NgRx also makes testing easier and the architecture more straightforward. Components in a Redux/NgRx architecture only responsible for rendering and dispatching events. All the data alternation implemented in pure functions so-called effects and reducers. No intertwined components, side effects just easily testable pure functions.
+1 (non-binding) On Tue, Nov 27, 2018 at 5:09 PM Shane Ardell <shane.m.ard...@gmail.com> wrote: > There are a couple of good examples in Metron Alerts showing different > advantages we would gain using NgRx. First, you’ll notice that a lot of > state does not persist between view changes. For example, if a user inputs > search criteria into the search bar, switches to the PCAP view, then > switches back, that search input is not persisted. If we used NgRx, the > application store can persist this state between view changes if we wanted > to. The importance of this will continue to become more apparent as the > application scales up and different views are added. > > In addition, there is quite a bit of shared application data between > components. For example, you’ll see that both the GroupByComponent and > AlertFiltersComponent display the number of facets available. When you > filter by a facet, these numbers update. You can filter by clicking on the > facets available in the AlertFiltersComponent, or you can search with a > filter keyword and value in the search bar. Multiple areas of the > application are showing the same data, and multiple areas of the > application are manipulating that data. While passing data through @Input > and @Output decorators and services is fine for basic sharing of > application data, you’ll eventually create a complex web of data sharing > and mutation that can be hard to follow and debug. In my opinion, we are > nearing that point in our application. NgRx solves this with its > one-direction data flow and immutable data structures. The store is the > single source of truth which your component derives state from rather than > having components holding their own state and having to manage, communicate > and pass data between them. > > There are also many debugging advantages. I don’t have a specific example > at the moment, but you can probably imagine how much easier it is to “time > travel” with NgRx debugging tools. What I mean by “time travel” is the > ability to move back and forth among the previous application states and > view the results in real-time rather than setting a breakpoint, reloading > the application, inspecting, setting another breakpoint to inspect a state > previous to your current breakpoint, reloading the application, etc. This > is a very repetitive and time-consuming thing to do when debugging on the > front-end, and is very common. For a visual example of this, here is a > video containing a decent overview of debugging with NgRx: > https://www.youtube.com/watch?v=70ojPxMA7Ig > > On Tue, Nov 27, 2018 at 5:30 AM James Sirota <jsir...@apache.org> wrote: > > > I found a helpful article here: > > https://brianflove.com/2018/01/08/ngrx-the-basics/ > > > > A lot of this goes over my head, but in a nutshell, it's a tree-based > > state management object for JS. Its main drawback seems to be added > > complexity, but if the guys who are more familiar with UI say we would > > benefit from it I am inclined to take them at their word. > > > > 26.11.2018, 13:09, "Michael Miklavcic" <michael.miklav...@gmail.com>: > > > Shane, thanks for sharing this. Can you perhaps describe a sample use > > case > > > in the UI currently and explain for us how it currently works (or > > doesn't, > > > ha) versus how it would be modified and improved with using NgRx? > > > > > > Thanks, > > > Mike > > > > > > On Fri, Nov 23, 2018 at 7:44 AM Shane Ardell <shane.m.ard...@gmail.com > > > > > wrote: > > > > > >> What I'm referring to is roughly the entire contents of the UI > > >> application's memory. > > >> > > >> On Thu, Nov 22, 2018 at 6:29 PM Otto Fowler <ottobackwa...@gmail.com > > > > >> wrote: > > >> > > >> > Can you describe what you mean by “state” in a little more detail? > > Not a > > >> > complete description, maybe just a crib list. > > >> > > > >> > > > >> > On November 22, 2018 at 07:21:43, Shane Ardell ( > > shane.m.ard...@gmail.com > > >> ) > > >> > wrote: > > >> > > > >> > As both the Management and Alerts UI grow in size, managing > > application > > >> > state continues to become more and more complex. To help us deal > with > > >> > managing all of this state and ensuring our application derives > state > > >> from > > >> > a single source of truth, I suggest we start using NgRx, a state > > >> > management > > >> > library based on the Redux pattern but built for Angular. It is by > > far > > >> the > > >> > most popular library of this type for Angular. As you can see in > the > > >> > project's GitHub Insights tab < > > https://github.com/ngrx/platform/pulse>, > > >> > it's quite actively worked on and releases are pretty frequent. The > > >> > project > > >> > is licensed under MIT. > > >> > > > >> > As far as an approach to integration, I don't think we necessarily > > need a > > >> > big refactoring right off the bat. I feel something like this can > be > > done > > >> > in a piecemeal approach over time. I think we can start by > > introducing it > > >> > into the project the next time we have a new application feature. > > >> > > > >> > What are everyone's thoughts around this? > > >> > > > >> > Cheers, > > >> > Shane > > >> > > > >> > > > > > ------------------- > > Thank you, > > > > James Sirota > > PMC- Apache Metron > > jsirota AT apache DOT org > > > > >
