- Issue created by @larowlan
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
This would be a massive change in the auto-save architecture.
Unfortunately, the ADR for that still hasn't landed: π Document the reasons for not using Workspaces for saving in 0.2.0 Active . π¬
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
The only other way I can see us 'recovering' when a fallback component is stored in auto save AND the component it replaced reappears is if we have an event listener that listens to config events and detects the change of source plugin in a config entity from fallback to something else. The listener would have to loop over autosave data and pass the component props to the new source plugin and ask it to transform input data to client data and then re-save the entry. Now that I type that out, it might be less effort and more perfomant than making autosave do to/from client data on every read and write
I think it's worth exploring if we can detect that scenario with existing config events
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Yes! this worked, updating issue summary and opening an MR, snuck in just under my 1hr timebox I allowed for it.
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Wow, very cool to see that:
- this uses the infrastructure that π Add a route for PATCHing both a config entity and its auto-saved version together Active added
- this basically does what I suggested over at #3515629-16: FieldWidget's XB transforms must be bubbled by the Field Widget rendering to inform the client β .2, where I sketched how I think this could actually happen automatically β .
Very cool!