Hacker News Reader

Comment by adamkl | Hacker News Reader

To manage state in our React application, we have a "service layer", just like you’d see in a server side application, only these are based on state machines (reactive services based on RxJS observables works as well).

We also created associated custom hooks that allow developers to easily "inject" a service into their React component (we use React's Context API for our "DI container").

From there developers can read the service state to drive the look of the UI, or send events to it to trigger behaviour that is encapsulated in the service itself.

Our most used service is a UserSession service that manages OAuth based login flow and session management.

The best part of this approach is that our service layer started in an Angular based proof-of-concept before we lifted-and-shifted it all into React.

[1] https://xstate.js.org/

View on HN

I wouldn't call it the "best part." It sounds like you took the service focused angular patterns you were using before and shoehorned them into a React application.

How comfortable would you be allowing an outside dev to hack on your codebase without a _long_ conversation beforehand explaining the idiosyncrasies?

From my view point, we “shoe-horned” a React UI into a well-established pattern for building an application.

I guess it depends on the vintage of the developer. I would argue that Redux is an idiosyncratic technique for state management, and by breaking it apart into separate services, you get better separation of concerns.

I should point out though, that our “service layer” follows the same event-driven flow that you would see with Redux, but by breaking it up into state machines we can be more explicit about the states of our application.

“Service layer” doesn’t have to be a dirty word. Redux is a stateful, reactive service, and so are the xState machines we are using. Logically speaking, I don’t see much of a difference.

As for the _long_ conversation you mention, in my experience, it’s actually been a pretty short conversation followed by gratitude at not having to use Redux. I really don’t meant that as a slight towards Redux, which is a very elegant solution, but seriously, the people I’ve introduced to xState just like it better.

Are you guys using xState entirely as your data store, or using something else in conjunction like MobX or Redux?

Just xState. Each machine is responsible it’s own piece of the global state pie by using its internal `context`.

This allows a similar approach to redux’s actions and reducers (or events and `assign` for xState), but each machine can focus on its area of responsibility and enforce its behaviour through defined state transitions.

This approach also makes it easy to coordinate between multiple services (e.g. having the “NavigationService” change which links should be available by listening to a state change on the “UserSession” service as a user becomes authenticated.

This started as a bit of an experiment to see what a stateful UI “service layer” might look like, but as we’ve progressed, we haven’t found a need for anything else like redux or mobx.

> e.g. having the “NavigationService” change which links should be available by listening to a state change on the “UserSession” service as a user becomes authenticated.

Could you expand on how you're achieving this? I'm creating a new project using xState at work and this is one of the things I've been trying to come up with a solution too.

My biggest problem is the pattern I've set up for routing on top of xState (It's an electron app so no URL management required which makes that easy) requires you to create the state machine yourself, so it can't for example be used as an actor in part of a larger system.

It sounds like your NavigationService and UserSession service might be similarly separated so I'm curious how they're communicating?

Something that occurred to me last night is that I can probably make a coordinator of some sort somewhere in the tree which forwards actions from state machine to another as required.

We keep things very simple. Maybe that will have to change as the code base grows, but for now it works and it easy to grok.

On start of the application we create singletons of our state machine backed services, and manage the dependencies between them manually. That is, we create an instance of the UserSessionService and then pass it into a "constructor" for the NavService. That constructing function creates the NavService and then wires them together by subscribing the NavService to listen to the state transitions of the UserSessionService.

I suppose if the code base grows and you have dozens of services to keep track of, it will get pretty unwieldy, but that is no different than using a fancy IOC container in Java/.Net. We plan on keeping things simple, while still braking apart the single store you'd have with Redux.

I hacked together a simple gist to show the basics of how we wire things together (without getting into the specifics of how the internals of the state machines work). [1]

[1] https://gist.github.com/adamkl/656008691d42220eddf8bfe147753...

That does help clarify things, thanks :) For context I'm just starting out this app so it's simple for now, but this is my first major project with xState so I'm trying to come up with sensible patterns.

I'll have a think about this and see if I can work it into my structure as I'm certainly going to need inter-machine communication as it grows.

The `makeMachineRoutable` function in this gist is what I'm using to consume my state machines in React. https://gist.github.com/UberMouse/49ff91e95390265d63d3ac1bc7...

It also shows my prototype for xstate based declarative data fetching, though I have sinced switched to using observables instead of promises for representing my GraphQL query results so I've changed it quite a bit.

I love the sound of this, do you have a link to any examples?

https://news.ycombinator.com/item?id=22294087

Reply on news.ycombinator.com