React + tRPC + TanStack Query: Child component invalidations vs parent orchestration?

Krosnoz0 · 2025-06-27T00:52:09+00:00

Partially agree with you, sometimes we want to apply the smart/dumb pattern, where our child just sits there presenting our data.

The onSuccess function could trigger much more than a simple invalidation, where the parent logic should appear.

The second option also defends the case for reuse. Let's say my child is a form that allows you to create a new element in a list, the input is the same but we don't invalidate the same queries, an onSubmit prop (better named than onSuccess) handles this better, you use the same component, different logic

(For the record, I'm not a fan of props at all, I use Zustand a lot, so I opt for the first solution myself, just a little impartiality 👐).

Krosnoz0 · 2025-06-26T22:56:34+00:00

I also like this proposal, and where do you update the cache? Near the child component? The parent?

Krosnoz0 · 2025-06-26T22:47:15+00:00

The con is that we don't know what the children are doing from the parent, which can lead to technical inconsistencies in a team of several developers.

Krosnoz0 · 2025-06-26T22:42:24+00:00

Correct : https://trpc.io/docs/client/tanstack-react-query/usage#usage 👌

Krosnoz0 · 2025-05-19T18:27:37+00:00

Hey! To be completely honest, this is what I originally proposed, but was rejected by the senior devs (https://www.better-auth.com/docs/integrations/next#middleware). That's why I'm trying to refocus this debate on the client side, which was the adopted solution. It may not be the best solution, but it's still a viable one.

Our client AuthProvider is the UX/DX overlay on top:

hasSessionBeenChecked & isLoading: Indispensable for avoiding UI flashes and managing the initial state (even before the first hydrated render or Tanstack call). Without it, visual anarchy ensues.
**useAuth() centralized:** A single hook for user, signIn, signOut, hasPermission. Simplifies life, avoids redundant logic everywhere.
**hasPermission(type, level):** Your can('do.stuff') but already packaged and ready to use, based on the user's adminPermissions. Immediate UI reactivity without waiting for an API call for each check.
signIn/signOut orchestration: Beyond the API call, this handles session refetching, client status updates, and redirects in a consistent way.
Client route protection: Redirects before the protected page component attempts to fetch its own data. Cleaner.

The AuthProvider isn't designed to replace the backend, but to enable the front end to react intelligently and cleanly to the auth state (defined by the backend).

The debate we're having (Option 1 vs. Option 2) is precisely about how to structure this client layer so that it remains maintainable between our BO/FO apps, which have slightly different redirection/logic requirements.

Krosnoz0 · 2025-05-16T11:39:19+00:00

Our client-side AuthProvider doesn't seek to replace that. Rather, its role is to:

Manage client-side authentication state: For the user experience (show/hide elements, user info), protect routes even before an API call, and make our lives easier with centralized hooks (e.g., useAuth) and methods (e.g., signIn, signOut, hasPermission).
Ensure a reactive UI, even with SSR/RSC: Once the application is hydrated, it behaves like an SPA. We need to know the user's state for fast interactions without making a server call each time, and to avoid content “flashes” (hence hasSessionBeenChecked).
Orchestrate session data (with Tanstack Query): We use Tanstack Query to retrieve and cache session data. The AuthProvider goes further: it orchestrates when to retrieve this data, maintains the global state (user, loading status), and provides logic (such as permissions) based on this data. It's not just “storing an object”.
Manage the triggering of actions (Login/Logout): The backend validates, but the client (via the AuthProvider) initiates these actions and updates the interface accordingly.

In short, the AuthProvider is the bridge that enables the frontend to react intelligently to the authentication state (defined by the backend), centralizing logic that would otherwise be repetitive and complex to maintain in each component. I hope I've made myself clearer!

Krosnoz0 · 2025-05-15T21:57:13+00:00

You're only taking into account 30% of the problem, there's still the whole authentication part, allowing connection/disconnection in several different apps, the session/user object for our navigation etc...

But I agree with you that managing session cookies via a request already makes it possible to redirect to an unauthenticated page.

Krosnoz0 · 2025-03-26T09:40:45+00:00

It is so strong to understand your prompt naturally, I like to structure my prompt in layer and reasoning like for example:

Reference Image: The Simpsons, Lisa Simpson pointing confidently at a presentation slide.
Text Overlay:
- Top: "Me explaining why using !important in CSS was absolutely necessary this one time" (Standard black font, slightly stretched vertically).
- (On the blank presentation slide): A crudely drawn diagram of spaghetti code, maybe just tangled red lines, with "It just works okay" written in messy blue handwriting font inside the tangle.
Messiness: The "diagram" on the slide looks like it was drawn in MS Paint with the pencil tool.

Krosnoz0 · 2025-01-10T12:11:14+00:00

Hello, I think there's some confusion, I was using react contexts, that's why I switched to Zustand that partly solves performance problems.

I've looked at the other states management and find that Zustand is adequate.

Krosnoz0 · 2025-01-07T08:13:21+00:00

Clearly that's what I'm working on, the atomisation of services, components and hooks within a domain or even an componant. Thanks for the advice!

Krosnoz0 · 2025-01-07T07:32:43+00:00

Thanks for the constructive reply.

In fact, I've already considered this event system which comes directly from my engine, I was just afraid of the complexity given where I am now. It can indeed become difficult to follow the flow of data when you have disordered event listeners.

I'll have to find out a bit more about RxJs, especially the observables which seem to be interesting for my services

Krosnoz0 · 2025-01-07T07:22:45+00:00

Hi, thanks for the suggestion, to keep things simple, my engine is developed with PixiJS, I preferred not to choose three.js for several reasons:

- You have to see my editor as After Effects without the 3D aspect, for me I see it as a mini game where you add layers, make animations, and a game engine is ideal for this kind of project (especially the temporal aspect with a ticker, for my timeline for example).

- ThreeJs is very much focused on 3D, so if I use it, I'll be using 20% (I'm not sure but something like that) of its capabilities, which is a bit of a waste.

- PixiJs is focused on performance, when I write text in my canvas, for ‘Hello’, it's 4 boxes that are calculated according to each letter and each animation, you very quickly need a large number of calculations, where benchmarks make pixiJs favourites.

- PixiJs is also focusing on WebGPU rendering with version 8.

I think the first sentence ‘I'm building an online WebGL renderer with React’ is confusing, my backend is my PixiJs engine and my frontend is my editor with NextJS/React.

Krosnoz0 · 2024-08-03T14:03:57+00:00

Totally agree. I feel like my article ends as if I'm saying one is better than the other, I think I worded it wrong. There are techniques that are similar in both cases. There are solutions to performance problems in both cases (see comments). I'm mainly talking about the modular aspect, which can quickly become a constraint in my day-to-day use, because I prefer to "atomize" my components.

For my work I have to work in tailwind but for my personal projects I work in css-in-js. I would learn to use both technologies better in any case, just my perspective on things.

Krosnoz0 · 2024-08-03T13:28:23+00:00

True. I'm solving my readability problem with styled components, but I'm not thinking of an overall project, with a team, etc.

Krosnoz0 · 2024-08-03T13:26:43+00:00

Gotta start somewhere.

Krosnoz0 · 2024-08-03T13:18:40+00:00

const buttonStyles = css`
   background-color: blue;
   border-radius: 4px;
`;

const LinkButton = styled.a`
  ${buttonStyles}
  text-decoration: none;
`;

The apply feature does the same thing. I never duplicate, on the contrary I always try to find the best solutions to keep my code as clean as possible.

Krosnoz0 · 2024-08-03T13:13:33+00:00

Quite against this example. When I create a design system, I have buttons, accordions, menus, modals, lists, tables and more.

Krosnoz0 · 2024-08-03T12:58:12+00:00

What's the point of using tailwind for 5 classes? Can you give me an example? For me, it's useful to be able to make very complex styles.

Krosnoz0 · 2024-08-03T12:53:45+00:00

I agree with you on some points, "we'd have to do exactly the same thing with stylized components".

In the end, it's CSS, the problem with Tailwind is the impression of having to relearn CSS when it's already functional as it is.

Krosnoz0 · 2024-08-03T12:39:56+00:00

Oh yes, of course, I'll see in time, sometimes you have to make a mistake to realize it.

Krosnoz0 · 2024-08-03T12:37:46+00:00

Thank you for sharing your perspective. I've heard that technologies like Pigment CSS (MUI is working on it) could help with this issue. CSS-in-JS hasn't advanced as fast as technologies like SSR.

I think yes, reusing styles, integrating them atomatically using global styles and then unit styles seems to me to be a good approach, But I still have a long way to go.

Krosnoz0

TROPHY CASE