Skip to content
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

[Form] Keep preferred choices order in ChoiceType #30985

Merged
merged 1 commit into from May 3, 2019

Conversation

vudaltsov
Copy link
Contributor

@vudaltsov vudaltsov commented Apr 7, 2019

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #5136
License MIT
Doc PR todo

#EUFOSSA

@nicolas-grekas nicolas-grekas added this to the next milestone Apr 7, 2019
@nicolas-grekas
Copy link
Member

Do we need an option for that? Why not make it the only and default behavior?

@vudaltsov
Copy link
Contributor Author

@nicolas-grekas , if that's okay from the BC prospective, I would do that.

@HeahDude
Copy link
Contributor

HeahDude commented Apr 8, 2019

We have to be sure that changing the order does not break BC in some way. But I would favor this behavior if possible indeed.

@nicolas-grekas
Copy link
Member

That's only a "display" order right? and the order is "random", since we don't preserve it,?
If confirmed, I don't see how this would be a BC break/

@HeahDude
Copy link
Contributor

HeahDude commented Apr 8, 2019

The order is not random, it is based on the order of the original choices, ignoring the one set in the preferred choices array.

@vudaltsov
Copy link
Contributor Author

So yeah, the behavior will change, but in a better, more controllable way. I am sure that usually people specify preferred choices in the order they expect or don't care about the order at all.

I am going to do this as a default. In case we get any reasonable complaints, the BC layer would be easy. Otherwise one can just change the order of the preferred choices in the desired way and the issue is gone.

@nicolas-grekas
Copy link
Member

Ok great. Note that adding an argument on a signature is a BC break. I'd suggest not making this optional and just adjust the behavior.

@xabbuh
Copy link
Member

xabbuh commented Apr 9, 2019

Does this have to be configurable per form or would it be enough to pass an argument to the DefaultChoiceListFactory constructor?

@vudaltsov
Copy link
Contributor Author

@xabbuh , we currently discuss to make it the only behavior. So no opt-in and no opt-out. Just change it.

@xabbuh
Copy link
Member

xabbuh commented Apr 9, 2019

I am sure there will be complaints that some JavaScript or test breaks when the order changes.

@vudaltsov vudaltsov force-pushed the keep-preferred-choices-order branch from 1516862 to b15c028 Compare April 12, 2019 12:46
@vudaltsov
Copy link
Contributor Author

@xabbuh , we'll see :)
We don't have any tests broken by the changed order. Neither do other developers, I guess.

@HeahDude , @nicolas-grekas , ready for review!

@vudaltsov vudaltsov marked this pull request as ready for review April 12, 2019 12:48
@vudaltsov vudaltsov force-pushed the keep-preferred-choices-order branch from b15c028 to 88753ee Compare April 12, 2019 12:51
$otherViews
);
}

uksort($preferredViews, static function ($a, $b) use ($preferredViewsOrder): int {
return isset($preferredViewsOrder[$a], $preferredViewsOrder[$b])
Copy link
Contributor Author

@vudaltsov vudaltsov Apr 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is needed when we have groups in preferred views.
It happens in tests and might happen in user land.

@vudaltsov vudaltsov force-pushed the keep-preferred-choices-order branch from 88753ee to 340a2fb Compare April 12, 2019 13:00
@nicolas-grekas nicolas-grekas changed the title [Form] Allow to keep preferred choices order in ChoiceType [Form] Keep preferred choices order in ChoiceType Apr 15, 2019
Copy link
Member

@javiereguiluz javiereguiluz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice to have this old feature request finally implemented!

@vudaltsov
Copy link
Contributor Author

@xabbuh , could you review this PR, please, so that we could merge it?

return \in_array($choice, $preferredChoices, true);
// make sure we have keys that reflect order
$preferredChoices = array_values($preferredChoices);
$preferredChoices = static function ($choice) use ($preferredChoices) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, I'm new to reviews in symfony. Should the usage of static be considered a BC break? It's unlikely someone relies on a Factory in preferredChoices, but possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This closure is only used if the user didn't configure the preferred_choices option as a callable (but as an array). And since we do not access the surrounding object context this change is fine.

@xabbuh xabbuh modified the milestones: next, 4.3 May 3, 2019
@xabbuh
Copy link
Member

xabbuh commented May 3, 2019

Thank you @vudaltsov.

@xabbuh xabbuh merged commit 340a2fb into symfony:master May 3, 2019
xabbuh added a commit that referenced this pull request May 3, 2019
…altsov)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Form] Keep preferred choices order in ChoiceType

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #5136
| License       | MIT
| Doc PR        | todo

#EUFOSSA

Commits
-------

340a2fb Keep preferred_choices order
@vudaltsov vudaltsov deleted the keep-preferred-choices-order branch May 3, 2019 21:09
@fabpot fabpot mentioned this pull request May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants