Fix dropdown lookup state normalization for attribute edit forms#2447
Conversation
|
I slimmed down the changes in #2443 to be just the PR. Some reason, i added fixes for other things that should have been seperated PRs. I'll start creating those now. |
|
Thanks @tazzytazzy I noticed on the attribute editing screen that if you try and edit a dropdown attribute the options appear as empty
Not sure if related to this PR specifically however I feel like it might be useful to investigate as part of this PR. |
|
Yea. I had a patch to that, but then when i cleaned up my other PR, i think it was lost. I'll poke around and try to dig it up again. The issue when away from my side. I'll dig around my past local commits. |
|
Found it. Tested by adding, removing, trying to add duplicate rows, removing rows in the middle, etc. I think a future feature would be nice to re-order the values. :-) Also updated the tests, I'm hoping the updated test is valid. Tests: 1 skipped, 769 passed (2815 assertions) |

Summary
This fixes dropdown attribute lookup hydration when editing attributes in the admin panel. This should resolve PR #2443 too.
Dropdown
lookupsare stored as an array of{ label, value }pairs, but the edit form expects keyed state for theKeyValuecomponent. That mismatch caused lookup state to hydrate incorrectly in attribute edit flows.What changed
Why
The admin attribute edit flow needs dropdown lookup state in keyed form like:
[ 'lookups' => [ 'Foo' => 'bar', ], ]but persisted configuration is stored like:
[ 'lookups' => [ ['label' => 'Foo', 'value' => 'bar'], ], ]Without normalization, the edit form mounts with the wrong shape and the lookup field does not hydrate correctly.
Tests