Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-28 Thread Michael Miklavcic
> "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  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 
> 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 
> > 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 

Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-28 Thread Tamás Fodor
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 
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 
> 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  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
> > > 

Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-28 Thread Tibor Meller
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 
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  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" :
> > > 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  >
> > > 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  >
> > >>  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 

Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-27 Thread Shane Ardell
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  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" :
> > 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 
> > 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 
> >>  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
>
>


Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-26 Thread James Sirota
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" :
> 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 
> 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 
>>  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 ,
>>  > 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



Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-26 Thread Michael Miklavcic
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 
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 
> 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 ,
> > 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
> >
> >
>


Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-26 Thread Michael Miklavcic
Just an fyi for newer members of the dev community - we are very open to
and appreciative of all community involvement and feedback - for
non-committers, as a general rule please make a small note next to any
votes (-1's, +1's, etc.) indicating "(non-binding)".

On Mon, Nov 26, 2018 at 7:04 AM Tamás Fodor  wrote:

> That is a great idea!
>
> +1
>
> On Mon, Nov 26, 2018 at 10:19 AM Tibor Meller 
> wrote:
>
> > Shane, Thanks for gathering the information and raising this.
> > I also feel that our UIs reached a level of complexity what makes this
> to a
> > reasonable next step.
> > This complexity on the client side will grow in the future and I believe
> it
> > is better to prepare instead of trying to make huge refactorings later.
> > NgRx/Redux is quiet the industry standard architectural library in both
> > React and Angular realm. Pretty well known in the community.
> > I would be happy to move forward with NgRx.
> >
> > On Fri, Nov 23, 2018 at 3:44 PM Shane Ardell 
> > 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 
> > > 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
> > > >
> > > >
> > >
> >
>


Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-26 Thread Tamás Fodor
That is a great idea!

+1

On Mon, Nov 26, 2018 at 10:19 AM Tibor Meller 
wrote:

> Shane, Thanks for gathering the information and raising this.
> I also feel that our UIs reached a level of complexity what makes this to a
> reasonable next step.
> This complexity on the client side will grow in the future and I believe it
> is better to prepare instead of trying to make huge refactorings later.
> NgRx/Redux is quiet the industry standard architectural library in both
> React and Angular realm. Pretty well known in the community.
> I would be happy to move forward with NgRx.
>
> On Fri, Nov 23, 2018 at 3:44 PM Shane Ardell 
> 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 
> > 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  >,
> > > 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
> > >
> > >
> >
>


Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-26 Thread Tibor Meller
Shane, Thanks for gathering the information and raising this.
I also feel that our UIs reached a level of complexity what makes this to a
reasonable next step.
This complexity on the client side will grow in the future and I believe it
is better to prepare instead of trying to make huge refactorings later.
NgRx/Redux is quiet the industry standard architectural library in both
React and Angular realm. Pretty well known in the community.
I would be happy to move forward with NgRx.

On Fri, Nov 23, 2018 at 3:44 PM Shane Ardell 
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 
> 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 ,
> > 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
> >
> >
>


Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-23 Thread Shane Ardell
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  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 ,
> 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
>
>


Re: [DISCUSS] Add ngrx to handle state management in Angular

2018-11-22 Thread Otto Fowler
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 ,
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