Gotcha, sorry, missed that reference to model.
Ok, yeah i think that would work.
Sorry, I did play around with this particular extension more, but I am still not sure if I’m still going to use this approach since each field takes up so much room in the editor, but the hiding of fields and controlling the height is definitely relevant to the larger plugin I am working on. I think you shared enough that I could definitely wrap it up.
The other approach I was considering was instead of having these dynamic selection fields as part of the model, I was considering showing the same kind of options as a field extension/editor. I have been testing that approach again given that you shared the example for Dropdown Button Overlay. I got that working and was able to tweak your suggested approach to support the case where a user clicks on the dropdown, but doesn’t click anything. It just still feels a tad janky.
Our core challenge with Dato (besides being trapped in an iframe) is that we have a fair number of computed and dependent fields we use. The plugin system allow us to do what we need to, but since they only operate when a user is editing the content within the dato form, we are having to work through architecturally how we want to manage this functionality when we need it to be applied both in the UI when editing in real time and if we were to publish content through the API.