1.0.0 Roadmap

[camwest]

Themes

• replace the prototype we have in production at Autodesk with this library
• [x] write proper test suite & setup guide
• [x] figure out how to deal with React Fiber situation - solution use react@next dependency

Engineering

• [x] Write unit tests for components
• [x] Extract & refactor lib into separate modules
• [x] Decide if view registry should be truly global or if it should be instanced with a provider component and passed via context
• [x] Convert to typescript #10
• [ ] Add better error message if Provider is missing

Infra

• Come up with a plan to verify we've got good browser support
• Set up circle ci
  • [x] Run unit tests
  • [x] Deploy github pages automatically on green build
  • [ ] Deploy canary release automatically on green build
• [x] Set up code coverage measurement with codacy
• [ ] Export pkg.module

Documentation

• [ ] Write some sample applications in addition to the demos we've built so far.
• [x] Add a forkable example on https://glitch.com/ that's really easy to play with
• [ ] Show an example using Redux

Bugs

Tech Debt

Development Experience

• This is looking pretty good since we are just literally using the default CRA

[rogeliog]

This is awesome! Thanks for putting a roadmap together... I'm happy help with any of these

[maxdeviant]

Super excited about this after watching your talk. Will definitely be looking to try this out in production once things are a bit more stable :smile:

[bondz]

Partial to Typescript as well, its integration with VSCode and other editors is stellar and makes the development experience much better. As this is a library though, the typings are the only thing required to use it with a tsx project. I'm sure there are tools to create typings automatically for TypeScript or Flow whichever you chose.

[ggarek]

Awesome initiative, i will definitely keep a close look on the library development! And i like the talk on React Conf 👍

Regarding the types, i think it is really a must have overall and for this kind of library for sure. It is a lifesaver in a long perspective. Personally i like TS more, and i really think that there should be only one typing system over there. Because supporting two different type systems is not an easy task (as difficult as it is redundant and meaningless).

Sure, one could automate creating type definitions, but as to my experience (i have dealt with autogenerated type defs) the best type definitions are made and supported manually along with the project development. The earlier you start - the easier it will be. And all auto-type-generation do not yield stable usable-without-a-pain results.

I really love TS (did i say it already?) 😉 , but there is one thing to be considered. If the slot-and-fill lib is meant to be used with React Native (which would be really awesome, and must be thought of, imo. Especially now, when it is not only about ios/android but it is also about desktops!) then users will have to do with two type systems in one project, because RN uses Flow. But i still hope the TS will win, and may be RN will switch to TS xD (not going to happen apparently).

[camwest]

Ok TypeScript sounds fine to me.

[camwest]

FYI #10 has initial typescript conversion.

[slorber]

hi

Just wondering if anyone ever used this in a RN projet? I dont see any react-dom dependency/peerDependency but it seems react-dom is used in code. Can this lib be made RN compatible?