Widget Driven Development
This article gives a great rundown of various UI layer approaches, the problems with each, and how the subsequent ones solved them.  I hadn’t seen react-query or its listed alternatives before, so thanks!<p>The one thing I’m not clear on is how this is much different from the “single global store” approach.  It looks like that’s what this approach uses, and the main difference is in the “store API.”  In other words, usage from components is nearly identical, and it’s the mechanics of the store itself that is changed.  There’s a layer of focused queries between the store and components that hides the access (and maybe update?) mechanics from the widgets.  So instead of<p><pre><code>  getFromStore(“books”, bookId) &#x2F;&#x2F; pseudocode, I am not a Redux user
</code></pre>
you instead use<p><pre><code>  useBookQuery(bookId) &#x2F;&#x2F; which includes some nice things like { isLoading, error }
</code></pre>
It doesn’t seem to resolve the need to handle the following bullet point found in the store drawbacks, it “just” pushes it into a group of queries (and presumably updates).<p>&gt; we now have to deal with a completely new concept, the Store, and care about a bunch of new things, such as designing and maintaining Store structure, appropriately updating data in the Store, data normalization, […]<p>Is this separation the point?  Or am I missing something else?  Keeping the store access mechanics separated from the widgets that use them makes sense to me, especially when it has built-in loading&#x2F;error notifications.  I was going to say that “widget driven development” doesn’t really point to what this achieves by making that separation, but I may be coming around to the term with those other considerations.<p>I suggest emphasizing the loading&#x2F;error mechanics more strongly at the end of the article.  React is doing a lot of work with Suspense to improve their ability to give UI feedback in those states, and it looks like this approach simplifies the data side of that.