react-global-states is a global state store for React projects.
without the reducer, dispatch, thunk/saga, nested selector etc ceremonies.
npm install react-global-states
Before you start you need to decide whether you need SSR (Server-side rendering) support or just CSR (client-side rendering). SSR significantly changes the way you code/use the library.
CSR Example:
JS
import { useGlobalState, updateStates } from 'react-global-states';
const Component = () => {
// get a specific property from the global store
const { name = 'Dan' } = useGlobalState('greeting') || {};
return (
<div>
Hi {name}
{/* for sake of demo, I am not placing the action logic in an action file */}
<button onClick={() => updateStates({ greeting: { name: 'everyone' } })}>Greet everyone</button>
</div>
);
}
export default Component;
TS
import { useGlobalState, updateStates } from './myStore';
const Component = () => {
// get a specific property from the global store
const { name } = useGlobalState('greeting');
return (
<div>
Hi {name}
{/* for sake of demo, I am not placing the action logic in an action file */}
<button onClick={() => updateStates({ greeting: { name: 'everyone' } })}>Greet everyone</button>
</div>
);
}
export default Component;
// myStore.ts
import { createStore, createHooks } from 'react-global-states';
type MyStore = {
greeting: {
name: string;
}
}
const store = createStore<MyStore>({
greeting: {
name: 'Dan'
}
});
export const { getStates, updateStates } = store;
export const { useGlobalState } = createHooks(store);
SSR Example:
JS
import { useGlobalState, useStore } from './storeHelpers';
const Component = () => {
// get a specific property from the global store
const { name = 'Dan' } = useGlobalState('greeting');
const { updateStates } = useStore();
return (
<div>
Hi {name}
{/* for sake of demo, I am not placing the action logic in an action file */}
<button onClick={() => updateStates({ greeting: { name: 'everyone' }})}>Greet everyone</button>
</div>
);
}
export default Component;
// storeHelpers.js
import { createContextAndHooks } from 'react-global-states';
export const getInitialState = () => ({
greeting: {
name: 'Dan'
}
});
export const {
Context,
useGlobalState,
useStore,
} = createContextAndHooks(
// optional to pass initial states.. but you get IDE intellisense if you pass it.
getInitialState()
);
// app.js
import { createStore } from 'react-global-states';
import { Context, getInitialState } from './storeHelpers';
const App = () => {
const store = createStore(getInitialState());
return (
<Context.Provider value={store}>
<Component />
</Context.Provider>
);
}
export default App;
TypeScript
import { useGlobalState, useStore } from './storeHelpers';
const Component = () => {
// get a specific property from the global store
const { name } = useGlobalState('greeting');
const { updateStates } = useStore();
return (
<div>
Hi {name}
{/* for sake of demo, I am not placing the action logic in an action file */}
<button onClick={() => updateStates({ greeting: { name: 'everyone' }})}>Greet everyone</button>
</div>
);
}
export default Component;
// storeHelpers.ts
import { createContextAndHooks } from 'react-global-states';
type MyStore = {
greeting: {
name: string;
}
}
export const getInitialState = (): MyStore => ({
greeting: {
name: 'Dan'
}
});
export const {
Context,
useGlobalState,
useStore,
} = createContextAndHooks<MyStore>();
// app.js
import { createStore } from 'react-global-states';
import { Context, getInitialState } from './storeHelpers';
const App = () => {
const store = createStore(getInitialState());
return (
<Context.Provider value={store}>
<Component />
</Context.Provider>
);
}
export default App;
It is good practice to move the updateStates() calls to separate "action" file. For e.g. you can unit test the actions without having to test the UI components as well.
actions/greeting.js
export const updateName = (store, name) => {
store.updateStates({ greeting: { name }});
}
And you can change the component to the following:
import { useStore } from 'react-global-states';
import * as greetingActions from '../actions/greeting';
const Component = () => {
const store = useStore();
// ...
<button onClick={() => greetingActions.updateName(store, 'everyone')}>Greet everyone</button>
// ...
}
Note: Actions can be async functions (yay! no thunk/saga required).
Within the action file you can't use hooks though. Instead you can use getStates() to get the current states from the store.
export const someAction = (store, name) => {
const allGlobalStatesOfTheStore = store.getStates(); // you get all the properties of the store
const { greeting } = allGlobalStatesOfTheStore;
// ...
}
If you are using TypeScript or if you are creating an new store, you get the ability to set initial states of the store while creating the store:
import { createStore } from 'react-global-states';
const getInitialStates = ():MyStore => ({
greeting: {
name: 'Dan'
}
});
createStore<MyStore>(initialStates);
However if you are using the default store, you can initialize the store using setStates()
.
import { setStates } from 'react-global-states';
setStates({
greeting: {
name: 'Dan'
}
});
setStates()
simply replaces the entire store.
The library only reacts to changes in level 1 and level 2 properties of the store object.
This may seem like an arbitrary decision, but from previous experience with libraries like Redux on large projects, it is mostly not a good idea to have highly nested global store. Mostly because managing a tree is a lot harder. It involves selectors and re-mapping store properties to new names etc to improve performance, all of which adds unnecessary complexities/cognitive load, which could have been avoided if you flatten the global store in the first place. react-global-states
takes that as good practice and enforces it here.
So what happens if there is a third level of nesting? Well the library will only do a JS strict equality check (=== operator), unlike the first two levels where individual properties are checked. Render performance could take a hit if you nest the global store beyond 3 and more levels. So if you do change 3rd or 4th level (or more) object, make sure that you create a new 3rd level object everytime (using spread or whatever), so that component re-rendering is triggered.
Answer: Each server request for a page needs it's own states. Sharing states across requests does not work well in async rendering libraries like next.js
. Which means each request needs a new store, passed to components via a Context. But that makes libraries more complex to use.
Redux documents two issues they had to tackle named "zombie child" and "state props" problems.
The common pattern between the two issues is the use of component props to select a global state. react-global-states
does not support dynamic selectors, rather get all the data you need and make the conditional decision in render code. This happens to be a good thing here, as both classes of issues are not possible with static selectors.
When using react-global-states
with multiple renderers (e.g. react-three-fiber inside react), you will have to implement a solution mentioned in this thread by franciscop-sc.
Go to examples directory
yarn install
yarn start
and start playing with the example.
React hook to fetch a property from the the global store. Using the hook also associates the component with the property.
Parameters:
propName: Property names (string) you want to fetch from global store
Returns: The property you asked for. If a value doesn't exist you get undefined.
Returns: the entire global store. You can use this outside of a component (example: in an action file).
Replaces your entire store with the newStore
object you pass.
Parameters:
newStore: The new store object.
Returns: No return value
Function to update multiple states on the global store. updateStates will merge new states upto two levels of the store.
So let's say your store looks likes the following:
{
prop1: { a: 1 },
prop2: { b: 2 },
}
and you do an update as below:
updateStates({
prop1: { a: 0 },
prop2: { d: 4 },
prop3: { c: 3 },
});
then the resultant global store will look like:
{
prop1: { a: 0 },
prop2: { b: 2, d: 4 },
prop3: { c: 3 },
}
Parameters:
partial: An partial store object that would be used to update the store.
Returns: No return value
Returns: Store methods for the store that was connected via context provider.
Returns a function that can be used to update a specific prop from the store. This is only needed if prop value is an object which you want to incrementally update.
This is a convenience function. You can achieve what you want with updateStates() function alone if you wish.
Arguments:
propName: The prop name whose sub/inner properties that you want to ultimately update.
Returns: A function that you can call (any number of times) to incrementally update the prop's sub/inner properties.
Example:
// without createPropUpdater()
const resetCart = () => updateStates({ cart: { items: [] } });
const setCartItems = (items) => updateStates({ cart: { items } });
// ...
// with createPropUpdater()
const updateCart = createPropUpdater('cart');
const resetCart = () => updateCart({ items: [] });
const setCartItems = (items) => updateCart({ items });
// .. the more actions you have that is updating cart, the more useful createPropUpdater() becomes.
Creates a new store and returns an object with functions with same name & interface as the APIs mentioned above (i.e. store.getStates()) to manage the new store.
There are two use-cases for creating a fresh store, instead of using the default store:
-
You are using TypeScript: For type checks to work you need to define your Store's interface. The default store accepts any props, which won't give you strict type check.
-
You are writing a library/module that is expected to be used with any react app: In which case polluting the default store with props can cause naming collision with the consumer of your library. Creating new store avoids prop name collisions for libraries.
Parameters:
initialStoreProps (optional): An object with properties to initialize your store with.
Returns: An object with functions to use the new store.
useGlobalStates() is removed, instead use useGlobalState() (singular).
// old api
const { cart: { quantity } } = useGlobalStates(['cart']);
// new api
const { quantity } = useGlobalState('cart');
- Bring back createSubPropUpdater(). But it's named createPropUpdater() instead.
-
updatesStates() now will merge 2nd level properties unlike v2 which only merged 1st level properties.
-
Renamed createSubPropUpdater() method. updateStates() now can do the same job. However if you really need the compatibility, then you can implement it as follows:
import { updateStates } from 'react-global-states';
const createSubPropUpdater = (propName) => (partial) => updateStates({ [propName]: partial });
- no more ES5 support. distributions are in ES6
Support for react concurrent mode. From the current useMutableSource` RFC it seems like we can support concurrent mode without public API change. This is just theoretical at the moment.. things could change.