Build-Your-Own Editor Components / Customizable backend widget

✋ Feature Requests
1

This isn’t a serious feature request as it’s practically a whole product, but I thought I’d share an idea I have been thinking about in general probably for a few years. I think it would work great with Dato.

Imagine if there was a set of editor UI components (web components, React, whatever really) that you could add to your site to bring the Dato editor within your site. So you’d create a static page at, say, /admin, and start dropping components onto that and other admin/* pages as you please to build up a CMS editor that is structured exactly how your editors want it.

For example, some pseudo-code showing how you might put together a simple admin homepage:

    <h1>My Blog Admin</h1>

    <!-- Hides once logged in -->
    <!-- Styled as modal overlay -->
    <dato-login api-key="..."></dato-login>

    <p>
      <!-- Provide the count for the given model -->
      Welcome to your blog. You have written <dato-count model="articles"></dato-count> articles!
    </p>

    <p>
      <!-- Plain link to another static page with components -->
      Write a <a href="/admin/new-article.html">new article</a>...
    </p>

    <h2>My Articles</h2>

    <!-- Regular table view for a given model, with given display options -->
    <!-- Clicking an article would probably bring up the default modal editor if nothing else specified -->
    <dato-table model="articles" filter="published" sort="published_at" per-page="10"></dato-table>

    <h2>My Contact Details</h2>

    <!-- A default edit form for a singleton -->
    <dato-edit singleton="contact"></dato-edit>

I think you could do most of this already using Dato’s GraphQL API, but obviously the login component would need custom support.

Over many years working with non-tech-savvy clients I still regularly struggle to communicate to them how CMSs work and how things are structured — especially when their data model is anything more complex than pages and posts. It’s worse with headless CMSs because there’s a big layer of indirection there. Granted it’s better when using live previews with JS generators such as Gatsby, but even then there is still a disconnect between their site and some random product (Dato) who’s name and purpose they forget every five minutes!

I think a modular editor like this could offer a very high quality user experience for content editors, as the editor would be part of the site, and it would be easy to style it the same way (components could have a default neutral styling, and/or just spit out plan HTML and adopt your site’s style give a few custom tweaks).

When you do have an unusual or complex data model — which I seem to be encountering more and more recently — you could build out your own pages to present the models and navigation in a way that’s easy for your editors to understand. Every bit of customisation in Dato’s editor such as the sidebar is welcome and makes it easier to provide a good UI for content editors, but ultimately I don’t think there can be any headless CMS that has enough UI options to compete with a custom CMS. Perhaps components are the solution?

2

Thank you for this, very inspirational! As you say, you could build it yourself with React components (for example). We have some users doing that automatically on the frontend, you could do something like that to build your own CMS, as we did, on top of the APIs :slight_smile:

The only idea that I have that could help you going where you want is if we released some of our components as open source modules. We asked about that some time ago, but we didn’t have much interest really… So not sure if we are going to do that soon, but maybe that’s a possible step forward?

3

I’d be super interested in that — I realise it’s probably the hardest one but a login widget would be amazing. That’s that hardest part to communicate to non-technical editors, that they have to log in somewhere different from their site (even if using a subdomain). It’s that interaction that really highlights how from a lot of editors’ point of view Wordpress, Squarespace etc is better.

I don’t know if there are any CORS gotchas, but I was assuming you could get the login flow done and cookie set from a widget, then proceed to make Dato API calls from other widgets on your static site.

4

A lot of time passed, but now there are services like https://www.stackbit.com/ that do this. If you (or anyone else) has interest in a possible integration between Stackbit and DatoCMS, please let me know at m.giaccone@datocms.com !