DEV Community

loading...

Discussion on: Normalize your React Query data with MobX State Tree

Collapse
ekeijl profile image
Edwin

Nice article! If I understand correctly, using this method, each object only occurs once in the store, but you still fetch a whole page per query? The creator of react-query mentioned that with normalized caching you may end up replicating all the filtering, sorting, paging logic on the client side and you potentially still have stale data.

twitter.com/tannerlinsley/status/1...

In your opinion, does this still outweigh just refetching the data (and potentially overfetching) with react-query?

Collapse
hrastnik profile image
Mateo Hrastnik Author

Nice article! If I understand correctly, using this method, each object only occurs once in the store, but you still fetch a whole page per query?

That's correct. I don't have to recreate the server-side logic because I use react-query to sync. The normalization makes sure that each object occurs only once in the store. This way, a resource on a list view and the same resource on the details view is always in sync. Also, updating the resource means that it will update both the list and details view.
a
This alone is already a great benefit with no downsides compared to plain react-query. But when you add to it all other benefits of MST...

Actions on models

you can do stuff like article.like() instead of like(article)

Transparent denormalization

you can do stuff like article.author.name (Here author is a MST object with actions and views). Or even article.author.update({name: "John Doe" }). The API is as clean as it gets.

Type checking

All of the properties, actions, views on the model are typechecked. When you type in article. you editor will list all the available props on the model, and it goes all the way down - type in article.author. and you get all the props on the author model.

As I see it - there no downsides when using RQ+MST combo - only benefits.