Redux with React - right way to share the store with components - reactjs

The store service from Redux is what ultimately utilized by various components in a React App. The methods (such as dispatch, getState and subscribe) exposed by it are used by all kinds components (like container or presentational).
I think the approach to pass this store service around is an important design decision. I see two approaches and they are:
1) By passing the store as a prop to every component at all nested levels. This is not the recommended one.
2) Use a tool like react-redux, which with the help of context, makes the store (state and dispatch to be exact) available wherever it is needed.
My questions are: Why not simply import the store wherever it is needed. For an SPA-based React App, store will be a singleton. Components nested at any level can simply import the store. Why should we adopt anyone of the above two approaches?
For a component at any nested level: Can we do this
import store from "path/to/store";
let MyComponent = () => {
let state = store.getState();
return (
<div onClick={() => {
store.dispatch({
type: "SOME_EVENT",
payload: store.somedata
});
}}>{state.dataINeedHere}</div>
);
};
export default MyComponent;
instead of
import { connect } from "react-redux";
let MyComponent = ({somedata, onMyAction}) => {
let state = store.getState();
return (
<div onClick={() => {
onMyAction(somedata);
}}>{somedata}</div>
);
};
const mapStateToProps = (state) => {
return {
somedata: state.somedata
}
}
const mapDispatchToProps = (dispatch) => {
return {
onMyAction: (input) => {
dispatch({
type: "SOME_EVENT",
payload: input
});
}
}
}
export default connect(mapStateToProps, mapDispatchToProps)(MyComponent);

The Redux FAQ covers this question, at http://redux.js.org/docs/FAQ.html#store-setup-multiple-stores.
Summarizing: while you can directly import a store, you're tying your code to that store implementation, which makes it less reusable and harder to test. Ideally, none of your own code actually ever references the store directly. Connected components, middleware, and thunked action creators all receive the relevant dispatch and getState function references by dependency injection, making them reusable and allowing easy mocking of behavior for testing.

Consider what happens when you have a second MyComponent, which manages data from a different part of the store. Your options are to tell each exactly how to access/update its data:
<Container>
<MyComponent path="/a/b/c" />
<MyComponent path="/a/b/d" />
</Container>
or you can give each access to only what it needs:
<Container>
<!-- context /a/b was passed to Container -->
<MyComponent data={c} onUpdate={update(c)} />
<MyComponent data={d} onUpdate={update(d)} />
</Container>
The latter makes the MyComponent much simpler and much more flexible.

Related

Composition In React with params

I am trying to create an architecture that in some way imitates the slots from VUE.
The idea is for the parent component to be able to inject some props into the component and the child can inject the rest of the props.
This is how I tried to approach this problem, unfortunately this approach will not work because the compontent will be "monut" every time the parent re-render takes place.
Filters = (prams) => {
useEffect(()=>{ //RENDER ALL THE TIME },[])
...
}
ParentComponent = () => <ChildComponent Filters={(props) => <Filters propA={"A"} />}
ChildComponent = (props) => {
const Filters = props.Filters;
render(<Filters probB="B" />)
}
I know, I can use useCallback for ((props) => <Filters propA={"A"} />), but only it will help only if what I want to pass to "propA" is steady.
I want to "manage" <Filters /> component in parent, so that the child does not have to handle Filters logic (props).
React gives you proper API to do most things. Using it forces you into certain paradigms that are proven to work well.
You should probably have a look at the Context and Memo APIs from React.
Or if you have to select and update state from multiple components, you might wanna have a look at libraries that provide global state, like Redux and Recoil.
Context example
// The shape
interface ContextProps {
myProp: string
}
// The context
export const MyContext = React.createContext<Partial<ContextProps>>({
myProp: 'nothing'
});
// The provider
<MyContext.Provider value={{ myProp: 'override' }}>
{children}
</MyContext.Provider>
// Consumer
const { myProp } = useContext(MyContext)
In some case you can also use useMemo or React.memo and use your own custom compare function if needed to prevent re-renders in very specific situations.

React - Hooks + Context - Is this a good way to do global state management?

I am trying to find a good, clean, with little boilerplate, way to handle React's global state
The idea here is to have a HOC, taking advantage of React's new Hooks & Context APIs, that returns a Context provider with the value bound to its state. I use rxjs for triggering a state update on store change.
I also export a few more objects from my store (notably : the raw rxjs subject object and a Proxy of the store that always returns the latest value).
This works. When I change something in my global store, I get updates anywhere in the app (be it a React component, or outside React). However, to achieve this, the HOC component re-renders.
Is this a no-op ?
The piece of code / logic I think could be problematic is the HOC component:
const Provider = ({ children }) => {
const [store, setStore] = useState(GlobalStore.value)
useEffect(() => {
GlobalStore.subscribe(setStore)
}, [])
return <Context.Provider value={store}>{children}</Context.Provider>
}
GlobalStore is a rxjs BehaviorSubject. Every time the subject is updated, the state of the Provider component gets updated which triggers a re-render.
Full demo is available there: https://codesandbox.io/s/qzkqrm698q
The real question is: isn't that a poor way of doing global state management ? I feel it might be because I basically re-render everything on state update...
EDIT: I think I have written a more performant version that's not as lightweight (depends on MobX), but I think it generates a lot less overhead (demo at: https://codesandbox.io/s/7oxko37rq) - Now what would be cool would be to have the same end result, but dropping MobX - The question makes no sense anymore
I understand your need to handle a global state. I already found myself in the same situation. We have adopted similar solutions, but in my case, I've decided to completelly drop from ContextAPI.
The ContextAPI really sucks to me. It seems to pretend to be a controller based pattern, but you end up wrapping the code inside an non-sense HOC. Maybe I've missed he point here, but in my opinion the ContextAPI is just a complicated way to offer scoped based data flow.
So, I decided to implement my own global state manager, using React Hooks and RxJS. Mainly because I do not use to work on really huge projects (where Redux would fit perfectly).
My solution is very simple. So lets read some codes because they say more than words:
1. Store
I've created an class only to dar nome aos bois (it's a popular brazilian expression, google it 😊) and to have a easy way to use partial update on BehaviorSubject value:
import { BehaviorSubject } from "rxjs";
export default class Store<T extends Object> extends BehaviorSubject<T> {
update(value: Partial<T>) {
this.next({ ...this.value, ...value });
}
}
2. createSharedStore
An function to instantiate the Store class (yes it is just because I don't like to type new ¯\(ツ)/¯):
import Store from "./store";
export default function <T>(initialValue: T) {
return new Store<T>(initialValue);
}
3. useSharedStore
I created an hook to easily use an local state connected with the Store:
import Store from "./store";
import { useCallback, useEffect, useState } from "react";
import { skip } from "rxjs/operators";
import createSharedStore from "./createSharedStore";
const globalStore = createSharedStore<any>({});
type SetPartialSharedStateAction<S> = (state: S) => S;
type SetSharedStateAction<S> = (
state: S | SetPartialSharedStateAction<S>
) => void;
export default function <T>(
store: Store<T> = globalStore
): [T, SetSharedStateAction<T>] {
const [state, setState] = useState(store.value);
useEffect(() => {
const subscription = store
.pipe(skip(1))
.subscribe((data) => setState(data));
return () => subscription.unsubscribe();
});
const setStateProxy = useCallback(
(state: T | SetPartialSharedStateAction<T>) => {
if (typeof state === "function") {
const partialUpdate: any = state;
store.next(partialUpdate(store.value));
} else {
store.next(state);
}
},
[store]
);
return [state, setStateProxy];
}
4. ExampleStore
Then I export individual stores for each feature that needs shared state:
import { createSharedStore } from "hooks/SharedState";
export default createSharedStore<Models.Example | undefined>(undefined);
5. ExampleComponent
Finally, this is how to use in the component (just like a regular React state):
import React from "react";
import { useSharedState } from "hooks/SharedState";
import ExampleStore from "stores/ExampleStore";
export default function () {
// ...
const [state, setState] = useSharedState(ExampleStore);
// ...
function handleChanges(event) {
setState(event.currentTarget.value);
}
return (
<>
<h1>{state.foo}</h1>
<input onChange={handleChange} />
</>
);
}
GlobalStore subject is redundant. RxJS observables and React context API both implement pub-sub pattern, there are no benefits in using them together this way. If GlobalStore.subscribe is supposed to be used in children to update the state, this will result in unnecessary tight coupling.
Updating glubal state with new object will result in re-rendering the entire component hierarchy. A common way to avoid performance issues in children is to pick necessary state parts and make them pure components to prevent unnecessary updates:
<Context.Consumer>
({ foo: { bar }, setState }) => <PureFoo bar={bar} setState={setState}/>
</Context.Provider>
PureFoo won't be re-rendered on state updates as long as bar and setState are the same.

Fully react state management

This is not an issue but rather a question.
I wanted to use React solely for my Global state management and pass the todos through useReducer and useContext and I wonder if this is by any means a right way to go. I was called out by a react coder that this way the components rerender when they aren't supposed to but my element inspection shows only the changed component rerenders. Would please guide me as whether or not I can continue developing this way or have to revert back to Mobx or redux or many other third party state manager libraries.
Yes, you can and it's easier than ever thanks to the new hooks API! For very simple things like for instance, a global theme you can just create a context with React.createContext, and useContext.
For a more robust solution, you can actually implement a Flux architecture with a combination of useContext and useReducer. Here's one I made earlier.
// AcmeContext.js
import React, { useReducer, createContext } from 'react'
const AcmeContext = createContext({})
const actions = {
DO_SOMETHING: 'doSomething'
}
const actionCreators = dispatch => ({
updateComment: comment => {
dispatch({
type: actions.DO_SOMETHING,
payload: comment
})
}
})
// first paramter is your state, second is the action
let reducer = (currentState, { type, payload }) => {
switch (type) {
case actions.DO_SOMETHING:
// important: return a NEW new object for this context, don't change the old currentState
return { ...currentState, hello: payload }
default:
return
}
}
// this component wraps any of the child components that you want to share state with
function AcmeProvider({ children, initialState }) {
const [state, dispatch] = useReducer(reducer, initialState)
const actions = actionCreators(dispatch)
return (
<AcmeContext.Provider value={{ state, actions }}>
{children}
</AcmeContext.Provider>
);
}
export { AcmeContext, AcmeProvider }
Then, you wrap the component you want to provide the context to with the exported provider.
// App.jsx
import { AcmeProvider } from './AcmeContext'
import TestComponent from './TestComponent'
render((
<AcmeProvider initialState={{ hello: 'world' }}>
<TestComponent />
</AcmeProvider>
), document.querySelector('.app'))
Finally, you can call it from the child component.
// TestComponent.jsx
import { AcmeContext } from './AcmeContext'
export default () => {
const { state, actions } = useContext(AcmeContext)
return (
<div>
Hello {state.hello}!
<button onClick={() => actions.updateComment('me')}>Set response on onClick to 'me'</button>
</div>
)
}
This does have a couple of downsides to a full Redux implementation. You don't get the Redux dev tools and you don't get things like redux-thunk which means you'll have to add that logic to the component and get the component to update the context.
Yes you can totally use the default React APIs for full state management on a project. The introduction of hooks makes it easy to manage. useContext has slowly become my favourite hook because it removes the need for consumers and makes the JSX look a bit nicer.
If you are worried about things rerendering too many times, you can still use all of the tricks in the React Toolbox like React.memo.

What is mapDispatchToProps?

I was reading the documentation for the Redux library and it has this example:
In addition to reading the state, container components can dispatch actions. In a similar fashion, you can define a function called mapDispatchToProps() that receives the dispatch() method and returns callback props that you want to inject into the presentational component.
This actually makes no sense. Why do you need mapDispatchToProps when you already have mapStateToProps?
They also provide this handy code sample:
const mapDispatchToProps = (dispatch) => {
return {
onTodoClick: (id) => {
dispatch(toggleTodo(id))
}
}
}
What is this function and why it is useful?
I feel like none of the answers have crystallized why mapDispatchToProps is useful.
This can really only be answered in the context of the container-component pattern, which I found best understood by first reading:Container Components then Usage with React.
In a nutshell, your components are supposed to be concerned only with displaying stuff. The only place they are supposed to get information from is their props.
Separated from "displaying stuff" (components) is:
how you get the stuff to display,
and how you handle events.
That is what containers are for.
Therefore, a "well designed" component in the pattern look like this:
class FancyAlerter extends Component {
sendAlert = () => {
this.props.sendTheAlert()
}
render() {
<div>
<h1>Today's Fancy Alert is {this.props.fancyInfo}</h1>
<Button onClick={sendAlert}/>
</div>
}
}
See how this component gets the info it displays from props (which came from the redux store via mapStateToProps) and it also gets its action function from its props: sendTheAlert().
That's where mapDispatchToProps comes in: in the corresponding container
// FancyButtonContainer.js
function mapDispatchToProps(dispatch) {
return({
sendTheAlert: () => {dispatch(ALERT_ACTION)}
})
}
function mapStateToProps(state) {
return({fancyInfo: "Fancy this:" + state.currentFunnyString})
}
export const FancyButtonContainer = connect(
mapStateToProps, mapDispatchToProps)(
FancyAlerter
)
I wonder if you can see, now that it's the container 1 that knows about redux and dispatch and store and state and ... stuff.
The component in the pattern, FancyAlerter, which does the rendering doesn't need to know about any of that stuff: it gets its method to call at onClick of the button, via its props.
And ... mapDispatchToProps was the useful means that redux provides to let the container easily pass that function into the wrapped component on its props.
All this looks very like the todo example in docs, and another answer here, but I have tried to cast it in the light of the pattern to emphasize why.
(Note: you can't use mapStateToProps for the same purpose as mapDispatchToProps for the basic reason that you don't have access to dispatch inside mapStateToProp. So you couldn't use mapStateToProps to give the wrapped component a method that uses dispatch.
I don't know why they chose to break it into two mapping functions - it might have been tidier to have mapToProps(state, dispatch, props) IE one function to do both!
1 Note that I deliberately explicitly named the container FancyButtonContainer, to highlight that it is a "thing" - the identity (and hence existence!) of the container as "a thing" is sometimes lost in the shorthand
export default connect(...)
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
syntax that is shown in most examples
It's basically a shorthand. So instead of having to write:
this.props.dispatch(toggleTodo(id));
You would use mapDispatchToProps as shown in your example code, and then elsewhere write:
this.props.onTodoClick(id);
or more likely in this case, you'd have that as the event handler:
<MyComponent onClick={this.props.onTodoClick} />
There's a helpful video by Dan Abramov on this here:
Redux: Generating Containers with connect() from React Redux (VisibleTodoList)
mapStateToProps() is a utility which helps your component get updated state(which is updated by some other components),
mapDispatchToProps() is a utility which will help your component to fire an action event (dispatching action which may cause change of application state)
mapStateToProps, mapDispatchToProps and connect from react-redux library provides a convenient way to access your state and dispatch function of your store. So basically connect is a higher order component, you can also think as a wrapper if this make sense for you. So every time your state is changed mapStateToProps will be called with your new state and subsequently as you props update component will run render function to render your component in browser. mapDispatchToProps also stores key-values on the props of your component, usually they take a form of a function. In such way you can trigger state change from your component onClick, onChange events.
From docs:
const TodoListComponent = ({ todos, onTodoClick }) => (
<ul>
{todos.map(todo =>
<Todo
key={todo.id}
{...todo}
onClick={() => onTodoClick(todo.id)}
/>
)}
</ul>
)
const mapStateToProps = (state) => {
return {
todos: getVisibleTodos(state.todos, state.visibilityFilter)
}
}
const mapDispatchToProps = (dispatch) => {
return {
onTodoClick: (id) => {
dispatch(toggleTodo(id))
}
}
}
function toggleTodo(index) {
return { type: TOGGLE_TODO, index }
}
const TodoList = connect(
mapStateToProps,
mapDispatchToProps
)(TodoList)
Also make sure that you are familiar with React stateless functions and Higher-Order Components
Now suppose there is an action for redux as:
export function addTodo(text) {
return {
type: ADD_TODO,
text
}
}
When you do import it,
import {addTodo} from './actions';
class Greeting extends React.Component {
handleOnClick = () => {
this.props.onTodoClick(); // This prop acts as key to callback prop for mapDispatchToProps
}
render() {
return <button onClick={this.handleOnClick}>Hello Redux</button>;
}
}
const mapDispatchToProps = dispatch => {
return {
onTodoClick: () => { // handles onTodoClick prop's call here
dispatch(addTodo())
}
}
}
export default connect(
null,
mapDispatchToProps
)(Greeting);
As function name says mapDispatchToProps(), map dispatch action to props(our component's props)
So prop onTodoClick is a key to mapDispatchToProps function which delegates furthere to dispatch action addTodo.
Also if you want to trim the code and bypass manual implementation, then you can do this,
import {addTodo} from './actions';
class Greeting extends React.Component {
handleOnClick = () => {
this.props.addTodo();
}
render() {
return <button onClick={this.handleOnClick}>Hello Redux</button>;
}
}
export default connect(
null,
{addTodo}
)(Greeting);
Which exactly means
const mapDispatchToProps = dispatch => {
return {
addTodo: () => {
dispatch(addTodo())
}
}
}
mapStateToProps receives the state and props and allows you to extract props from the state to pass to the component.
mapDispatchToProps receives dispatch and props and is meant for you to bind action creators to dispatch so when you execute the resulting function the action gets dispatched.
I find this only saves you from having to do dispatch(actionCreator()) within your component thus making it a bit easier to read.
React redux: connect: Arguments

React/redux - passing actionCreators many levels deep

I'm wondering how other people are handling passing redux action creators from a smart top-level component down to many lower level dumb components without bloating their props definitions.
For example, following this excellent tutorial on redux, if I pass a list of action creators into the props like so
import Voting from './Voting';
import * as actionCreators from '../action_creators';
...
export const VotingContainer = connect(
mapStateToProps,
actionCreators
)(Voting);
then in my Voting component I have access to the actionCreators which is really cool.
But if I have say 20 actionCreators that are used in Voting and all of its child components, eg.
Voting -> VotingContainer -> VotingDetail -> VotingFoo -> VotingBar
then I end up with render functions that look like this
class Voting extends React.Component {
render(){
<VotingContainer
actionCreator1={this.props.actionCreator1}
.
.
.
actionCreator15={this.props.actionCreator15} />
}
}
class VotingContainer extends React.Component {
render(){
<VotingDetail
actionCreator1={this.props.actionCreator1}
.
.
.
actionCreator12={this.props.actionCreator12} />
}
}
.
.
.
class VotingFoo extends React.Component {
render(){
<VotingBar
actionCreator1={this.props.actionCreator1}
.
.
.
actionCreator6={this.props.actionCreator6} />
}
}
Is there a best practice for this situation, a way to group the actionCreators together somehow without a lot of boilerplate at each step ? I haven't seen anything in any of the tutorials/examples...
Just connect components below the tree to Redux too.
We over-emphasize “one container at the top” in the examples.
This makes sense when we’re talking about very simple apps.
For any complex app, as soon as passing props gets tedious, connect() components below.
I cover this in my free videos: see Extracting Container Components and the next several videos.
I find that in most cases where I have a lot of dumb wrappers around a core ui component, most of the props from the top container are needed in the most nested component.
Because of this, ES6 ... syntax helps a lot.
You can do this:
<VotingBar {...this.props} />
Which is equivalent to this:
<VotingBar
actionCreator1={this.props.actionCreator1}
.
.
.
actionCreator6={this.props.actionCreator6} />
To avoid passing propertied from level to level down to where those props are actually used, React Context could be used to wrap the top Child with context (some specific data).
Codepen Demo
Here's a simple use-case example, where more than one reducer is defined, each of the reducers is responsible for its own state (a counter in this example)
A <Button> is inside a <Modal> and two Modal components are inside App, each one should eventually "broadcast" the change made internally (in the deepest component) to the top component (App) which is actually listening to the changes and acting on them.
Only App cares about changes in Button but since there can be many Button components, the App must know which deep component did what action and dispatch the right data back to Redux.
The Modal is simply something in between which exists for representational purposes only. it doesn't care about any props or state. Button also doesn't care about anything except what is being sent to it directly via the Context. he listen to changes via the Consumer method from React.createContext
const { Provider:ContextProvider, Consumer:ContextConsumer } = React.createContext({});
const {connect, Provider } = ReactRedux;
const {createStore, compose, combineReducers} = Redux;
const {Component} = React;
//// REDUX STORE STUFF /////////////////////////////////////
function reducer_foo(state = {value:1}, action){
if( action.type == 'FOO__SET_VALUE') // type should be unique
return { ...state, value:action.value }
else return state
}
function reducer_bar(state = {value:1}, action){
if( action.type == 'BAR__SET_VALUE') // type should be unique
return { ...state, value:action.value }
else return state
}
const rootReducer = combineReducers({
foo: reducer_foo,
bar: reducer_bar
});
//// REACT STUFF /////////////////////////////////////
// 2nd depth-level
// This component's "job" is to simply take a value and return a manipulated value to
// whoever called it. This is a very simplifed component, but think of a datepicker instead.
const Button = () =>
<ContextConsumer>
{v => <button onClick={()=> v.action(v.value + 1, v.name)}>Click to INC: {v.value}</button>}
</ContextConsumer>
// 1st depth-level (in reality this level will be more complex)
const Modal = () => <p><Button /></p>
// top depth-level component
class App extends Component {
constructor(props) {
super(props);
this.state = {};
}
// The deepest component will pass the value and the name for which to dispatch to
updateValue = ( value, name ) => {
this.props.dispatch({type:`${name.toUpperCase()}__SET_VALUE`, value})
}
render(){
const {foo, bar} = this.props;
return (
<React.Fragment>
<ContextProvider value={{value:foo.value, action:this.updateValue, name:'foo'}}>
<Modal />
</ContextProvider>
<ContextProvider value={{value:bar.value, action:this.updateValue, name:'bar'}}>
<Modal />
</ContextProvider>
</React.Fragment>
)
}
}
function mapStateToProps(state){
return state // in this example let's just pass the whole state for simplicity
}
const ConnectedApp = connect(mapStateToProps)(App)
const store = createStore(rootReducer);
ReactDOM.render(
<Provider store={store}>
<ConnectedApp />
</Provider>,
document.getElementById('root')
)
<script src="https://unpkg.com/react#16/umd/react.development.js"></script>
<script src="https://unpkg.com/react-dom#16/umd/react-dom.development.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/redux/4.0.0/redux.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-redux/5.0.7/react-redux.min.js"></script>
<div id="root"></div>
There are of course a variety of ways you can tackle this issue.
Recently, I've started skipping the whole passing of action creator functions down the chain in favor of just requiring the store and my action creators directly wherever they're needed and dispatching from there, e.g.
var store = require('../store');
var actions = require('../actions');
// Somewhere inside your component...
store.dispatch(actions.someAction(data));
Just make sure the result of your action creators (i.e. the new state) is passed down through your top level components. This keeps your data flow unidirectional and easy to understand.

Resources