Disposable in TypeScript: Explicit Resource Management

We got using/dispose aka explicit resource management in TypeScript 5.2. In this video, we look at a couple examples of how to use this tool in practice.
- mock - 0:37
- object pool: - 4:25
- transaction - 10:55
Check out the code for this video here: github.com/andrew8088/ts-usin...
My Links
shaky.sh
shaky.sh/tools
/ andrew8088
mastodon.social/@andrew8088
#programming #coding #typescript #javascript #using #resourcemanagement
#frontenddeveloper #backenddeveloper #softwareengineer #softwareengineering #softwaredevelopment

[@Luxcium]

You are so charismatic. I each time feel like you are probably the best friend, coworker, uncle, husband, father, brother, mentor, _cousin, grandfather(?), neighbor, teacher, coach, leader, colleague, role model, advisor, confidant, supporter, godfather, partner, buddy, pal, associate, ally, comrade, teammate, companion, guide, protector, hero, inspiration, guardian, benefactor, cheerleader, sympathizer, advocate, and champion._ (after mentor it is all ChatGPT but I wanted to make it clear how much I love to see your videos and how they make me feel good)… 🎉🎉🎉🎉

[@dimitrimitropoulos]

great to see more resources covering this topic!

[@IkraamDev]

Nice Neovim setup.

[@Luxcium]

I love your videos they are very amazing because they are instructive but I am such a nerd that I would rather say they are entertaining 😅😅😅😅

[@meyou118]

you could wrap or extend a new class, where the new class knows how to be pooled

[@studiowebselect]

potential bug a 10:42 if tPrime have already an Symbol.dispose.
You should combine tPrime Symbol.dispose if exist with your new one.
Also, its an javascript feature, not typescript.

[@andrew-burgess]

ooh, yup, good catch. calling the existing dispose first is exactly the right call.

[@smash3689]

Maybe wrapping the "T" object (monad approach) instead of monkey patching it would be better..? 🤷‍♂️dunno great video regardless!
Also the fact that you can keep the instance alive after the "dispose" method call was interesting (in your "pool" example, the "dispose" method puts the object into the pool list byitself, keeping the object from being removed by gc. Potential side effect concern? This "pool" thing is very new to me cause i'm just a junior front end dev. Would love to know if keeping the object from dying by gc by destructor-method-thingy is a common pattern/practice. Sorry for poor english ).

[@theyreMineralsMarie]

You could create a "Poolable" class/interface that Summer implements. That would would be the Java way at least.

[@adamszalkowski8226]

Is there any mechanism that checks if the to-be-disposed object leaks out of the scope?
Rust has the borrow checker for that purpose.

[@juanferrer5885]

Andrew I need your help, i tried to build reduce for fun but im stuck, i need your TS knowledge, its a funny exercise
`
const reducee = (
array: T[],
cb: (accumulator: U, val: T, index: number, array: T[]) => U,
initial?: U
) => {
for (let i = 0; i < array.length; i++) {
let acc = initial ;
if (initial === undefined) {
acc = array[0];
continue;
}
acc = cb(initial, array[i], i, array);
}
return initial;
};
`

[@user-fed-yum]

So it's somewhat like a c++ destructor? The design seems inconsistent with the rest of the language. I can't see how one could reasonably justify this is a necessary feature in its current form. Seems like astronaut architecture to me. Anyway, I'll stick with try finally for the time being.

[@thinkingdev102]

Any Queueable thing can be made handy with dispose / asyncDispose.
1. Any Email Builder
async using _ = mail(body).to(recipients)
2. Any Queue Job Dispatcher.
dispatch(job).
This will help with not waiting for these to finish before sending the response.

[@HoNow222]

this is the most awkward camera angle in youtube history