-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Refactor reorderable list semantics #123263
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
Conversation
7cd4d89 to
a18805d
Compare
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 make this required because this has to be the same as the scrollview, so It feels weird to me that we let people omit this property.
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.
It's a bit surprising that you have to tell the sliver in which direction it scrolls (and keep that in sync manually with e.g. the ScrollView). I don't think we do this for any other sliver. Can this sliver not find out the scroll direction by e.g. looking up Scrollable.of?
cc @Piinks
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.
This should not be necessary, the scroll direction is provided to the sliver during layout in the SliverConstraints.
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.
Actually, it looks like the scroll direction is already known, there is a _scrollDirection available in the widgets/SliverReorderableListState
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.
Rendering layer may be too late to apply the semantics actions to children.
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.
Right right, SliverReorderableList does not actually have its own rendering object anyways, my mistake. Does the _scrollDirection that is already available from the state work?
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.
@Piinks Do you think using Scrollable.maybeOf would be a good solution?
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.
oh yeah, I missed it, it looks like it was using scrollable.of. I will just use that.
|
I have separated out i18n and reorderablelist changes into separate commit, hopefully this makes it easier to review |
|
a friendly bump |
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.
The first commit is super-hard to review. Maybe separate hand-crafted changes to the tool and automatically generated changes into two separate commits.
Also, do the changes to the tool have to happen in the same PR that modifies the semantics of the reorderable list? Should/could those land separately?
Last, but not least, please get someone more familiar with dev/tools/localization and flutter_localizations to review those bits.
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.
It's a bit surprising that you have to tell the sliver in which direction it scrolls (and keep that in sync manually with e.g. the ScrollView). I don't think we do this for any other sliver. Can this sliver not find out the scroll direction by e.g. looking up Scrollable.of?
cc @Piinks
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.
Is this method a straight copy from reorderable_list.dart?
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
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.
Should this be widgetsLocaleToResources? Maybe add a test that would have failed for this case
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.
wondering: why are they not all const?
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.
this bool decide whether to add const keyword when calling factory. Since material/cupertino pass in parameter to when calling factory, they can't use the const. Will update the name to be more precise
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.
What if this conflicts with the scroll direction provided by the constraints during layout?
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.
| if (widget.scrollDirection == Axis.horizontal) { | |
| if (_scrollDirection == Axis.horizontal) { |
Maybe?
|
turning this into draft until https://github.com/flutter/flutter/pull/123620/files is merged |
0ecd0a7 to
eab3c1a
Compare
|
|
||
| /// The semantics label used for [ReorderableListView] to reorder an item in the | ||
| /// list to the start of the list. | ||
| String get reorderItemToStart; |
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.
Will removing these public getters be a breaking change?
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.
If someone is using it, then yes. It is hard to imagine how people will reuse this though.
I am not sure whether people would extend this class. @thkim1011, do you know if there is use case for that?
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 familiar with any use cases regarding extending the class, but I assume anyone can get the localizations and use those strings in their project? I'm not too sure how we've handled deprecating strings in the past.
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.
This is technically not a breaking change given all tests pass. The breaking change guide states it would be optional whether we announce this as a courtesy. I personally think it is very unlikely this would be a breaking change. WDYT?
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.
If no tests broke that sounds fine to me. I would probably do a global test run in Google before this lands though to make sure.
Piinks
left a comment
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.
goderbauer
left a comment
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.
LGTM!
This reverts commit 94327e7.
|
@Piinks @chunhtai This breaks https://pub.dev/packages/reorderables However, maybe the resolution is for the package maintainer, I believe @hanshengchiu to update the package instead |
|
I will prepare a migration guide and dart fix, it looks like it is more widely used than I think |
|
Thanks @chunhtai ! @borjandev unfortunately any change could potentially break a package on pub.dev Any contributor can add tests to We also look at how our own tests are affected by a change, and how customer tests inside of Google are affected. In this case, our signals worked and the change was reverted after we found Google tests were broken by the change. To learn more about our breaking change policy and how we determine breaking changes, you can read the breaking change section in the wiki. |
Refactor reorderable list semantics

fixes #71396
and move semantics to sliverReoderableList
all i18n related change is in first commit.
reorderable list related change is in second commit
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.