4 ms·

Not Sucking at TypeScript: 3 Tips

2 points by thoughtspile 8y ago

Alexendoo 8y ago
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 [1] https://github.com/Microsoft/TypeScript/blob/5fb39769ada9ff72d905c62069aab136c93f38a8/lib/lib.es2015.core.d.ts#L22-L32 https://github.com/Microsoft/TypeScript/blob/5fb39769ada9ff7...
- thoughtspile 8y ago
  Thanks, I reckoned there was a way to get it done but never found one! Can you also enable individual features, not the whole pack?
jeremychone 8y ago
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.
- thoughtspile 8y ago
  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)?
  - jeremychone 8y ago
    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.

2 points by thoughtspile 8y ago

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 [1] https://github.com/Microsoft/TypeScript/blob/5fb39769ada9ff72d905c62069aab136c93f38a8/lib/lib.es2015.core.d.ts#L22-L32 https://github.com/Microsoft/TypeScript/blob/5fb39769ada9ff7...

thoughtspile 8y ago
Thanks, I reckoned there was a way to get it done but never found one! Can you also enable individual features, not the whole pack?

jeremychone 8y ago

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.

thoughtspile 8y ago
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)?
- jeremychone 8y ago
  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.