I would recommend avoiding adding your own global types if you can avoid it, for example TypeScript has a full type definition for Array.prototype.find [1]. You can enable it without changing the target and breaking things by adding es2015 to lib in your tsconfig compilerOptions
I would add
1) Starts with `strict: true`
2) Favor interface over class
3) Functional first, OO as needed
4) Avoid Java way of coding, DI, Class for everything.
Nice ones! My first TS project was with a C# guy, so we had some virtual classes, no good) Anyways, the TS community itself does not seem to enforce OOP stuff too much — Angular / mobx do.
On the other hand, I don't know why the DI stuff never caught on in he js world — it should be good for testablity (better than build-time magic at least)?
Honestly, DI is really a thing of the OO-Obsessed world when everything has to be a class and instantiated.
In the JS/TS world, we mostly use Interface/Type to describe constraints, and most of the module export function or group of methods in a const (namespace, module,...) but the caller does not have to know if it is a class or just a object with some methods, and does not do a "new ..." or @inject... anymore. Much simpler, much more intent driven, and you can remove a lot of boilerplate code (which DI still is)
Now, one of the value of DI is for testing, and one way to accomplish module compartmentalization, is with module-alias. It does not the granularity that DI needs, but I would argue that if more is needed, it perhaps because the testing and mocking got a little too out of hands. In our experience, thanks to Kubernetes, we try to mock less, and have our test running mostly with real services.
5 comments
[ 1.4 ms ] story [ 22.9 ms ] thread[1] https://github.com/Microsoft/TypeScript/blob/5fb39769ada9ff7...
On the other hand, I don't know why the DI stuff never caught on in he js world — it should be good for testablity (better than build-time magic at least)?
In the JS/TS world, we mostly use Interface/Type to describe constraints, and most of the module export function or group of methods in a const (namespace, module,...) but the caller does not have to know if it is a class or just a object with some methods, and does not do a "new ..." or @inject... anymore. Much simpler, much more intent driven, and you can remove a lot of boilerplate code (which DI still is)
Now, one of the value of DI is for testing, and one way to accomplish module compartmentalization, is with module-alias. It does not the granularity that DI needs, but I would argue that if more is needed, it perhaps because the testing and mocking got a little too out of hands. In our experience, thanks to Kubernetes, we try to mock less, and have our test running mostly with real services.