Closed franciscop closed 5 months ago
The raw component tree (virtual DOM?) looks like this, so at this level the selected
and data-selected
look the same (this is from a different example):
pendingProps: {
'data-id': '25',
'data-selected': true,
selected: true,
children: 'Card'
},
memoizedProps: {
'data-id': '25',
'data-selected': true,
selected: true,
children: 'Card'
},
With a forked CodeSandbox, we can see the rendered HTML looks different from the parsed HTML from the string by the browser:
=== React ===
<INPUT disabled="" data-disabled="true"></INPUT>
1 ""
2 true
=== Javascript ===
<INPUT class="injected" disabled="" data-disabled=""></INPUT>
3 ""
4 ""
So I'd like to theorize that it's when renderingn the VirtualDOM to the HTML that this transformation occurs only for the data-attributes. I'm not familiar with the React codebase, but I might guess it's somewhere around here that this happens? One if()
uses the empty string, and the other stringifies the value, which would convert a true
boolean into a "true"
string:
if (type === BOOLEAN || (type === OVERLOADED_BOOLEAN && value === true)) {
// If attribute type is boolean, we know for sure it won't be an execution sink
// and we won't require Trusted Type here.
attributeValue = '';
} else {
// `setAttribute` with objects becomes only `[object]` in IE8/9,
// ('' + value) makes it output the correct toString()-value.
if (enableTrustedTypesIntegration) {
attributeValue = (value: any);
} else {
if (__DEV__) {
checkAttributeStringCoercion(value, attributeName);
}
attributeValue = '' + (value: any);
}
I try to find the answer of first question:
Because you don't set the value of ‘data-disabled’,so the react give the value ‘true’。 when react try to set property of Dom:
Because ‘ disabled’ is the property of Dom,react reset the value to ‘’。
Because ‘data-disabled’ is not the property of Dom,react set the value to ‘’ + rawValue。 That is the difference of react and javascript in your first question。
I agree with the above clarification.
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!
Sincerely,
Savannah(Zi-Yuan) Lin Software engineer Email: @.>@. @.***> LinkedIn: https://www.linkedin.com/in/zi-yuan lingered/ https://www.linkedin.com/in/zi-yuanlin/
On Wed, Apr 10, 2024 at 6:33 PM Francisco Presencia < @.***> wrote:
Closed #24812 https://github.com/facebook/react/issues/24812 as completed.
— Reply to this email directly, view it on GitHub https://github.com/facebook/react/issues/24812#event-12419670545, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6WEVHMUJYLZWLOYJBVBATY4UIQNAVCNFSM52FY2LQ2U5DIOJSWCZC7NNSXTWQAEJEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW4OZRGI2DCOJWG4YDKNBV . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Sorry, but this is bothering me.
I have to use data-disabled={disabled ? "" : undefined}
to keep the functionality up and running.
Since I'm using [data-disabled]
selector in CSS, if that's the case now, I'd have to write [data-disabled="true"]
, which would be more cumbersome.
If I really need to convert to a string, I should manually call disabled.toString()
, instead of automatically implicitly converting like this.
React converts boolean data-attributes to
"true"
, while leaving boolean attributes as""
(empty string). This is inconsistent with the way Javascript works and also it's inconsistent from the way React treats attributes.React version: 18.0.0
Steps To Reproduce
This is what is expected:
Link to code example:
https://codesandbox.io/s/fragrant-thunder-3dsi62?file=/src/App.js
The current behavior
The
data-X
attribute, when it doesn't have a value, is coerced to"true"
, a behavior that is not observed in plain Javascript (stays as""
) and is also not observed with the way React treats plain boolean attributes (also stays as""
).The expected behavior
The boolean attributes, both for plain attributes or data-attributes, behave in the same way. I don't know which one is "the right way", but surely treating them vastly different seems to be the wrong way.
Alternative: maybe this is the expected behavior? But I couldn't find any mention to anything related to this in the official documentation, please let me know if I missed it somehow or if this needs to be documented otherwise.