The App wrapper would need to implement the hooks and actions itself, and then pass them down via Context or props so child components could access the correct data and actions in the store. So with a shared store, this architecture was at risk of becoming very complex. In our initial prototype it implemented it's own store and Redux's Provider component so the child components could implement Redux hooks directly. It acts as a container and wraps the layout and components. Our architecture has a top level App component which is unique for each search application. A useSelector hook allows it to retrieve the current page, and a useDispatch hook allows it to call an action which updates the current page. It needs to keep track of which page a user is currently on, as well as update the current page. The initial build featured a suite of reusable components that each implement useDispatch and useSelector to act on their independent state management. Redux's excellent dev tools stopped functioning as intended, and the dev tools being a big driving point behind using Redux in the first place - meant we had to rethink our implementation. However, it quickly became apparent that Redux had not been designed to work this way. The choice of using separate stores allowed us to easily reuse React components that implemented Redux's useSelector hook to retrieve data from the store. In Redux there can only be one store, and we put this to the test with an initial prototype that threw caution to the wind and used a separate store for each application. Whilst developing a recent project which utilises an Elasticsearch backend to provide a number of independent search interfaces, a need came up to have very similar state management for each application. This article assumes an understanding of (on the React side) Context, hooks, components, (and on the Redux side) actions & reducers, Redux hooks, and at least a little dabble in Redux Toolkit.
0 kommentar(er)
