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.
-
-
I think the attitude that they show in #1 - that TypeScript is only supposed to add typing to JavaScript and everything that goes beyond is bad - is wrong.
In fact, the only major problem I have with TypeScript is the lack of operator overloading [1]. This feature has been denied with the exact same justification. They will not add any feature that emits additional logic, so they cannot add operator overloading unless JS adds it. Also they will not add anything that needs runtime type lookup.
I think very simple, stupid syntactic sugar would be sufficient to solve 90% of use cases. For example, and please don't take this apart, I'm just making it up on the spot: transforming `a + b` to `a._op_add(b)` if a is not provably `any` or a primitive type.
Without operator overloading, for example vector math looks really ugly. I hope somebody will make at least a babel plugin or something to allow that.
[1]: https://github.com/microsoft/TypeScript/issues/6936
I've just looked this up and it seems to support `const enum` just fine[0]. I remember Babel not being able to process `const enum`, since it goes across module boundaries and Babel does not.
[0]: https://github.com/evanw/esbuild/issues/128
The symbol, as a whole, isn't shorter. But, it's easier to read (and write!). It also helps disambiguate where in the symbol each component of the type's name should reside, when the producer wants to for example add a new type or function.
The argument against presented by the article boils down to: it creates unnecessary fluff in the emitted javascript. That's a reasonable argument; it does. In practice, it's more nuanced. First: I've never seen it cause an issue. So, premature optimization, YMMV, etc. Second: the fluff is erased for types anyway; so it only becomes an issue for functional code defined like this (all of my examples were in types, but its easy to imagine a Google.User.List function). Third, though not a direct counterargument to the article: it's literally how Google organizes the types we've been talking about [1] (though, how they organize the functional code, I'm not sure).
[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
The latest versions of Ember.js (Octane) have built-in decorator support and they're discussed in the RFC:
https://github.com/emberjs/rfcs/blob/master/text/0408-decora...
https://guides.emberjs.com/release/in-depth-topics/native-cl...
Related posts
- If you ever get called out for using long type names, remember this exists
- Declaring JSX types in TypeScript 5.1
- Challenges and Confusion in Learning React Native
- Functional Programming with TypeScript's Type System
- TypeScript PR merged to allow components to return anything renderable (raw strings, numbers, promises for RSC), instead of just JSX.Element and null.