0

I've been using Redux for most of my React applications.

I think I will start using XState as I don't have to use effects as a plugin all the time.

And I think is a more complete pattern.

One thing that I want to understand is it's connection with React (hooks and classes) and it's interaction with reactive programming in general:

Can I (and should I) use XState context as Redux data store in the same way, having a single source of truth on a shared by React Components way? Will my components be able to "connect" and "mapToProps" the XState context and rerender only when those values changes and not every time the state machine state changes?

From what I understand Redux lacking side effects is so it can adhere to a pure functional paradigm. But that breaks with side effects usage, that is a lot of times needed in web apps or games for example.

Thanks in advance!

Rui d'Orey
  • 982
  • 3
  • 13
  • 31

1 Answers1

4

XState can basically manage your global state in Redux (or other state management libraries) if you want to, but it won't replace connecting with React as Redux does. You should view it as an extension to Redux and you would still need to follow the patterns used in Redux, but use XState to perform them. A few examples:

  • Redux state can be represented as anything, so it can be a XState machine state + XState machine context.
  • Redux actions should basically trigger XState machine transitions. They can also trigger async actions (https://xstate.js.org/docs/guides/communication.html#invoking-promises), so you might not need something like redux-thunk to deal with that. You actions will become much simpler, but the actual handling is moved to the machine.
  • Redux reducers usually return a new state, therefore they are the outcome of a XState transition.

You can probably find a way to connect this all together (did a similar thing with Vuex recently). The XState machine would simply be a singleton called from Redux entities, but you would not "embed" the machine inside Redux.

You would also still need to use the react-redux tools as before and the machine would never really be exposed to the actual React components (except you want to use XState machines for local state as well).

Torsten Engelbrecht
  • 13,318
  • 4
  • 46
  • 48
  • But can't I just make an HOC to do the same as `react-redux` `connect()` and map *XState*'s `send` and parts of the `context` to React's `props`?Or there is better way to do this on XState? XState already seems to have a good integration with Redux Dev tools by itself. – Rui d'Orey May 15 '20 at 14:25
  • @Ruid'Orey You can replicate what `react-redux` does. The connect method really does not that much and you could reimplement it and hook it up with XState under the hood instead of the Redux store. You would still end up reimplementing quite a bit around it and make sure it works. The easier way is definitely to simply wrap Redux core functionality around XState and let the state machines do the heavy lifting, while the Redux basic building blocks are just a thin layer around it and ensure your application is reactive to changes. – Torsten Engelbrecht May 16 '20 at 06:23
  • @TorstenEngelbrecht - I was struggling to understand how I could use xstate context for all my data, but now I realise with your answer, that we still manage our data outside of xstate, but the application state is in xstate correct? – Neil Nov 30 '20 at 15:21
  • 1
    @Neil To a degree. An XState machine isn't really something which stores your data, but is mostly used to define "transitions" of your data. Given you have state X with data a, b and c the machine offers you a deterministic way to define what that data would look like after you transition to state Y, lets say a', b' and c'. Storing the data and making it accessible application wide is not inside of a machine and has to be handled by the solution you are using (e.g. Redux, Vuex, etc). – Torsten Engelbrecht Dec 01 '20 at 22:52