Thanks Florian, I need to read this over again, and again. Reason: I'm not sold on farming off state management as this is only a recent concept with redux etc.
A few Questions if you don't mind
Do you find State Management as its own concern improves our developer lives? Does it make the whole state thing go smoother, faster, easier? How do this tie in with FormControls in Angular?
Software engineer, I've been working with Angular for 6 years now and strive to work more full stack. I publish on dev.to about topics I love around open source, frontend, data privacy, automations.
Hi John. At least my developers life became more fun with state management. I started out with NgRx and was quite happy with it. In NgRx you also work with immutable data and state changes happen explicitly (with dispatching an Action). In the simple StateService in this article we have a similar explicitness with using setState inside public API methods. That helps to understand/debug where certain state changes come from.
In NgRx you have the principle of Single Source of Truth. It means that there is just one place (Store) which holds the complete application state object. That way you always know where to find/query the state data. The simple StateService has a similar purpose. Services which extend the StateService are also the Single Source of Truth for a specific feature (e.g. the TodosStateService is the Single Source of Truth for everything related to Todos).
With immutable data and Observables it is easily possible to use ChangeDetectionStrategy.OnPush which will improve performance (if you have a lot of components).
Also when working in a Team it is great to have a state management solution in place, just to have a consistent way of updating/reading state that every one can simply follow.
Regarding Form Controls... Ideally the component which holds the form does not know about state management details. The form data could flow into the form component with an @Input() and flow out with an @Output() when submitting the form. But if you use a Facade then the form has no chance to know about state management details anyway.
There is one important thing to keep in mind: Template Driven Forms which use two-way-binding with [(ngModel)] can mutate the state. So you should use one-way-binding with [ngModel] or go for Reactive Forms.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks Florian, I need to read this over again, and again. Reason: I'm not sold on farming off state management as this is only a recent concept with redux etc.
A few Questions if you don't mind
Do you find State Management as its own concern improves our developer lives? Does it make the whole state thing go smoother, faster, easier? How do this tie in with FormControls in Angular?
I'll let OP reply to other questions but to tie some data to an angular form you could give a go to dev.to/maxime1992/building-scalabl...
Hi John. At least my developers life became more fun with state management. I started out with NgRx and was quite happy with it. In NgRx you also work with immutable data and state changes happen explicitly (with dispatching an Action). In the simple StateService in this article we have a similar explicitness with using
setStateinside public API methods. That helps to understand/debug where certain state changes come from.In NgRx you have the principle of Single Source of Truth. It means that there is just one place (Store) which holds the complete application state object. That way you always know where to find/query the state data. The simple StateService has a similar purpose. Services which extend the StateService are also the Single Source of Truth for a specific feature (e.g. the TodosStateService is the Single Source of Truth for everything related to Todos).
With immutable data and Observables it is easily possible to use ChangeDetectionStrategy.OnPush which will improve performance (if you have a lot of components).
Also when working in a Team it is great to have a state management solution in place, just to have a consistent way of updating/reading state that every one can simply follow.
Regarding Form Controls... Ideally the component which holds the form does not know about state management details. The form data could flow into the form component with an
@Input()and flow out with an@Output()when submitting the form. But if you use a Facade then the form has no chance to know about state management details anyway.There is one important thing to keep in mind: Template Driven Forms which use two-way-binding with
[(ngModel)]can mutate the state. So you should use one-way-binding with[ngModel]or go for Reactive Forms.