Best practices: components responsible for querying
Love this library and I've been using it for quite some time. I'm struggling to get folks on board w/ tanstack/query for our next phase dev. I came a across this article a while ago and I think it succinctly summarizes the opinion of the hold outs:
Any clever response to the thoughts below?
https://nikoheikkila.fi/blog/clean-frontend-architecture-with-sveltekit/discovering-the-use-cases/#user-content-fnref-2
1. ....Some special utility libraries, such as React Query, endorse it as a best practice. In this fashion, components fetch data and render their HTML based on whether the internal state of a query is pending, rejected, or fulfilled. It does this so you don't have to touch the global state 2. But I'm afraid of no state, and neither should you be!I don't recommend having components responsible for querying data because their responsibility is already in presenting the data. More accurately, components need only receive data from view models, format it, and output it to the screen. Instead, I advise you to follow either of the three following ways:
Niko Heikkilä
Clean Frontend Architecture with SvelteKit: Discovering the Use Cases
Why designing loosely coupled applications is crucial for managing complexity and sustaining maintainability.
6 Replies
unwilling-turquoiseOP•3y ago
wondering if you might have any thoughts @babycourageous?
extended-salmon•3y ago
More accurately, components need only receive data from view models, format it, and output it to the screen.someone really loves the smart / dumb component split. I couldn't disagree more 😂
extended-salmon•3y ago
Components should primarily see the data passed to them via properties, commonly known as props. It helps you by creating a natural anti-corruption layer between your views and the application keeping it maintainable, scalable and effortless to test.the counterpart to "maintainable, scalable and effortless to test" is having an unnatural split between a "DashboardContainer" and a "DashboardView", which drills props around 5+ component layers. I've been there and don't want to go back. At the end of the day, it's all tradeoffs: https://tkdodo.eu/blog/react-query-as-a-state-manager#a-note-on-separation-of-concerns
React Query as a State Manager
Everything you need to know to make React Query your single source of truth state manager for your async state
extended-salmon•3y ago
by that definition, you can't really use something like redux and call
useSelector in a component that produces markup. That is literally going back to mapStateToProps.absent-sapphire•3y ago
it should come as no surprise, @TkDodo 🔮 said it much better than i ever could 😉 ! I def side with him on the smart/dumb split. I'm def a fan of not doing that. In NextJS and React Server Component land i adore being able to fetch data and display it all colocated in one spot. So delightful!
unwilling-turquoiseOP•3y ago
delightful indeed!!
thank you very much for your replies! this was the kind of crystalline input I was hoping for!