Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
proposal-async-explicit-resource-management
Discontinued ECMAScript Async Explicit Resource Management
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
proposal-class-method-parameter-decorators
Decorators for ECMAScript class method and constructor parameters
The proposal[1] explains several cases where try…finally is verbose or even can result in subtle errors. The upshot for me is that this feature adds RAII to JavaScript. It makes resource management convenient and more maintainable. Seems like a no brainer to me.
[1] https://github.com/tc39/proposal-explicit-resource-managemen...
There's a conversation I had with Ron Buckton, the proposal champion, mainly on this specific issue. [1]
Short answer: Yes, Disposable can leak if you forget "using" it. And it will leak if the Disposable is not guarded by advanced GC mechanisms like the FinalizationRegistry.
Unlike C# where it's relatively easier to utilize its GC to dispose undisposed resources [2], properly utilizing FinalizationRegistry to do the same thing in JavaScript is not that simple. In response to our conversation, Ron is proposing adding the use of FinalizationRegistry as a best practice note [3], but only for native handles. It's mainly meant for JS engine developers.
Most JS developers wrapping anything inside a Disposable would not go through the complexity of integrating with FinalizationRegistry, thus cannot gain the same level of memory-safety, and will leak if not "using" it.
IMO this design will cause a lot of problems, misuses and abuses. But making JS to look more like C# is on Microsoft's agenda so they are probably not going to change anything.
[1]: https://github.com/tc39/proposal-explicit-resource-managemen...
Your code is destructuring two properties and discarding one of them. It doesn't work with a single property: https://sharplab.io/#v2:C4LgTgrgdgNAJiA1AHwAICYAMBYAUBgRj2Nw...
I think that records don't generate a deconstruct method when they only have one property, but even if you manually define one you'll get an error on `var (varName) = ...`
https://github.com/tc39/proposal-async-explicit-resource-man...
https://github.com/tc39/proposal-async-explicit-resource-man...
> Imports without webpack.
https://caniuse.com/?search=import
Unless you were using the (yet unimplemented) exact types in TS. https://github.com/Microsoft/TypeScript/issues/12936
Yes, the requirement that static constructors are used makes this substantially less ergonomic than it would otherwise be for the reasons you point out.
Some of the React hooks in Isograph use this pattern, and as a result the constructor returns an instance in an invalid state: https://github.com/isographlabs/isograph/blob/1a8182355ac9d1...
I'm of the opinion that this is a paper cut worth stomaching in favor of the addition of an idiom that provides genuine safety. The type for the class and the static conductor (ie a free function) could be exposed, but the class itself could be hidden.
> I wonder if they will put forth a new proposal for dependency injection next, at this rate.
Yes, there is a new-ish proposal [1] which is motivated in large part by DI.
(Full disclosure: I'm on the committee and don't really like DI or this proposal. But we'll see how it goes.)
[1] https://github.com/tc39/proposal-class-method-parameter-deco...
> I wonder if they will put forth a new proposal for dependency injection next, at this rate.
Yes, there is a new-ish proposal [1] which is motivated in large part by DI.
(Full disclosure: I'm on the committee and don't really like DI or this proposal. But we'll see how it goes.)
[1] https://github.com/tc39/proposal-class-method-parameter-deco...