3 ms·

I started using TypeScript about 7 months ago. And heavily in the last 3 months. I'm up to speed now, but I still feel I'm missing an opinion. e.g. I have nat

I started using TypeScript about 7 months ago. And heavily in the last 3 months. I'm up to speed now, but I still feel I'm missing an opinion. e.g. I have naturally been drawn to "maximally infer" types, whilst I see other developers would rather re-create/co-locate a type with its function/component. Does anyone have a repo where they think the TS is near-perfect? Or even better, a deeply opinionated Style Guide?

chmod775 6y ago
It's nice to explicitly state types at module boundaries, which will make it easier for other developers, theoretically allows some type-checking optimizations, and will prevent you from accidentally changing your API. I've been starting to build speed-focused TS type-checker that is intended to be used in single-file editors like VIM to highlight errors, because it starts checking from a single file and just traverses files necessary to check types within that one file. If you defined your types at a module boundary it can bail out super early, since it doesn't need to look at the rest of the code of that module at all. Most linters have rules that will force you to explicitly declare types at module boundaries. Other than that, do whatever you prefer.
- orta 6y ago
  Very cool. I'd recommend reading the built-in vscode extension for TypeScript, because with 4.0 we added a feature very close to that for editors into TypeScript and you can rely on our work instead. Links in: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-0.html#partial-semantic-mode-at-startup https://www.typescriptlang.org/docs/handbook/release-notes/t...
stopyellingatme 6y ago
Go to the VS Code repo. It's written in TS and its one of the best examples of a well written TS app. https://github.com/microsoft/vscode https://github.com/microsoft/vscode
eyelidlessness 6y ago
I’ll second the point about explicit types at module boundaries and add: - Ideally they should either not be derived types (using eg type parameters), or if they are they should be derived using types from the same layer of your project/service. This makes it much more likely you’ll notice if you introduce breaking changes. - Types should also between network boundary layers and business logic, regardless of your module structure. This ensures your business logic’s interface is clear regardless of how it’s consumed, making it more easily testable and more portable (eg to other transport formats/protocols).

chmod775 6y ago

It's nice to explicitly state types at module boundaries, which will make it easier for other developers, theoretically allows some type-checking optimizations, and will prevent you from accidentally changing your API. I've been starting to build speed-focused TS type-checker that is intended to be used in single-file editors like VIM to highlight errors, because it starts checking from a single file and just traverses files necessary to check types within that one file. If you defined your types at a module boundary it can bail out super early, since it doesn't need to look at the rest of the code of that module at all. Most linters have rules that will force you to explicitly declare types at module boundaries. Other than that, do whatever you prefer.

orta 6y ago
Very cool. I'd recommend reading the built-in vscode extension for TypeScript, because with 4.0 we added a feature very close to that for editors into TypeScript and you can rely on our work instead. Links in: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-0.html#partial-semantic-mode-at-startup https://www.typescriptlang.org/docs/handbook/release-notes/t...

stopyellingatme 6y ago

Go to the VS Code repo. It's written in TS and its one of the best examples of a well written TS app. https://github.com/microsoft/vscode https://github.com/microsoft/vscode

eyelidlessness 6y ago

I’ll second the point about explicit types at module boundaries and add: - Ideally they should either not be derived types (using eg type parameters), or if they are they should be derived using types from the same layer of your project/service. This makes it much more likely you’ll notice if you introduce breaking changes. - Types should also between network boundary layers and business logic, regardless of your module structure. This ensures your business logic’s interface is clear regardless of how it’s consumed, making it more easily testable and more portable (eg to other transport formats/protocols).