Resolver vs Redux

Question

I have been working for quite some time now in small/medium sized projects with Angular and as long as there is some data which needs to be loaded from a server, the team directly goes for storing it into a Redux store. This allows for the data to be preserved when a user navigates between "pages" and if they decide to refresh their page.

However, recently I have been doing a "proper" Angular tutorial and we managed to achieve the same results with a combination of service (provided in in app.module.ts) to keep the data and resolvers. The resolver makes sure that when my main page is loaded, the data required is loaded into the service. Additionally, if the data is not too big I can even store it into the localStorage and thus, eliminating the HTTP requests in the resolver if the data is not there.

Except for the unlikely use case where 1. there needs to be a lot of data loaded and 2. the user refreshes for some reason the webpage very often, I don't really see why we should be implementing a complete redux store.

Are there more reasons to use Redux which I have not understood or are there more downsides of using this approach?

By the way, I have seen cases where people get data from a store in a resolver, as a way to use both, and avoid migrating to services once off. — Athanasios Kataras, Nov 14 '19 at 10:05
@AthanasiosKataras That's definitely interesting case which I haven't thought about. But how is implementing a whole Redux better than using a simple data service which sets/gets data? — AGoranov, Nov 14 '19 at 11:50
It's not, it's just something to thing about for gradual migration to Resolver/Service paradigm. — Athanasios Kataras, Nov 14 '19 at 12:16

score 3 · Accepted Answer · edited Jun 20 '20 at 09:12

This is a very famous article from the creator of redux. It's called you might not need redux.

Angular is a framework that is known to have solved the problem of inter-data dependency. If the inter-component communication of event and data binding works for you and caching via services is ok without causing the following problems, then you should stick with them.

Why?

Redux is counterintuitive for most developers with a steep learning curve
Requires a lot of boilerplate code, that if you don't need it's tradeoffs then you shouldn't bother with it

Redux and flux in general is misinterpreted and widely used in a wrong manner. There are indications of when you need to use redux which you can see in angular univercity. It pretty much says the following

React components are arranged in a hierarchy. Most of the time, your data model also follows a hierarchy. In these situations Flux doesn’t buy you much. Sometimes, however, your data model is not hierarchical. When your React components start to receive props that feel extraneous, or you have a small number of components starting to get very complex, then you might want to look into Flux.

You have a piece of data that needs to be used in multiple places in your app, and passing it via props makes your components break the single-responsibility principle (i.e. makes their interface make less sense)

There are multiple independent actors (generally, the server and the end-user) that may mutate that data

In any other case (and when the examples above are limited), I would choose to go without redux and use the Resolver, Guards and services that angular serves out of the box.

Thanks for the answer! It seems that many people assume that they must have Redux without considering the built-in options of their respective Frontend framework. As the article says, it can lead to huge boilerplate code without serious benefits. — AGoranov, Nov 14 '19 at 12:01
Cheers! Is there anything else you'd like to know? If not, please don't forget to upvote/accept helpful answers. — Athanasios Kataras, Nov 14 '19 at 16:45

Resolver vs Redux

1 Answers1