Roadmap to 3.0

[quisido]

This Issue serves as documentation for anticipated breaking changes in 3.0 and allows community feedback to drive the development process.

Breaking Changes 💔

• Do not re-export React from reactn. Have users just import React and ReactN Component/hooks from separate packages. This will help with the namespace conflicts with Component in TypeScript.
• Remove support for @reactn decorator. Typing the decorator is difficult to maintain, and the feature is not often (if ever?) used.
• Property reducers/dispatchers to be moved to addPropertyReducer and usePropertyDispatch instead of sharing a namespace with addReducer and useDispatch.

New Features ✨

• Since the decorator is removed, the project can be pure TypeScript with the "as MagicType" happening in src/index.ts.
• Since addPropertyReducer is given its own helper function, the property can be tightly coupled at the global level. addPropertyReducer(property, reducer) would be synonymous with addReducer((global, dispatch, ...args) => ({ [property]: reducer(global[property], ...args) })). This may make some reducers easier to write.
• useSelector('id') as a simplified way to grab global.x.y.z.mutate(f).
• Update the /docs app to reflect 3.0 as development occurs.
• Rerendering of multiple subscriptions are batched. #129

Undecided 📃

• Try to officialize type Reducers = typeof reducers in reactn/global.d.ts.
• Use a different helper function for adding reducers that dispatch other actions.
  • function reducer(global, ...args) and function reducer(global, dispatch, ...args) should both be acceptable ways to write a reducer.
  • Forcing users to write the latter is annoying when the majority of reducers do not use the dispatch parameter.
  • This would require a verbiage change to describe reducers that dispatch and reducers that don't, e.g. addReducer and addSaga.
• Come up with solid verbiage for actions, reducers, dispatchers. The concept that actions and reducers are tightly coupled is not immediately obvious to users.
• Can the saga pattern be officialized? The global state manager has a concept of building up state changes before committing them. Should a commit/rollback method be exposed to saga reducers to allow them to build state before finalizing/committing it? Is the desired behavior of sagas to finish multiple state changes before re-rendering, or should the UI re-render as the state changes and the UI rolls back as the saga rolls back?
• Support deep-nested listeners? Perhaps only for objects that share an immediately prototype with Object or null, i.e. not instances of Error, etc. useGlobal('x', 'y', 'z'). On state change, check all global subscriptions for shallow keys, then check all matches for shallow key changes. Implementation direction could use fleshing out.

[ffMathy]

What is the status on 3.0? More specifically, the feature where React is removed from the library, so that it is no longer re-exported.

[quisido]

React will remain in 2.x because removing it would be a breaking change. ReactN functions the same way whether or not you import React from it or from the react package. In my personal projects, I still import React from 'react'; when using ReactN. I hope you don't feel as if you are forced into importing it from reactn!

3.x is on pause, as my contributions to Amazon CloudWatch take higher priority at the moment.

I still think about 3.x on almost a daily basis! :) It's simply a matter of finding time to do a near-complete rewrite of an established product. That's a lot of time: something I simply don't have right now.

[matteocargnelutti]

@CharlesStover Reactn is a fantastic tool and my team and I have been using it for a while. The roadmap to 3.0 is exciting, but there is just one thing I wanted to mention:

Remove support for @reactn decorator. Typing the decorator is difficult to maintain, and the feature is not often (if ever?) used.

We do use this feature a lot. The only problem we've had with it is the constant deprecation notice it generates, as componentWillUpdate is still implemented by the decorator, as mentioned in #134.