Motivation

React components has a built-in state object, where you store property values that belongs to the component.

When the state object changes, the component re-renders.

This behaviour has certain limitations:

• Component state can only be shared by pushing it up to the common ancestor, but this might include a huge tree that then needs to re-render.

React-Holmes adopts a new vision when talking about state handling.

As other state managers use an external single source of truth to hydrate app client on state change, React-Holmes does not create an external store and does not need to wrap your app in a context.

So, where is the global state?

There is no global state, actually.
The state is decentralized into components themselves.

The ONLY differences are the hook declared for state management and a key to identify state chunk.

While to declare a React state we need to declare it as:

    const [state, setState] = React.useState('test');

with React-Holmes we need to declare it as:

    const [state, setState] = useHolmesState('key', 'test');

What does useHolmesState do?

When a state is set with useHolmesState, the hook is responsible to set state with React and add some power ups to it.

In fact, when a component using useHolmesState is mounted, it will create (if not exists) a new RxJs Observable identified by specified key.

If we register another component with the same key, it will not create another Observable, instead it will subscribe to existing one, allowing access to its value and its callback to mutate the state.

This allows state handling to be delegated to React itself, guaranteeing reactish updates and shared state too.

So React-Holmes can be considered a React state orchestrator because its hooks can be used into very small and deeply nested components without performance impacts generated by multiple re-renders.

• 🚀 Easy as React state management
• 🔄 State synchronization between components
• 🛰️ Distributed and not centralized state
• 🤯 No extra re-renders
• 🚀 Fast