react 19

[GavinNegron]

PLEASE UPDATE TO SUPPORT REACT 19 IM BEGGING U 👍

[paulincai]

Usually, sending some code the a pull request takes less time than begging.

[ijash]

[Mahmoud-walid]

It is still not working. I use React 19

[danielb7390]

A pull request for this already exists #248

[birdofpreyru]

FYI, I got too annoyed by the lack of proper maintenance of this library, thus I forked it, changed the declared peer dependency for React to v19, and released it to NPM as a new package: https://www.npmjs.com/package/@dr.pogodin/react-helmet. At the moment there is no other changes in my fork, but I'm planning to revise its dependencies & implementation to ensure it is all up-to-date with the latest React features, and to take serious care about its proper maintenance going forward.

[akunal1]

react 19 can handle meta tags in its component tree. so you don't need a helmet for simple cases.

ref: https://react.dev/blog/2024/12/05/react-19#support-for-metadata-tags

example:

  return (
    <>
      <meta name="description" content={formatMessage(home.welcomeBody)} />
      <meta name="keywords" content="example" />
      <meta property="og:url" content={canonicalUrl} />
      <script type="application/ld+json">{JSON.stringify(faqData)}</script>
    <main>
       <h1>Welcome to FAQ page </h1>
        .......
        .....
    </main>
    </>
  );

if you still need the helmet then you may override in your package.json until official support arrives .

//package.json

  "overrides": { 
    "react-helmet-async": {
      "react": "^16.8.0 || ^17 || ^18 || ^19"
    }
  }

[birdofpreyru]

@akunal1 open your eyes, just in the article section you refer to it says

Also, the actual documentation for <title> says

Documentation for <meta> does not include such Pitfall note, but I'd expect it is probably the same, otherwise it would be strange that it tracks duplicated <meta> tags correct overriding them, but not <title> ones.

That's what react-helmet(-async) solves — it allows to render multiple <title> / <meta> / etc. tags where you need them, taking care of the correct overriding of earlier rendered tags by later rendered ones.

[akunal1]

Thanks for the detailed explanation.But In my use-case, I need it for one landing page as all other pages are restricted for search engines. So I wouldn't go with the helmet and can manage duplicates in my dynamic meta tag file.

[birdofpreyru]

Well, in someone's use case there is no need for React at all, just a plain HTML written in a generic text editor... I am glad all those folks don't come here to say that we don't need helmet and react 🤣 🤣 🤣

[akunal1]

I’m genuinely surprised that you still can’t follow a simple reference link or figure out if it’s relevant for your use-case after reading the documentation. Perhaps an inflated sense of self is blocking your ability to process basic information.

[birdofpreyru]

Dude, apparently Helmet is relevant to me (otherwise I wouldn't undertake its forking & refactoring), and to other folks who asked re. React v19 support. Then you come, and quite arrogantly claim underneath my msg about my fork that nobody needs Helmet anymore, as the latest version of React makes its purpose obsolete (at least, that was what you wrote originally, prior to editing); and when I explain (mostly to others who may read it, to avoid any confusion your msg may cause) that Helmet is still relevant in general, you start discussing that for your particular case you may do without it... ok, fine, we all are happy that you personally don't need Helmet for your current project... I am just pointing out that it is a strange reason to come to a thread dedicated to React v19 support by Helmet and to comment that nobody needs it 🤷‍♂

[ChrisCates]

@birdofpreyru, I would love to see Helmet features merged with the current React 19 spec. I honestly don't quite understand the value of the current implementation outside of SSG pages.

Until then, I'm a bit puzzled by the lack of maintenance on this project. Would be nice if @staylor just handed off the package to you.

Adding to that, renderToPipeableString() having an option for two pipes for head and body would make working with popular tools like Vite seamless.

[birdofpreyru]

@ChrisCates yeah... honestly, half of React v19 features seem strange and very opinionated to me... my naive guess is that Vercel's team got too much weight in React Core Team and now they just push hard for whatever is good for their for-business platform and use cases, without much second thought about what makes sense from PoV of good engineering and use with different frameworks. IMHO, kind of a worrying sign for the future of React.

[ChrisCates]

@birdofpreyru, I agree with you. Interesting you mention Next, I am working on a Next alternative using Bun tooling. Since all route files are precompiled/pregenerated. Middleware and various other tooling are trivialized despite the limitations of the Bun core spec. Also, another core thing the framework is focused on is React Server Components and providing better support for Routing with React Server Components.

I love the Next workflow, but, quite frankly, the dev environment (even though I don't mind paying a few extra thousand for prod) has gotten so painfully slow on what I'd consider a mid sized payload project. Which is why I'm working on a Bun alternative.

There is a lot of scope (outside of the business motives) for React to improve... The fact I need to work on a router focused on Server Component rendering speaks for itself in terms of missing scope in React's core spec. (Something that React Router team has seemed to stifle progress in despite all the changes to React's core functionality).

In fact, I am surprised how little proper support there is in the ecosystem for React Server Components for proper production applications.