What that action does is not the concern of the component, and so it does not need to be tested with the component.This is all an order of magnitude simpler than the previous state management.Īs mentioned previously, if there is a downside to using the Redux pattern with NgRx, it is that is more complex to use and learn.
#Omniplan software update
When we expect a component to update the state we only need to test that the action is fired correctly, not that the state is updated. And we can test that selectors will return just the small slice that we need.
We can test that actions and effects will update the state as we want, and that the outcome if what we expect. We can mock our state, and ensure that when we have a known data state a component will behave in a certain way. A component cannot simply update a random part of the state - but instead has to call an action that will cause it to be updated.Īll of these make testing much simpler and less awkward. This means that we are never accessing the entire state, in a random way, in our components.Īs the state cannot be updated directly, but rather you need to use actions, effects and reducers in order to do so means that we also have greater control over how and when the state changes. By using selectors we allow access to only that part of the state that is needed. It is both one single store, and split into modules that only know about the part of the state they have responsibility for - ensuring that each module has responsibility for it’s own data, and never changes another modules data. So… No only did we not have automatic checks in place, but every single component could damage every single piece of data - and no one would know That meant that anyway it was used could also update the data.
#Omniplan software manual
These were super awkward!Īs well as this context service making it difficult to do any kind of automatic checks - meaning that every change needed complete manual regression testing to be sure that nothing had broken, the data inside of the service had no protection. And as it was strongly typed it made testing those components a nightmare! Because to inject the test service it needed to be complete. A service that contains everything needed for the application, and was injected into almost every component that we used. Previously this problem was solved by use of a “context” service. We had a lot of data floating around, data that was needed in many different components and in many different combinations. This is a problem that we were facing with our previous Angular user interface to our platform. "If you think that state management is easy, then think how many times you have fixed a problem by turning your computer off and on again."
0 kommentar(er)
