alexey2020

That's cool and definitely the future of HTML streaming,

it simplifies things a lot: js enabled out-of-order streaming leads to SEO problems and frameworks usually need to come up with workarounds - detect bots and turn of streaming for that case.

With such technique no workaround is needed, less things to worry about.

Excellent!

came here to write a similar comment. Totally agree!

Focusing on a particular metric for the sake of the metric - what's the point?

Let's spend a couple months, refactor an app to generate less js just to look cool in the eyes of dev community?

>But in the article, you wrote:

I also wrote a bit below: "be transparent to components and not affect their logic in any way (make components think they communicate to Backend directly)"

I met people trying to use ReactQuery with the mindset that it's a Store. The result was that they were greatly frustrated with the outcome. That mindset led them to use ReactQuery in a way it's not supposed to be used. Every now and then they wanted to directly manipulate with the Cache (the "Store" underneath ReactQuery).

That's why I find that Store-mindset very dangerous when working with such Libraries.

Better come with a mindset that there is no Store at all. Better think that "useBookQuery" is just a simple hook to fetch data. NO STORE.

>To me, “directly communicating with the backend” implies that I have to have REST calls in my components, and handle all that comes with that

This is exactly what I meant :)

I'm glad that you found the article useful. Thanks again for providing your feedback!

Thank you for the valuable feedback!

Very good question about the difference between `getFromStore` and `useBookQuery`.

When using `getFromStore` you have the expectation that the value is already in the Store. Someone should have already put the value there somehow.

You have also the expectation that `getFromStore` is synchronous and simply gives you nothing if the value is not there.

With `useBookQuery` you expect the value to be fetched from Server. There is no 3rd party to care about putting the value in the Store. `useBookQuery` is simply like `fetch('...')` from a Component perspective.

With libs like ReactQuery every component "simply" fetches what it needs, sort of directly communicating to the Backend. No intermediary party (like a Store)

>React is doing a lot of work with Suspense ...

Yeah, I heard about React team collaboration with libs like ReactQuery on making Suspense work with those, also on server side. But I'm not much into that Suspense topic, so decided to not mention anything about it.

>I suggest emphasizing the loading/error mechanics more strongly at the end of the article.

Thanks for the suggestion. I will think about it.

>the quality and intent Marin fowler’s of writing is actually respectable.

Sorry, didn't want to be picky, but the article you mentioned is not written by MarTin Fowler. And I also didn't find there many "citations" you were looking for in my article.

I'm sorry that you found my article of a little quality.

I did my best trying to analyze different approaches to Data Management, How we came to those and their problems. I illustrated those with the my own diagrams to help readers better understand the concepts.

The article is based on my 10+ years experience in the industry.

It went through many iterations of reviews and corrections.

There nothing unique in the approach I described. It builds on what libraries like ReactQuery allows to do.

I basically just tried to formalise why I see this approach as the next logical step in how we approach building UI apps.

I'm not a native English speaker and not a professional blogger. Most probably there are ways to write such an article better. I do my best learning how write better.

Having said that, I think you are not fair comparing it with your "expert-junior-evangelical" phase.

"the small cognitive load" - true that!

Thanks for the link to the podcast. Will definitely check this out

>Whether the action goes and fetches data from the server doesn't matter

I tried to explain in the article why it matters.

If you are comfortable with putting all the data in a single Store and this works fine to you, then you may disregard the article.

>Let's say you want to add a button somewhere that hides/shows another widget.

That's a good case. This is purely UI state, right? (we don't store it on the server).

For UI state we still need to depend on prop-drilling or State Management solutions.

In the article I'm mainly talking about the Data which exist on Backend (as you can also see from all the pictures). In my experience such Server data is 90-95% of all data in most UI applications and that data contributes the most to the complexity.

Pure UI state is often just a fraction of the the whole State and is's often synchronous, so managing it should not be complex. So this kind of coupling will still exist.

To clarify, I do not say Widgets should be 100% independent. We do not achieve complete decoupling. But moving Server Data under control of Widgets gives us closer to this.

Agree. There are applications where widgets approach would not bring much benefits.

Let say, applications with lots of UI state (state that doesn't exist on Server).

Also not sure how it would work with realtime apps.

It's the same with every approach, the are always exceptions from the rule.

That said, I see the benefit of this approach for the majority of UI apps, which heavily rely on Server data.

>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.

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