Just have default throw an error? Then, if you add a value to the string union (hopefully) your tests will highlight it isnt handled.
Equally, for such a simple switch, surely a map is better?
But i rarely find myself using switches.
I find ifs with early returns cleaner. Allows for variable creation during execution (which my tslint complains about)
I really appreciate compile errors in this scenario. In Rust the compiler will freak out when there are missing enum variants in a match. Tests are great, but compiler errors don’t rely on exhaustive and properly written tests.
Generally, I would recommend against throwing in the default case, since it will actually reduce your type safety (exceptions bypass all your other types). But I learned that with another clever trick this can be avoided, giving both runtime and compile time safety: exploringjs.com/tackling-ts/ch_enums.html#exhaust…
The loose approach could be good as a way to get your feet wet if the entire team has no preexisting TS experience and needs to get weaned into it.
However when it comes to seriously converting the codebase I completely agree, not just for TS conversations, but for all major refactors. Slowly updating the same file over and over again is simply inefficient and leads to things never fully getting done.
Hi - I have been using this in production for a few months now, and haven’t experienced significant issues with debugging or troubleshooting.
It also helps that the library is type-safe - if we are overriding a function, we must comply with the signature of the original function for TS to pass.
Wrt. run time errors, the use of proxy does not interfere with good stack traces, if that is what you are worried about.
If we take the example in this gist where an overriden function throws an exception, we can see that the stack trace clearly shows the file (which overrides the hello function) where the exception is originating from.
In effect, the DX is not much different if you use any other mechanism for making some feature runtime configurable. In comparision to most traditional IoC/DI utilities I find the DX to actually be superior:
Unlike a lot of other IoC solutions whose APIs are cloned/inspired from similar Java/C# libraries, you don’t need to wrap things in classes to participate in the DI system
Also, that a function is overridable is transparent from consumer side - they just call a function that they import without needing any @Inject/@Provide boilerplate. This is great if you are writing a library or a small utility and don’t want to enforce usage of a specific DI/IoC library for your consumers.
What we don’t have (and likely will never) is support for things like request scoped DI or hierarchy of IoC containers. In mostly-functional TS code I have seldom missed those patterns.
Oh, I get it. It’s like a tech demo, to encourage Microsoft to add compiler plugins. Can’t really use it on a project of any scale, due to every other tool also providing its own TS compiler, again because TSC doesn’t support plugins.
I use it in the code generator mode (typia.io/docs/setup/#generation) that doesn’t require the tsc plugin integration and works well with other build tools (in my case esbuild) and arbitrary testing/code-coverage libraries.
Yes, that mode works pretty well. In my case I don’t really own the types (they come from a third party source) so being able to to auto generate validators from them is very convenient.
Title: Optimizing TypeScript: Embracing Functional Patterns and Leveraging V8’s Strengths
Body:
Hello TypeScript Community! Our journey in TypeScript development benefits greatly from a deeper understanding of JavaScript’s core mechanics and the V8 engine’s optimizations. It’s become increasingly clear that JavaScript, and by extension TypeScript, subtly discourages traditional object-oriented (OO) programming in its built-in functionalities, favoring functional programming paradigms instead. Combining this with V8’s optimization techniques can significantly enhance our code’s performance and readability.
Functional Over OO in JavaScript’s Built-ins:
Function References in Core Functions: JavaScript’s built-ins, like addEventListener, setTimeout, setInterval, and array methods (map, filter, reduce), prefer function references over objects with expected methods. This design choice subtly favors functional programming over OO.
Closures for State Management: Instead of passing around shaped objects or using bind, closures provide a more natural and efficient way to maintain state in functions, aligning well with JavaScript’s functional tendencies.
Understanding and Utilizing V8’s Optimizations:
Leveraging Hidden Classes and Inline Caching: Consistent object property initialization helps V8 create and reuse hidden classes efficiently, optimizing property access. Inline caching improves performance by optimizing repeated property and method access on objects.
Best Practices for V8 Optimizations: Avoid dynamic changes to object shapes and focus on writing monomorphic code to aid V8’s optimization processes.
Adapting to Functional Programming in TypeScript:
Functional Patterns for Performance: Embrace functional patterns, such as immutable data and pure functions, which V8 optimizes more effectively than complex class hierarchies.
Using TypeScript Features for Functional Code: TypeScript’s powerful type system, including interfaces and type aliases, supports a more functional style of coding, which is inherently more aligned with V8’s optimization strategies.
Moving Away from Classic OO Patterns:
Challenges with OO in TypeScript: The behavior of this, complex inheritance structures, and the awkwardness of bind highlight the incongruities of OO patterns in TypeScript.
Functional Techniques as Solutions: Opt for closures and composition over inheritance. Utilize functional programming constructs to create more modular, reusable, and efficient code.
In conclusion, by understanding the inherent functional leanings of JavaScript and TypeScript, and by aligning our coding practices with V8’s optimization techniques, we can write more efficient and maintainable TypeScript code. This approach not only capitalizes on the language’s strengths but also ensures our code is primed for optimal performance by the V8 engine. Let’s continue to explore and embrace these functional paradigms and share our insights on leveraging V8’s capabilities in TypeScript development.
To add, turning everything into an enum can make the code nearly unreadable and hard to work with. This isn’t Rust, and there’s no performance gain for using enums over string unions.
typescript
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.