Custom Interface
Thanks, yeah I totally understand. I have actually started work on a prototype custom editor for our core content type, but plan for that to actually be a completely external tool. It essentially would be a custom chrome extension with some AI capabilities to pull data from the page you are currently looking at. So, I’m not against a custom interface, I’m just trying to find how we can get the most out of the standard forms within dato for the traditional use-case as a base-layer of functionality.
Native-Feeling Dato Plugins
The issues i’ve mostly been coming up against are where plugins have inherent limitations that make it impossible for them to feel like a native field and fully manage their visual presentation independent of their function. I think these aren’t needs that are necessarily specific to us.
I do think that Dato should strive to support plugins feeling as native as possible. There is a lot in there already like opening modals, opening item pickers, alerts, etc. However, if I use the dato react library to generate a custom select field, I’d expect that the select field would look and behave like a native select field.
It sounds like you have that feedback though and finding these limitations or quirks has helped me learn more about the framework, so I appreciate the discussion.
Our Specific Needs with Computed Fields
We did do an evaluation of other CMS options out there and there didn’t seem to be a lot of support of computed/templated fields, which is a big use case for us. Directus has some basic support that I think is using underlying postgres functionality for computed fields, but it wasn’t completely what we need. I found a surprising amount of capability to do this kind of thing in productivity tools (fibery.io which even has a graphql api, coda.io), but they aren’t well suited for production-level content production. So, Dato’s limitations around this wasn’t special.
I guess the area we didn’t quite fully anticipate is just how client-oriented dato’s plugin system is. We did discover this issue when trying out the Computed Fields plugin, so what I’ve built-out is a model in Dato that represents the transformations as input fields, some action to transform those inputs, then output fields. The idea being the plugin can use that data model to generate the transformed data client-side and a server-side component could use the same data model to say based on the state of this data, here are the transformations i need to execute if I’m pushing content into Dato via the API. I have this working, but was running into visual issues/artifacts that I wasn’t expecting (canvas height and the dropdown/select field issue).