Eric Wong

Software Crafts-person

3 minute read

In this series, I’ll be exploring how to build scalable Angular Enterprise applications.

Hi! If you haven’t read part 1, you might want to do that first.

So, last time we covered the general idea behind how the components would be architected. However, we didn’t get a confusing aspect of larger applications: state management.

What is state management, exactly?

State management, in my opinion, is related to the management of any data that influences how a view is displayed to the user. Depending on your requirements, state management could be quite simple. As any precursory glance on Google can tell you, state management became a really well-known problem for Facebook. They came up with Flux.

Dan Abramov later wrote another implementation, Redux, a solution to several design problems that they were coming up against. The gist of the problem was: multiple places in their app were trying to update and display the same set of data. Very often, one or more of the areas would be out of sync and the view would become inconsistent.

A few ways to solve the issue:

  • read-only views
  • write to the database every time and make calls to ensure one source of truth

Solution tyme!

If you look at Flux/Redux/store-solutions, in a sense, they actually are an amalgamation of the two aforementioned ideas. Have a single source of truth but make it on the client-side, to minimize expensive service calls. Keep the subscribers of the data as read-only and only allow them a set of repeatable and consistent methods of interacting with the source.

If we boil down the solution to these two ideas, the whole thing seems pretty simple and trivial. That being said, it took me a few full days to really wrap my head around this whole idea. I kept on getting distracted by talks of:

  • actions (the determined types of methods to interact with the data)
  • reducers (functions that transform actions into actual immutable state objects)
  • stores (where the source of truth exists), dispatchers (the way to send actions to reducers)
  • effects (extra occurrences that are async, like http, that have an impact on state)

Caveat Emptor

But if we jump straight to this conclusion, it seems like we’d be overdoing for most of our simpler applications. Not all enterprise applications need be gigantic. And generally, very few applications will require that global state be kept. We’re not all building Facebook-level apps. A concern I have is that, with introducing Redux/stores too early, you’re asking for all your developers and their grandparents to put variables into that store. It’ll grow big, be disgusting, and become another nightmare to untangle later. We should use global state management in the worst-case scenarios and no sooner.

Triviality

Now, what about for more trivial scenarios?

If you take a look at Angular’s Tour of Heroes tutorial, I believe they cover two methods of how best to manage state.

Option une

You can use components’ @Input and @Output decorators for regular component interaction. This isn’t really a feasible answer, as you rarely ever pass state only between two components. That being said, it wouldn’t be very easy to manage if it went above 2+ components.

Option deux

Use a local service. Inject the service between the two smart components within the same business domain (generally within a set of pages related to the same thing) and manage state from that. The provider would be within a component or even within just that module. This leads to the ideal case of the service cleaning itself up when that page is no longer used. Less headache, tbh. You’re essentially creating a mini-store that’s 10x easier to manage and much less of a pain in the butt. Redux-like solutions are way too overpowered (OP) for this case.

When I was researching and learning more about state management, I really forgot the very first things I learned about Flux/Redux.

Local state is fine. -Dan Abramov

You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it. -Pete Hunt

No code this time, folks! Hope this piece helps clear up some of the mystery y’all may be having. Until next time!

For slick cool giffies of how Redux works, click here.

https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/

Very detailed explanation about the whole shebang: https://blog.angular-university.io/angular-ngrx-store-and-effects-crash-course/

You May Also Enjoy