An NgRx based State Machine for Angular Components - Part 3
As mentioned in the second part of this article, we initially used object literals to specify the state machine setup for a given component but this object was not easy to structure and difficult to read. To improve the setup and readability we set up a fluent style builder.
Once the component has specified the state transitions that it is interested in the next step is to register these with a component state service.
The above service still does some restructuring of the state data into a more machine readable format. This is left over from when we were specifying the state date as object literals in the components. It would now be possible to have the fluent builder structure the object in the correct format, and the service would then be even simpler, just inserting the state data as received. For reasons of maintaining backwards compatibility with some older components we haven't got around to doing this yet.
In the fourth and final article in this series I will show how the central state machine handles the flow of actions based on the registered component states.
Once the component has specified the state transitions that it is interested in the next step is to register these with a component state service.
The above service still does some restructuring of the state data into a more machine readable format. This is left over from when we were specifying the state date as object literals in the components. It would now be possible to have the fluent builder structure the object in the correct format, and the service would then be even simpler, just inserting the state data as received. For reasons of maintaining backwards compatibility with some older components we haven't got around to doing this yet.
In the fourth and final article in this series I will show how the central state machine handles the flow of actions based on the registered component states.
Comments
Post a Comment