Replies: 4 comments 1 reply
-
Hey @Ragzzy-R - if you're using XState v5, the strategy for migrating away from XState (at least the state machine part of it) would be to use simpler actor logic creators! For example, if your logic can be succinctly expressed as a plain "reducer function" instead of a state machine, you can use the import { fromTransition, createActor } from 'xstate';
const countLogic = fromTransition((state, event) => {
switch (event.type) {
case 'increment': {
return { count: state.count + 1 };
}
case 'decrement': {
return { count: state.count - 1 };
}
default: {
return state;
}
}
}, { count: 0 }); // Initial state
const countActor = createActor(countLogic);
countActor.subscribe(snapshot => {
console.log(snapshot.context);
});
countActor.start();
// logs { count: 0 }
countActor.send({ type: 'increment' });
// logs { count: 1 }
countActor.send({ type: 'decrement' });
// logs { count: 0 } Since it would use the same XState API ( From there, if you really want to, it's simple to do an additional migration step to move that logic out of XState and into something like Zustand, |
Beta Was this translation helpful? Give feedback.
-
Hello @davidkpiano Thanks for the swift reply. I guess I should have mentioned that we are in V4. I can see how V5 is more actor oriented and is more easy to migrate away. Not sure how to do this in V4. if you could provide some insights on it, that'd be great. on a side note, would it be easier to migrate to V5 first then to something else? rather than migrating away from V4? if so, please let me know if there are some migration guide for it. |
Beta Was this translation helpful? Give feedback.
-
Hey @Ragzzy-R (cc. @Marwa-Da) - We have just released XState Store ( It is an alternative to XState only if your app logic is simple enough that it doesn't need a state machine or other powerful features of XState. It is most directly comparable to Zustand. I would recommend you use that because the migration path can end up being pretty straightforward, without having to change a lot of code to satisfy the APIs of different state management libraries. |
Beta Was this translation helpful? Give feedback.
-
Hello @davidkpiano , thanks for following this up! We haven't done the migration because this is a big undertaking and we don't have the resources for it at the moment. but the Xstate Store looks interesting. I will look at it and get back to you guys with more questions in a few days. Thanks again :) cc: @Marwa-Da |
Beta Was this translation helpful? Give feedback.
-
Hello!
This might sound a bit controversial. But at my work, I'm trying to migrate away from XState and would like to know some migration strategies for it. Please note that I do not have any issues with XState its just our product doesn't need the kind of power XState gives as it is a relatively simple application and hence we want to reduce the complexity by removing XState.
A little background
Our product is a fairly medium sized application which is a customer onboarding application. It uses React, XState, Apollo and Graphql. The app has multiple branches of user journey based off certain business rules. For example. Say if a User is from NY, we have a particular user journey and UI for them. if a user is from CA but also say a Veteran, then they have a different user flow and so on. say we have a dozen or so conditions like this that makes the onboarding journey almost same but also slightly different for different users. For example, say if they are a veteran we ask them for some extra detail so we show them a form while others don't get to see that page. Initially we thought that its a nice way to have a state machine branch off into these scenarios neatly and hence chose XState.
Pain points
Currently, the problem is, XState is just way too sophisticated for our needs. While it look like we are transitioning to multiple state, most of it just boils down to one or two top level conditions which could easily be done with simple routing. There is really no complicated state transitions that actually need the sophistication of XState.
Also, There are other pain points like learning curve, boilerplate code etc which would have been totally justified if our app actually had that kind of complexity.
So, We have decided to migrate away from XState for something simpler to maintain the app state like zustand(or maybe just contexts?) while apollo(or react query) handles server states.
Although, I'm lost on how to do this migration without rewriting the entire app because of how much Xstate code is in the codebase. I'd love to know if anyone has done this kind of effort or if you could suggest me some ideas/resources on getting me some initial directions on this. Do let me know if you need more information.
Thanks and Regards
Beta Was this translation helpful? Give feedback.
All reactions