[React 19] React warns about "fetchpriority" props about react

[ascorbic]

I mean the warning. It warns when previously it didn't complain. I think this would count as a breaking change. It renders fine in both cases, so the warning isn't needed.

[rickhanlonii]

It doesn't count as a breaking change, since we don't consider DEV warnings as breaking changes in our development policy: https://react.dev/community/versioning-policy#what-counts-as-a-breaking-change

But we should probably make this a deprecation warning instead of the current text since it implies it doesn't work. Something like:

Warning In React 19,fetchpriority has been renamed to fetchPriority. We will remove support fetchpriority in a future version. Please check the render method of <Foo>.

What do you think @eps1lon?

[ascorbic]

I wish there was a way to feature-detect for it though. A warning is fine for end users, but those of us building libraries will need to support both. Granted, there probably aren't many libraries that need to set that particular prop (and with vercel/next.js#65235 and ascorbic/unpic-img#644 those are probably most covered), but checking for the existence of use isn't a great solution.

[eps1lon]

In the repro, the fetchpriority attribute is set for both cases. The warning targets different casings now. Is there some other behavior that changed?

[ascorbic]

Both should work correctly, with no warnings. fetchpriority works in 18.2.0. Adding support for fetchPriority shouldn't have broken the previously-supported casing, but seems to have done so.

[eps1lon]

With broken you mean the warning that changed or is there some other, end-user observable behavior that broke?

[ascorbic]

Are you planning to remove support? I'm not clear on the policy there: is the plan to only support DOM properties and not HTML attributes?

[eps1lon]

Mabye the "invalid" wording is a bit strong. We should just say it's renamed as @rickhanlonii suggests. But removing support would be a novel thing to do. We haven't done that for any other prop.

[ascorbic]

Is there any reason to not treat them as extra variants that are both supported (like Preact does), and not warn about either? One is the HTML attribute and the other is the DOM property and they both work.

[eps1lon]

It can get confusing with regards to object spreading and handling both casings. We'd have to add additional runtime logic to reconcile all casing variants.

Typechecking would also have to support both casings and would no longer flag if you specify both properties.