FEAT: [Admin] #100 add functionality to add new content elements between existing ones - #165
Conversation
19d79e8 to
609e2c7
Compare
3195c22 to
9a66d96
Compare
9a66d96 to
72b2117
Compare
crydotsnake
added
Admin
72b2117 to
e8e74cb
Compare
a98f97a to
ec28752
Compare
|
@PiotrTulacz @TheMilek can you guys have a look again and test it? I'm not sure why the Behat test is now failin. |
d2ed480 to
9700ad3
Compare
9700ad3 to
3c64336
Compare
|
I can not find the issue with the behat test :/ I'm not even sure if its related to my changes as the failing test is This is also interesting: |
|
@TheMilek Build is now green. I dont know why it worked now 🤔 |
6f73681 to
f26526b
Compare
|
Commits are now squashed in to one :) |
Now its failing again.. |
|
Todos:
|
fdb66b1 to
5c0c26c
Compare
|
I'm not sure if the failing behat test is because of my changes 🤔 |
crydotsnake
added
UX
|
Hi, @crydotsnake! |
Hi @SzymonFilipek ! Thank you for your feedback! Yes, i will take a look at it :) |
…s between existing ones refactor: improve element moving logic chore: apply suggestion review from TheMilek Co-authored-by: Kamil Grygierzec <53942444+TheMilek@users.noreply.github.com> FIX: style attribute in ux_icon FIX: insert new content element at correct position instead of at the end translation: add missing german translation for add_element [Behat] Fix test files after rebase
9dbb30e to
b05146b
Compare
|
I pushed a new commit that should fix the issue you have reported. I tried to reproduce the issue exactly as you did in your video. And for me it worked fine. Would be great if you could test it again! |
I also fixed an issue with the Quill Editor that when you changed the content, and moved the element, the content was lost. |
|
Hi @crydotsnake! |
cd5149d to
5322d89
Compare
5 participants
This PR adds the feature to add new content elements between existing ones.
Why keys are preserved in
moveCollectionItem(73-74)Swap the two values while both rows keep their original keys. Giving a moved row a new key makes it look like a brand-new element to Symfony's
CollectionType, which only ever appends unknown keys to the end of its children (see the note ininsertCollectionItem). The row would therefore jump to the bottom of the collection instead of moving one position, and every subsequent move would operate on an order that no longer matches what is rendered.Keeping the keys is safe for the stateful WYSIWYG widgets because
ContentElementConfigurationTypeincludes a signature of the element's content in the configuration container's DOM ID. When the content at a position changes, so does that ID, causing the Live Component to replace the entire subtree instead of morphing the widget in place.Why keys are replaced in
insertCollectionItem(128-129)Symfony's
CollectionType(viaResizeFormListener) never reorders existing form children. It only appends keys that it does not have yet, always at the end of its internal list, regardless of where that key appears in the submitted array.Giving only the new row a fresh key is therefore not enough to place it in the middle of the collection: the form would still render it last. Every row from the insertion point onward must look "new" so that Symfony drops and re-appends that entire tail in a single pass, in the order we submit it, placing it immediately after the untouched prefix.
Rows strictly before the insertion point keep their original key and DOM node untouched.