Hacker News Reader

Comment by petilon | Hacker News Reader

All you need is a client-side cache.

How do changes to that cache get displayed? Your cache emits events that each UI element has to listen to? Congrats you’re using redux!

(It would perhaps be more accurate to say that React folks had to reinvent these patterns, but the problems were definitely present in the postback era)

> Your cache emits events that each UI element has to listen to?

It doesn't. How often do you have the same information redundantly displayed in multiple places, on the same screen?

It's not even necessarily the same information, but small pieces of one bigger piece that need to be updated once some of the other smaller pieces change

Yeah this. The classic is unread state in a mail app. Unread state is usually displayed both as bold state per message in a message list, and as a count in the folder list. These need to stay in sync as the user reads mail (and sometimes marks read state explicitly). Two views of the same underlying state.

Sure, you can come up with an example where some synchronization is needed, but how often do you have this requirement? In most apps it is rare, which means that it can be solved by using a couple of extra lines of code to update the screen, as opposed to adopting a complex state management system with events firing and so on. Simple solutions for simple problems.

It is quite common. Take this screenshot of Youtube: https://imgur.com/a/nxGdcWj

The comments total at the top and each of the thread counts need to be kept in sync with their corresponding inline list representations.

Most lists in apps display a total count summary. This is even more common on desktop, where you have room to display more info.

That is exactly what the React state management solutions all are...

Reply on news.ycombinator.com