Closed ascorbic closed 1 month ago
In the repro, the fetchpriority
attribute is set for both cases. The warning targets different casings now. Is there some other behavior that changed?
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.
With broken you mean the warning that changed or is there some other, end-user observable behavior that broke?
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.
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 tofetchPriority
. We will remove supportfetchpriority
in a future version. Please check the render method of<Foo>
.
What do you think @eps1lon?
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?
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.
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.
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.
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 https://github.com/vercel/next.js/pull/65235 and https://github.com/ascorbic/unpic-img/pull/644 those are probably most covered), but checking for the existence of use
isn't a great solution.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Summary
In 18.2.0, React allowed the
fetchpriority
prop in all lower case, but did not accept camelizedfetchPriority
. Support for the camelized version was added in #25927, but it seems to have broken the lowercased version. This means there is no variant that works in both 18.2 and 18.3 canary/19 beta.Repro: https://codesandbox.io/p/sandbox/nameless-bird-wvv84h
In 18.2.0
fetchPriority
generates a warning butfetchpriority
works without warning In 18.3.0-canary and later,fetchPriority
works butfetchpriority
generates a warning.