One example of application state would be a list of customers or products maintained in an application.<\/p>\n\n\n\n
Problem (we’re trying to solve)<\/h3>\n\n\n\n
Think of an application using a list of data (products, customers, …). This list is the state that we are trying to manage. <\/p>\n\n\n\n
Some API calls and user inputs could change the state ( i.e. the list ) by adding or removing items\/entries. The state change should be reflected in the UI and other dependent components. <\/p>\n\n\n\n
We could solve this with a global variable to hold the list and then add\/remove customers from\/to it and then write the code to update the UI and dependencies. But, there are many pitfalls in that design which are not the focus of this article. <\/p>\n\n\n\n
Solutions<\/h3>\n\n\n\n
Currently there are several state management libraries for Angular apps: NGRX<\/a>, NGXS<\/a> or Akita<\/a>.<\/p>\n\n\n\n RxJS is a library for reactive programming using Observables, to make it easier to compose asynchronous or callback-based code. This project is a rewrite of Reactive-Extensions\/RxJS with better performance, better modularity, better debuggable call stacks, while staying mostly backwards compatible, with some breaking changes that reduce the API surface<\/p>\n\n\n\n Vorschau(\u00f6ffnet in neuem Tab)<\/a><\/p>\n\n\n\n Store is RxJS powered state management for Angular applications, inspired by Redux. Store is a controlled state container designed to help write performant, consistent applications on top of Angular.<\/p>\n\n\n\n Key concepts<\/strong><\/p>\n\n\n\n Akita is a state management pattern, built on top of RxJS, which takes the idea of multiple data stores from Flux and the immutable updates from Redux, along with the concept of streaming data, to create the Observable Data Stores model<\/strong>.<\/p>\n\n\n\n Akita<\/strong> encourages simplicity. It saves you the hassle of creating boilerplate code and offers powerful tools with a moderate learning curve, suitable for both experienced and inexperienced developers alike.<\/p>\n\n\n\n Akita<\/strong> is based on object-oriented design principles instead of functional programming, so developers with OOP experience should feel right at home. Its opinionated structure provides your team with a fixed pattern that cannot be deviated from.<\/p>\n\n\n\n NGXS is a state management pattern + library for Angular. It acts as a single source of truth for your application’s state, providing simple rules for predictable state mutations.<\/p>\n\n\n\n NGXS is modeled after the CQRS pattern popularly implemented in libraries like Redux and NgRx but reduces boilerplate by using modern TypeScript features such as classes and decorators.<\/p>\n\n\n\n State is basically everything that will define the UI that our user will be using. State could be whether a button should be visible or not, it could be the result of that button click and it could also be an This big variety of what state could be, how long it lives and where it comes from results in complexity that we need to manage.<\/p>\n\n\n\n State management is the concept of adding, updating, removing and reading pieces of state in an application. When we have deeply nested data structures and we want to update a specific part deep down in the tree, it might become complex. In that case we have state management libraries that contain a Combining state management together with reactive programming can be a really nice way to develop single-page-applications. Whether our focus lies on Angular, Vue or React, combining these two principles will result in more predictable applications.<\/p>\n\n\n\n Now what has state to do with reactive programming? A piece of state can change over time, so in a way we are waiting for new state changes. That makes it asynchronous.<\/p>\n\n\n\n Let\u2019s take this example for instance:<\/p>\n\n\n\n The The We can either use a Before we dive deeper in state, there are 2 important principles that we should follow when managing state. The first principle is immutability<\/strong>, which means that we should never mutate data directly without creating a new reference of that object. If we mutate data directly, our application becomes unpredictable and it\u2019s really hard to trace bugs. When we work in an immutable fashion we can also take advantage of performance strategies like the ChangeDetection.OnPush<\/a> from Angular or React its PureComponent<\/a>.<\/p>\n\n\n\n When we use typescript we can enforce the typescript compiler to complain when we mutate data<\/p>\n\n\n\n In the previous example we have overwritten the Arrays can be handled like this:<\/p>\n\n\n\n the The second principle is Unidirectional data flow<\/strong>. In a nutshell, this means that we should never use two-way data binding on state. It is the absolute owner of that specific piece of state that is in charge of updating it (immutable of course).<\/p>\n\n\n\n Both of these principles are highly enforced by the Redux<\/a> pattern.<\/p>\n\n\n\n Often forgotten, but one of the most important pieces of state a web application can have. Putting state in the route gives us the following advantages:<\/p>\n\n\n\n Tip<\/strong>: Instead of handling modals with a Every component could contain state. That state could be shared with its dumb components or could be used in the component itself. Eg: When an Personally, I try to avoid state management frameworks for managing component state because it\u2019s the responsibility of that component to manage that state. There are however good reasons to use state management frameworks to manage component state:<\/p>\n\n\n\n If the state management of the component becomes a bit too complex and we don\u2019t want to use a state management framework just yet, we could use a state reducer in the component itself.<\/p>\n\n\n\n Persisted state, is state that is being remembered when the user navigates between different pages. This could be whether a sidebar was collapsed or not, or when the user returns to a grid with a lot of filters and he wants them to be remembered and reapplied when he returns. Another example is a wizard with different steps, and every step needs to be persisted so the user can navigate back and forth and the last page is a result of all these steps.<\/p>\n\n\n\n Persisted state is the type of state where we typically use a state management framework for, that being said, if we don\u2019t want to rely on an external dependency we can also manage it in a Angular When we are talking about shared state, we are talking about state that needs to be shared between different parts of our application. State that is being shared throughout different smart components. This means that the instance of this piece of state should live on a higher level, than the components that want to consume it.<\/p>\n\n\n\n Shared state can be managed in a state management framework like Redux<\/a>, Ngrx<\/a>, Akita<\/a>, Ngxs<\/a> and so on, but if that state is small and simple we can also manage it manually. Let\u2019s say that we want an Simple right, one line of code?! For this we don\u2019t need<\/strong> a state management framework, although it can also have its benefits. Some developers like to keep all their master data in a Now that we know what state is, we have to ask ourselves which state needs to be managed, and where do we manage that state? In a component, singleton service or a framework (Store)?<\/p>\n\n\n\n This is the part where the strong opinions surface. I would suggest to use what works for you and your team and really think about, but here are my personal opinionated<\/strong> guidelines:<\/p>\n\n\n\n However, there is also a popular opinion out there to put literally everything in the store which has the following advantages:<\/p>\n\n\n\n However, there are a few downsides as well:<\/p>\n\n\n\n Introduction One of the most challenging things in software development is state management. Motivation What is a state (or application state)? Theoretically, it is the entire memory of the application, but, typically, it is the data received via API calls, user inputs, presentation UI State, app preferences, etc. It is the data that can differentiate two instances of the same application. One example of application state would be a list of customers or products maintained in an application. Problem (we’re trying to solve) Think of an application using a list of data (products, customers, …). This list is the state that […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[90,69],"tags":[],"class_list":["post-5722","post","type-post","status-publish","format-standard","hentry","category-angular","category-rxjs"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/posts\/5722","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/comments?post=5722"}],"version-history":[{"count":0,"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/posts\/5722\/revisions"}],"wp:attachment":[{"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/media?parent=5722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/categories?post=5722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/via-internet.de\/blog\/wp-json\/wp\/v2\/tags?post=5722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}RxJS – Reactive Extensions Library for JavaScript<\/a><\/h4>\n\n\n\n
@ngrx\/store<\/a><\/h4>\n\n\n\n
Store<\/a><\/code>, an observable of state and an observer of actions<\/li><\/ul>\n\n\n\n![\"NgRx](\"https:\/\/ngrx.io\/generated\/images\/guide\/store\/state-management-lifecycle.png\")
<\/figure>\n\n\n\nAkita<\/a><\/h4>\n\n\n\n
![\"\"](\"https:\/\/i1.wp.com\/blog.via-internet.de\/wp-content\/uploads\/2020\/01\/akita-arcitecture.jpg?fit=700%2C394&ssl=1\")
<\/figure>\n\n\n\nNGXS – State management pattern + library for Angular<\/a><\/a><\/h4>\n\n\n\n
Introduction (taken from here<\/a>)<\/h2>\n\n\n\n
What is state?<\/h3>\n\n\n\n
Array<\/code> of users that is coming from an API. State can live in different places throughout our entire application. Some state is very specific to a certain component where other state might be shared in different parts of our application. One piece of state could be a singleton instance, where a another piece of state could share the limited lifespan of a component that can be destroyed at any time.<\/p>\n\n\n\nWhat is state management?<\/h3>\n\n\n\n
Store<\/code> which helps us with state management to get rid of that complexity. A quick note, we have to be careful that these libraries don\u2019t add complexity by overusing them.<\/p>\n\n\n\nReactive state<\/h3>\n\n\n\n
\/\/ false------true-----false---true...\nsidebarCollapsed$ = this.state.sidebarCollapsed$<\/pre>\n\n\n\n
sidebarCollapsed$<\/code> stream starts out with false<\/code>, later on it becomes true<\/code> and so on. This stream keeps on living. In Angular this state can be consumed with the async pipe<\/a> as easy as:<\/p>\n\n\n\n<my-awesome-sidebar *ngIf=\"sidebarCollapsed$|async\">\n<\/my-awesome-sidebar>\n<\/pre>\n\n\n\n
async<\/code> pipe will subscribe to the sidebarCollapsed$<\/code> pass it to the component, mark it for check and will automatically unsubscribe when the component gets destroyed. Keeping state in an observer pattern is nice because we can subscribe to the changes. Oh, and did I mention it plays super nice with Angular?<\/p>\n\n\n\nBehaviorSubject<\/code> or state management frameworks that support Observables. Here are some really great ones with Observable support:<\/p>\n\n\n\nImmutability and Unidirectional data flow<\/h3>\n\n\n\n
type Foo = {\n readonly bar: string; \n readonly baz: number; \n}\n\nlet first = {bar: 'test', baz: 1};\nfirst.bar = 'test2'; \/\/ compilation error\nfirst = {...first, bar: 'test2'}; \/\/ success<\/pre>\n\n\n\nfirst<\/code> instance with an entire new instance that has an updated bar<\/code> property.<\/p>\n\n\n\nlet arr = ['Brecht', 'Kwinten'];\narr.push('John'); \/\/ BAD: arr is mutated\narr = [...arr, 'John']; \/\/ Good, arr gets new reference<\/pre>\n\n\n\nArray<\/code> prototype also has some great helper functions that we can use to enforce immutability like map()<\/code> and filter()<\/code> but this is not in scope for this article.<\/p>\n\n\n\nWhat kind of states are there?<\/h3>\n\n\n\n
Router state<\/h4>\n\n\n\n
userDetailModalVisible<\/code> property, why not enjoy all the benefits mentioned above and bind it to a users\/:userId<\/code> route? Using a child router-outlet<\/code> in Angular makes this a piece of cake as we can see in this snippet.<\/p>\n\n\n\n<table>\n<!--contains users -->\n<\/table>\n<router-outlet>\n<!-- user detail modal rendered in here -->\n<\/router-outlet>\n<\/pre>\n\n\n\n
Component state<\/h4>\n\n\n\n
ItemComponent<\/code> has a property selectedItems<\/code> which is an array of ids, and that array is never used in other components (that aren\u2019t children of that component), we can consider it component state. It belongs to that component, therefore the component should be responsible for it. Child components can consume that state but should never mutate it<\/em>. Those components can notify their parent that is responsible for it, which could update it in an immutable way. For more information about smart and dumb components look here<\/a>.<\/p>\n\n\n\nPersisted state<\/h4>\n\n\n\n
service<\/code> which can be a singleton that is shared throughout the entire application. If that service<\/code> becomes too complex or there is a lot of state to manage, I would consider to put that state into a state management framework.<\/p>\n\n\n\nShared state<\/h4>\n\n\n\n
Observable<\/code> of an Array<\/code> of countries that we need to share throughout the entire application. In Angular we could have a CountryService<\/code> that fetches the countries from the API once, and then shares it throughout the entire application. For that we can use the shareReplay<\/code> operator from RxJS.<\/p>\n\n\n\nexport class CountryService {\n ...\n countries$ = this.httpClient.get('countries').pipe(shareReplay(1));\n}<\/pre>\n\n\n\nRedux<\/code> store, and that\u2019s fine. Just know that we don\u2019t have to. I like to develop by the KISS<\/strong> principle (K<\/strong>eep I<\/strong>t S<\/strong>imple S<\/strong>tupid) as much as possible, so I favor this approach many times. Think about the amount of lines of code we saved by this approach. Beware that every line of code we write, not only needs to be written but also maintained.<\/p>\n\n\n\nWhich state needs to be managed?<\/h3>\n\n\n\n
shareReplay<\/code> operator.<\/li>getById<\/code> API call into a store if there is no one consuming that state except for the component requesting it<\/li>countries$<\/code> example we would have to write an: action<\/code>, actiontype<\/code>, effect<\/code> and a reducer<\/code>.<\/li>currentUserToEdit<\/code> in the store, we have to get it out when we navigate away<\/li>async<\/code> pipe to cancel pending XHR requests<\/li>More to read<\/h2>\n\n\n\n