Best way to organize functions in React?

sebastianspiller · February 12, 2024, 2:37pm

Hello everyone!

Question: What would be the best way to setup my functions associated to e.g. Mongodb Collection Objects? Are there Best Practices in React, Meteor?

I used to use the package Collection Helpers in blaze, where I could call Mongodb queries insight the method and everything was reactive.

Using this, in autorun, Messages AND Streams was both reactive.

Now in react, I have:

Bildschirmfoto 2024-02-12 um 15.30.15

I keep reactivity through the dep Array, but I could not use helper code like shopCart.getStream() as a inner Query to Collections.Streams.findOne(shopCart.stream_id) would not be reactive.

I found the Collection Helpers package really cool, because I could use code on both client and server side.

Do you know some cool patterns?

Thanks in advance

vikr00001 · February 12, 2024, 11:26pm

Can you get the results of shopCart.getStream() and assign the results to a React component useState variable? That would make the React component reactive. (I haven’t used MongoDB except for Meteor Accounts.)

storyteller · June 10, 2024, 9:53am

I have been lately struggling with React and reactivity. The big change/return now is to have components dedicated just to data fetching while previously it used to be in one component or we have HOCs (which are now making comeback). Since my project is almost 10 years old it is a mix, but lately while experimenting with React 19, the older pattern with co-located data fetching has been causing a lot of problems. In React 18 I could get around it with suspense, but that seems no longer be possible, so now I’m hunting for the problem code and separating things. The upside of this is that it will make it easier to use the show components in Storybooks and other tools outside of Meteor.

Though I think we need a guide on the proper React pattern with Meteor. Anyone has any good suggestions here?

rjdavid · June 10, 2024, 10:44am

I’ve tried working with React Router’s data fetching, and it isn’t compatible with having “unknown” components on the router level.

With use() and suspense, I am planning to make stand-alone components that have the following structure:

Suspense Boundary > data fetching > UI

Data fetching can be either a subscription or a method.

For our use, the component should be the same for both client and SSR (I haven’t thought yet how this will work with RSC).

I still do not know if this will work with React 18 and Meteor 3. We also have a mix of hooks and classes

rjdavid · June 14, 2024, 5:50am

Many developers are revolting against the “best practice” of hoisting the data fetching up at the router level instead of near the component where it is used.

github.com/facebook/react

Don't prerender siblings of suspended component

facebook:main ← acdlite:disable-sibling-prerendering

opened 04:39PM - 13 Mar 23 UTC

acdlite

+476 -487

Today if something suspends, React will continue rendering the siblings of that …component. Our original rationale for prerendering the siblings of a suspended component was to initiate any lazy fetches that they might contain. This was when we were more bullish about lazy fetching being a good idea some of the time (when combined with prefetching), as opposed to our latest thinking, which is that it's almost always a bad idea. Another rationale for the original behavior was that the render was I/O bound, anyway, so we might as do some extra work in the meantime. But this was before we had the concept of instant loading states: when navigating to a new screen, it's better to show a loading state as soon as you can (often a skeleton UI), rather than delay the transition. (There are still cases where we block the render, when a suitable loading state is not available; it's just not _all_ cases where something suspends.) So the biggest issue with our existing implementation is that the prerendering of the siblings happens within the same render pass as the one that suspended — _before_ the loading state appears. What we should do instead is immediately unwind the stack as soon as something suspends, to unblock the loading state. If we want to preserve the ability to prerender the siblings, what we could do is schedule special render pass immediately after the fallback is displayed. This is likely what we'll do in the future. However, in the new implementation of `use`, there's another reason we don't prerender siblings: so we can preserve the state of the stack when something suspends, and resume where we left of when the promise resolves without replaying the parents. The only way to do this currently is to suspend the entire work loop. Fiber does not currently support rendering multiple siblings in "parallel". Once you move onto the next sibling, the stack of the previous sibling is discarded and cannot be restored. We do plan to implement this feature, but it will require a not-insignificant refactor. Given that lazy data fetching is already bad for performance, the best trade off for now seems to be to disable prerendering of siblings. This gives us the best performance characteristics when you're following best practices (i.e. hoist data fetches to Server Components or route loaders), at the expense of making an already bad pattern a bit worse. Later, when we implement resumable context stacks, we can reenable sibling prerendering. Though even then the use case will mostly be to prerender the CPU-bound work, not lazy fetches.

storyteller · June 17, 2024, 8:03am

This is getting super interesting. Overall I have noticed a lot of issues when trying to upgrade to React 19. The upside so far is that it is forcing me more to separate data loading into separate components.

rjdavid · June 17, 2024, 8:29am

The challenge is that this is one of those cases wherein what is best for the user is bad for developer experience.

In terms of developer experience, it’s easier to fetch data nearest to where it’s used. Standalone components are reusable and easy to use and understand. Component encapsulation is the goal.

In terms of user experience, the best scenario is to fetch data once before rendering anything (sometimes even before knowing if you will need the data or not). This removes the loaders per component and friendly for slow internet connection. In this case, graphql and router-based loading shines.

For the meantime, React 19 is on hold due to these two opposing patterns
https://x.com/sophiebits/status/1801663976973209620

paulishca · June 17, 2024, 9:08am

To add some more abstraction to this, I think data fetching functions can stay nearest to where data is being used. However the function and the method in Meteor can be different things.

As I use Redux in all my projects, Meteor Methods calls can be … anywhere on the client. The Redux actions (that invoke Meteor methods) are always within the component. I think it works the same with React Context. It is indeed inefficient to pass subscriptions through a global context and I suppose they best stay at the (parent) components level (without using too much granularity - using too many subscriptions for too many nuclear components)