echarles
commented
6 years ago If current contributors are eager to move to typescript, then we should indeed try it for a new component.
I also mentioned on the slack channel a few options for theming and took more time to dig into the new-for-me css-in-js domain. @rgbkrk @alexandercbooth I feel that theming will drive the ion direction, where should we discuss this: I was thinking to comment on #33 but it has just been deleted.
To bootstrap the discussion on a solid foundation:
- I like the
styled-componentsapproach, especially its ThemeProvider. styled-systemlooks like it provide theme components without any logic/state (e.g. Tabs is not functional as such, you need to code more for this) - As they say on their homepage, it is more like bootstrap where you have to code your own logic.- From styled-components/awesome-styled-components, I stumble upon reakit/reakit which delivers a lot of react styled-components widgets developed in vanilla js.
I was thinking in first instance to wrap a reakit component and expose it in ion in a typescript way, maybe composing additional props to bring something more custom. WDYT?
There's a thread in the nteract slack (on #ion) about our choice of vanilla js. I'm bringing that thread over here to bring some insight, experiment, and pave direction.
@echarles asked:
Yeah! It's pretty tempting as we love typescript as well. It's currently flowtype backed largely because that's how nteract/nteract is setup and flow works out of the box with react styleguidist
Example style guides to get a feeling for what we're talking about:
Before we started this repository @alexandercbooth and I talked about doing more components with typescript. We soon came to realize that react-styleguidist didn't work with typescript because it uses react-docgen (which parses flow types with babel).
However, I just noticed that react-docgen-typescript now exists! It's time to experiment with it. 😄
Intent
As much as possible we want to see full blown usable components documentation that both developers and designers can experiment with. All the component doc tools that use react-docgen underneath help expose this (there's also docz, we're going with the one we've started using as the point is documenting the components while building them and the format is roughly the same).
The library is largely about getting the API design and visual design carved out in the way we'd like them, which aren't affected by how it's implemented underneath. At the end of the day we're going to produce both typescript definitions and flow defs.
Next Steps
For now, I recommend tackling some of the components in the README using some of the tooling that's in place so that we're both sharing a common understanding. That'll help for if and when we transition to typescript.