> "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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
