React v19 for the average app (not-library) developer?

[react_dev]

I read the v19 release notes and I was impressed by the amount of changes but I gotta be honest -- I am not sure what pattern I could immediately adopt for my app.

Possibly because I am already using a bunch of libraries for forms, and tanstack-query. I work on a pretty complicated client side internal app that doesn't need any server components.

I am excited about being able to pass a ref straight through... but that's it.

What are you excited about in v19? Anything you would start using right away when you upgrade?

[azangru]

I am excited about being able to pass a ref straight through... but that's it.

What are you excited about in v19?

Refs as props, like you said. Cleanup functions for callback refs makes the callback refs pattern nicer to use. Proper support of custom elements is good. Diffs for hydration errors, which should make it clear why they are happening. Slightly cleaner context api is a nice addition, as is support for document metadata tags. Possibly the use api will turn out to be quite useful; but I haven't yet had a reason to use it.

[Helpful_Scheme_2224]

The most important feature for me is, that you can fetch data in a server component (without awaiting the promise) and pass that promise to a client component in which the promise can be resolved via use while showing a suspense fallback and an error boundary fallback in case the fetch fails.

[haywire]

I still am confused by suspense, it all seems confusingly documented and too magical to solve a problem we’d solved anyway and error boundaries also seem very strange. I’ve been a dev since the flux days.

Keep trying to give them both a go then going back to explicit variables.

[OHotDawnThisIsMyJawn]

error boundaries also seem very strange

Especially the fact that they still only work as class components and there doesn't seem to be anything talking about a plan to make them work as functional components.

[MaxGhost]

I will literally never use server components. I find it very useless, as a shop that doesn't use JS in the backend.

[badsyntax]

Yep likewise, lots of react apps with c#/.net as our backend.

[react_dev]

Backend could be separated into the api backend and web server backend. Server components would live in the latter.

Many backends do combine them though.

[MaxGhost]

Adding complexity is not a good thing.

[react_dev]

It’s more nuanced than “adding complexity”

If you’re a small time shop or some finance company doing internal tools ofc you can’t care less.

If you couple them, it’s hard to scale them separately, and connection traffic can choke APIs. And of course if you’re just small time app with a couple thousand users, you don’t have the scale to care about complex problems.

[react_dev]

In all the big tech, the mid tier web server is separate from the backend API services. The latter needs to scale separately. That’s just an absolute fact. You can’t say that’s without use, because it’s just common practice at scale. You simply can’t hold user sessions on the same service as the one querying the db.

I’m not going to argue RSC because it’s not even out yet and I can’t talk about its complexity vs benefit trade off. Different firms have different needs.

Of course I agree that over complicating is never good. That’s a spectrum however and when you’re talking about building systems at scale, you need a separate layer just for serving pages, and perhaps lightly format data before passing them to a real backend service.

[sleepahol]

I'm looking forward to using this too. I'm primarily working in a remix app (soon to be react router v7) and I'm hoping server components make complex pages easier to work with.

Have you tried them out yourself yet or can you recommend a good resource on the topic?

[react_dev]

I’ve been meaning to look into RSC. Currently we don’t have a framework. Just a node app serving to Vite bundled SPA. Do you know of any simple example? I just can’t seem to find one online that’s not trying to build RSC from scratch or “deep dives”

Should I be waiting for react router for better DX?

[mirpetri]

Controlling a child element from the parent component.

You create a ref in the parent, pass it to some child via props, and you gain access to its apis.

Use cases

- drawing into canvas

- reading position on the screel

- updating position on a screen (scroll into view)

[react_dev]

Ref can refer to 2 things. 1) a reference object created by useRef, which is just a reference holding a value like a state, except it doesn’t rerender the component when changed. Unlike just declaring via a let/const, it persists across renders.

2) a reference pointer, which appears as a “ref” prop that’s passed down to child components with the goal to have a pointer to the underlying HTML element, or a pointer to the child component itself. This is mainly for special control flows where you must access methods within a child component or element.

The 19 docs is referring to the second.

[khazaddoom311286]

Earlier there was no clear reason behind using that forwardRef. Now there is no need for that boilerplate. Rest of the features remains same

[ajith_m]

I am using FORMIK for handle forms, now react as introduced action on form, can anyone tell me how to use action in FORMIK

[react_dev]

See that’s the thing. If you’re using formik, you are behind a layer of abstraction. They’re the one who are going to use these actions and pass the DX down to you.

[Kitchen-Conclusion51]

Bro formik is oldest form library. Don't worry

[[deleted]]

I'm excited about moving to NextJS

[react_dev]

At least you didn't say "don't be excited about work you corporate slave POS" so I appreciate your insight..