[tmikaeld]

The benefits seem unclear to me, especially how this solves the shared-state issue. Is it just that each "widget" calls the same API "manager" and propagates the changes to every widget in the event of a change?

Isn't this exactly what Redux already do if you use actions to fetch data and put it into the store, with the difference that each "widget" manage filters and state based on the fetched API data? Seems like it could create a lot more code with less re-usage, since every widget has to manage this themselves.

[alexey2020]

With pure Redux approach the mutation flow is more complex: - send mutation request to Backend - fetch updated data - put the updated data in the Store - see the updated data propagated in components

The suggested approach: - send mutation request to Backend - see the updated data being fetched and displayed by components

To me the second is much cleaner and easier to reason about

[ptx]

Wouldn't the lack of a shared store on the client lead to an inconsistent application state when different components fetch different versions of the data? I.e. one part of the UI could think you're logged in as admin while another thinks you're a guest user.

[alexey2020]

>Seems like it could create a lot more code with less re-usage, since every widget has to manage this themselves.

It might create a bit more code in components, agree. I think this is a fair price for the all benefits it brings.

That said, the total amount of code might be even less (no action-creators, reducers, etc.).

Also declarative nature of the libraries makes the added code very easy to follow.

[candiodari]

The key thing to realise with widgets is that while the widget code is indeed complex, it’s reusable and generally you’re not writing it.