-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layout child fixed size should not be fixed by default and should always have a value set #46139
Merged
Merged
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
477908f
Change behaviour of fixed child size to not be fixed by default
tellthemachines 07de731
Fix boo-boo
tellthemachines 40d0ac2
Remove unshrink control
tellthemachines 2ec5ac7
Determine fixed size automatically
tellthemachines c9e50f7
Revert "Determine fixed size automatically"
tellthemachines File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the value as a fallback in all cases appears to cause an odd behaviour when editing / removing the fixed value altogether, because it winds up getting a closer to fresh value for the width. Here's a screengrab (initially set to
200px
, then after deleting the value and clicking out of the field, it sets it to95px
:Would it work to use
blockSize
within theonChange
handler when switching betweenfit
andfixed
instead? Edit: ah wait, I see you're already doing that. I guess the question is then, do we need to include the fallback onvalue
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the question. If we remove the fallback from
value
the field won't be pre-populated, which I think is a requirement?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good point, my apologies, I missed that detail of the requirement that James mentioned. I'd been thinking of the Fit -> Fixed selection and not the saved empty Fixed state problem 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries, always worth asking!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just thought I'd hack around a little bit. The only other way I could come up with addressing that requirement while preventing the
95px
issue from showing up, would be to add a bit of logic so that when the block is initially selected, it displays as iffit
were selected iffixed
is selected butflexSize
is empty:Then, in the
ToggleGroupControl
change handler we'd callsetShowFit( false )
whenever the value changes. And the bits where we're referring toselfStretch
would become the slightly awkward:With that in place, I think we could then remove the
blockSize
fallback invalue={ flexSize || blockSize }
, but overall it would be slightly different behaviour than what was asked for.Feel free to ignore all that, though, I was mostly curious to better understand how it's working! 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't that hide the input altogether when it has no value? I'm not sure we want that; the idea is that if 'fixed' is selected the input should be pre-populated with the current width/height of the block, so we have to pass
blockSize
as the value unless there's an existingflexSize
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it would hide it when initially selected if it doesn't have a
flexSize
value, and would default to display 'fit' instead. I'm not really advocating for that, but it was the only behaviour I could figure out that avoided accidentally displaying the wrong width value when a user clears out the Fixed input field and then tabs away.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thought: the issue of the wrong width value only appears when you tab away from the cleared input field, and is correct again if you select another block and then click to re-select the block you were initially working on. Personally, I'd be fine with the idea of merging this PR as-is, and us continue to fix/tweak in follow-ups if need be.