> "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
> > > >
> > > >
> > >
> >
>

Reply via email to