> "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."
That does sound desirable. The explanations you guys have provided all sound very reasonable to me. I recall us having issues with state even in the early versions of the Alerts and Management UI's and this sounds like it should simplify that a great deal. I'm +1 on going this route. Cheers, Mike On Wed, Nov 28, 2018 at 11:26 AM Tamás Fodor <ftamas.m...@gmail.com> wrote: > Personally, I prefer following the flux approach because having one store > as a single source of truth makes a complex web app more predictable and > easier to reason about. > In angular we can easily achieve this by using NgRx which supports the > unidirectional data flow by involving pure functions that hold the business > logic and it it's extremely simple to test them. With NgRx we could also > have separated functions to manage side effects like http requests. Not to > mention the aforementioned awesome Redux toolbar to see how the data flows > trough the application. > This approach has been proven over the years and perfected by many other > developers. Onboarding new members in team has never been easier, since, > instead of spending a lot of time to come up with our own solution and > write a documentation or a usage guide, new devs can find tons of resources > about best practices on the Internet. > NgRx also forces developers to keep the state immutable which is a very > important ingredient of the whole story. By having an immutable data > structures we can get the most out of Angular's rendering capabilities by > setting the proper change detection strategy. We can simply avoid a lot of > unnecessary re-renders and difference calculations between the previous and > the new state. If we use immutable state Angular can compare it by > reference checking which is extremely fast. If the data has the same memory > pointer as the previous data it simply skips the reconciliation process for > a certain part of the (or the entire) component tree. > > On Wed, Nov 28, 2018 at 10:48 AM Tibor Meller <tibor.mel...@gmail.com> > wrote: > > > 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 > > > > > > > > > > > > > >
