Adopting react-states

Introducing a framework into a project can often be a challenging task, and with good reason. Creating applications is not only about consuming the API surface of a framework, it is about patterns, best practices and conventions. If a team is familiar with a framework and works effectively in it, it is not really the framework that makes them effective, it is the experience, patterns, practices and conventions they have evolved together. Changing out the framework has a high cost as you need to grow new experience, patterns, practices and conventions.

What react-states offers is not an API, but a mindset. Using React primitives it offers a set of patterns, practices and conventions that enable your team to work more effectively and write code that makes you feel confident about the predictability of the user experience. That does not mean the concepts in react-states are immediately intuitive, which is why this list can help you defend why your team could benefit from this architecture.

• It is just React

• It is designed to take full advantage of TypeScript

• Your team will spend more time discussing how to best describe the state model, which shares ownership

• The UI implementation is completely separated from logic, meaning the team can split up its efforts

• Implementing UI is a pure joy. No logic, just consume a well described state model and fire off dispatches