Improve soundness of ReactDOMFiberInput typings#13367
Merged
philipp-spiess merged 2 commits intofacebook:masterfrom Aug 12, 2018
Merged
Improve soundness of ReactDOMFiberInput typings#13367philipp-spiess merged 2 commits intofacebook:masterfrom
philipp-spiess merged 2 commits intofacebook:masterfrom
Conversation
This is an attempt in improving the soundness for the safe value cast that was added in facebook#11741. We want this to avoid situations like [this one](facebook#13362 (comment)) where we need to remember why we have certain type casts. Additionally we can be sure that we only cast safe values to string. The problem was `getSafeValue()`. It used the (deprecated) `*` type to infer the type which resulted in a passing-through of the implicit `any` of the props `Object`. So `getSafeValue()` was effectively returning `any`. Once I fixed this, I found out that Flow does not allow concatenating all possible types to a string (e.g `"" + false` fails in Flow). To fix this as well, I've opted into making the SafeValue type opaque and added a function that can be used to get the string value. This is sound because we know that SafeValue is already checked. I've verified that the interim function is inlined by the compiler and also looked at a diff of the compiled react-dom bundles to see if I've regressed anything. Seems like we're good.
philipp-spiess
force-pushed
the
philipp/typed-input
branch
from
b2b714b to
3e2f19e
Compare
|
ReactDOM: size: 0.0%, gzip: -0.0% Details of bundled changes.Comparing: 725e499...db84bdc react-dom
Generated by 🚫 dangerJS |
nhunzaker
approved these changes
Aug 11, 2018
Contributor
nhunzaker
left a comment
nhunzaker
left a comment
There was a problem hiding this comment.
This is a great change, 👍
| if (props.type === 'number') { | ||
| if ( | ||
| (value === 0 && node.value === '') || | ||
| // We explicitly want to coerce to number here if possible. |
Contributor
Contributor
Author
|
@raunofreiberg Awesome! Let's merge then, your PR should be fine if you already have that change 👍 |
Collaborator
|
Nit: “safe” has security connotations. We want to be careful with naming like this because the reader might think it implies some particular type of safety (for example safety for emitting into HTML without escaping it). |
Contributor
Author
|
@gaearon Good point. Do you have another idea? Maybe ConcatenateableValue? Feels a bit long and might lead to typos. Maybe |
Contributor
|
|
Collaborator
|
Maybe |
philipp-spiess
added a commit
to philipp-spiess/react
that referenced
this pull request
Aug 12, 2018
Following up on the changes I made in facebook#13367, @gaearon suggest that "safe" could be read as necessary for security. To avoid misleading a reader, I'm changing the name. A few names where discussed in the previous PR. I think `ToStringValue` makes sense since the value itself is not a string yet but an opaque type that can be cast to a string. For the actual string concatenation, I've used `toString` now to avoid confusion: `toStringValueToString` is super weird and it's namespaced anyhow. Definitely open for suggestions here. :) I'll wait until we wrap up facebook#13362 and take care of rebase afterwards.
gaearon
pushed a commit
that referenced
this pull request
Aug 13, 2018
Following up on the changes I made in #13367, @gaearon suggest that "safe" could be read as necessary for security. To avoid misleading a reader, I'm changing the name. A few names where discussed in the previous PR. I think `ToStringValue` makes sense since the value itself is not a string yet but an opaque type that can be cast to a string. For the actual string concatenation, I've used `toString` now to avoid confusion: `toStringValueToString` is super weird and it's namespaced anyhow. Definitely open for suggestions here. :) I'll wait until we wrap up #13362 and take care of rebase afterwards.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an attempt in improving the soundness for the safe value cast that was added in #11741. We want this to avoid situations like this one where we need to remember why we have certain type casts. Additionally we can be sure that we only cast safe values to string.
The problem was
getSafeValue(). It used the (deprecated)*type to infer the type which resulted in a passing-through of the implicitanyof the propsObject. SogetSafeValue()was effectively returningany.Once I fixed this, I found out that Flow does not allow concatenating all possible types to a string (e.g
"" + falsefails in Flow). To fix this as well, I've opted into making the SafeValue type opaque and added a function that can be used to get the string value. This is sound because we know that SafeValue is already checked.I've verified that the interim function is inlined by the compiler and also looked at a diff of the compiled react-dom bundles to see if I've regressed anything. Seems like we're good.