TypeScript Adoption Plan: get it started 🎉 #5
Conversation
|
Like I said in Discord, my imagination regarding the documentation is:
These three switches, it seems, would make TS seem pretty first-class in the documentation. It's always there, but it's not in your face. I think the a11y model might be good to follow. Make it accessible by default (though TS isn't default), and reward people who want to do a deeper dive. In this case, make TS an option in the detailed tutorial and then just move on. Ideally the code snippets would all be written in TS and then the JS version would be compiled from it, like with the proposed blueprints. This means not having to maintain two versions of each code snippet. |
|
@muziejus I believe all of that is covered in the RFC. :) |
|
Super. Can't wait to contribute to the documentation. |
|
|
||
| This does introduce two new small considerations: | ||
|
|
||
| - New APIs will now need to specify import paths for type-only imports. For example, today there is no public import for `Transition` or `RouteInfo`, because they are not intended for end users to construct. However, types for them *should* be publicly exported because end users need to be able to name those types them in their own code. If we were to write [RFC #0095: Router Service](https://emberjs.github.io/rfcs/0095-router-service.html) today, we would specify imports for both. |
Co-authored-by: Dan Freeman <dfreeman@salsify.com>
- Courtesy of @wagenet's work (and in line with the recommended migration path for Ember Classic types *in this RFC*!) the bit about `Controller` ambient types became defunct, and we should in fact be able to rely on Ember’s own types as the full source of truth. - Fix an incomplete sentence/paragraph caught by @dfreeman (on the SemVer option of *not* using `strict: true` but using specific flags).
|
Opened as emberjs#800! |
Rendered draft – now open for comments and input from the TypeScript strike team for polishing before opening against Ember!
Looking for feedback especially on: