Once you’ve got the output you are looking for (you’ve got unit tests to prove that the code is correct, right?) begin refactoring, but don’t go too far too fast! For now, stick with refactoring strategies that are in the category of proper naming, functions doing only one thing, and the avoidance of mutation; don’t immediately start making extensible or reusable classes and factories until you have identified a repeating pattern.
Get it all out there into that function. At first don’t worry too much about naming, single responsibility, or being extensible — you’ll address that once your function is working. To be clear, you won’t be writing your whole application like this, just one small piece.
The other way I see selectors not being used is in the effects. Often I will need additional data from the store, so I will use a selector in my component to get it so I can pass it with my action. The data is completely unrelated/unused by my component and only needed by my dispatched action. In this case, don’t have the component use a selector to retrieve it only to pass it along as that will required a subscription to extract the value and it’s not needed elsewhere. A better approach to consider would be to use `withLatestFrom(store.pipe(select(mySelector))`. This allows you to get the previous value from the store as necessary, simplify your actions, and r…
Another problem with nested data is a result of good component design. When we think about our applications, we start with a top level app component, which renders a page component, which renders a bunch of child components, which are often nested multiple layers deep to reduce complexity and promote reusability. The component pattern often follows the container/presenter model and allows us to create reactive forms/pages. This is a great pattern to follow and I teach it often to developers of all levels. The problem with this is that since the data in the store is immutable, if I change a single property on a nested object, the whole state object has to change, and thus forcing a rerender of potentially hundreds of components. This is a big performance issues and can easily be avoided.
but can happen only once per level. This is to avoid any infinite redirec…ch route whose
path matches that segment, the router checks if that path has a
redirectTo property. Redirects can happen at each level of nesting in the router config tree, but can happen only once per level. This is to avoid any infinite redirect loops.
…m (read more here). Angular asks you to think about it as if all component have their own injector. What gets injected into a component depends on the components provider settings as well as the providers of the parent components higher in the overall component tree. So there is the catch; components inherit the service instance of their parent (or parent’s parent and on up). But, if a component adds a service reference to its list of providers that the parent also injects, a new service instance will be instantiated that does not share state with the parent’s service.