- Issue created by @bnjmnm
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
I think this is a duplicate of 📌 EntityFormController should load auto save state if it exists Active
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
Postponing on 📌 EntityFormController should load auto save state if it exists Active
- 🇺🇸United States effulgentsia
📌 EntityFormController should load auto save state if it exists Active is in. Is this issue now fixed as well, or is there more to do here that the other one didn't cover?
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
Confirming this still occurs after 📌 EntityFormController should load auto save state if it exists Active - I think it is now a FE issue. Will investigate.
- 🇬🇧United Kingdom jessebaker
I have been testing this and the issue described is fixed, at least partially. When returning to the Page Data tab the selected image is correctly displayed. However after leaving and returning to the page data tab, the remove image button no longer functions correctly as the entire widget is removed from the DOM (as shown in attached video).
Furthermore, the same issue described in the IS is also present for media widgets in the component instance form (leaving the form and returning means the selected image is no longer shown).
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
Furthermore, the same issue described in the IS is also present for media widgets in the component instance form (leaving the form and returning means the selected image is no longer shown).
I think this means we're going to have to mutate the slice after AJAX calls, its ick but with the requirement to 'make existing Drupal forms just work' we're stuck between a rock and a hard place.
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
Came up with a different approach.
Rather than mutate the form HTML in the slice for both the component and page data forms, instead invalidate them on umount if the form_build_id was changed during rendering. This means any ajax operations that update the form trigger an invalidation of the cache when the form is unmounted.
Seems to work in manual testing and was able to write an e2e test to show it is working, switching tabs doesn't clobber things.
So if you're just switching tabs we keep the cached form around and its snappy.
If you make a change to the form that triggers something AJAX-y the next time we mount we make sure to fetch a fresh form because the cached one is stale and doesn't reflect the new state
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
This reveals a fail in multi value widget handling
But it looks as though that exists in HEAD too, the error is that dragging and dropping doesn't trigger an update to the server and autosave - 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
Pushed this forward a bit but still failing on multi-value widget
- Merge request !1258Draft: #3533289 another approach to the tabledrag hassles → (Open) created by bnjmnm
- 🇺🇸United States bnjmnm Ann Arbor, MI
I added 3533289-if-select-value-change-triggers-react-onchange as a draft MR which approaches the tabledrag issue differently - any programmatic changes to the select element are relayed to the onChange callback.
As noted in the MR, if my changes are accompanied by me commenting away the useEffects added to DummyPropsEditForm and PageDataForm, the widget-multivalue.cy.js test is able to get several scenarios further, though it still eventually fails. Although it's not a complete solution, my hopes it is helps surface info that helps us get there.
Also worth noting
I was running into other problems with widget-multivalue.cy.js until I removed the existing components from the layout. More info is in a comment within the test. - 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
Went back to the start on this one.
Started by splitting 🐛 Reordering items in a multi-value field doesn't update auto-save unless the user makes another edit Active for the existing issue with drag and drop in HEAD as the priority of that is lower than the bug here.
Then dropping down to the root of the issue, it is that switching tabs in the side panel causes the form to umount.
This means any AJAX modifications to the form are lost.
And then when we switch back, we restore the form from the cache in the slice, which doesn't have the ajax modifications.So instead of trying to work out when AJAX modifications occur, I looked into the tabset component and realised we can prevent the component from being unmounted with the forceMount option.
And this was the sauce.
We still need to trigger invalidations when the component is unmounted, and that is when we use full page preview or the code editor, so I added code for that.
I then tried to reproduce this with the components input form and could not.
I think the difference with that is we have the query params that tracks the current values of the props when using the slice cache and as a result the form is already being correctly invalidated when we need it to. I added additional matching tests for the component inputs form to verify this and they passed without any changes in HEAD.
So the new changeset is much smaller:
We make sure the page data form remains mounted when switching between tabs
We make sure the page data form cache is invalidated when we come back from preview or code editor
Test coverage for all of the above.The issue with tabledrag is split to 🐛 Reordering items in a multi-value field doesn't update auto-save unless the user makes another edit Active
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
larowlan → changed the visibility of the branch 3533289-if-select-value-change-triggers-react-onchange to hidden.
- 🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
This is now passing and the changes are much smaller than previous iterations 🎉
-
bnjmnm →
committed e0eca9d3 on 0.x authored by
larowlan →
Issue #3533289 by larowlan, bnjmnm, jessebaker, lauriii: Page data form...
-
bnjmnm →
committed e0eca9d3 on 0.x authored by
larowlan →
- 🇺🇸United States bnjmnm Ann Arbor, MI
glad the solution wound up being so elegant! Merged.