Visual composer

Is your feature request related to a problem? Please describe.
A Visual composer is a pre-historic functionality which is in the core of most CMS systems out there, such as Wordpress. Its an intuitive way of editing and previewing the changes on-the-fly.

Describe the solution you’d like
Much similar to storyblok, it would be interesting to combine the Headless CMS approach with a visual composer, which makes it easy and intuitive to edit and preview pages/content.

Describe alternatives you’ve considered
Only option is to change CMS system.

Additional context
None. There are tons of solutions to this feature out there already which is doing the job quite good.

As much as I love the idea of a visual composer for websites, I do think that the purpose of DatoCMS is broader than serving only content for websites, and that the preview function will do this task just fine for now. (though it might be the majority of it’s usage at the moment)

I believe that a visual composer should be a plugin (That you might initiate building?) and not a core functionality at the moment. IMO there are far more important features to be build before this :slight_smile:

That’s just my five cents on this subject.

1 Like

thank you @simon very interesting hearing that from you, would be useful to know if someone else has the same opinion on this!

I think iterating on the modular content type is the solution to this. With some visual improvements and added display options (for examples: killing padding and modular model name if only one item present; ability to pre-set default expanded/collapsed state of different models; expand-to-fullscreen edit mode; etc) I think modular content could eventually get to the typical Squarespace-style page editing experience, without the slowness and bloat in Squarespace’s interface.

I agree with you @maziarz that many others are doing this, but every time I’ve tried them it’s been a lot of work. For example, Prismic has powerful field composition and rich text models, but when I tried it on a couple of projects I found I was writing hundreds of lines of code just to transform their models into markup (custom link resolvers, etc).

For me, I think the basic model Dato sits on is very solid and easy to deal with on the front end — what I’d like to see is more work on the editor UI and more display options for the various field types.

1 Like

I second @simon that any visual editors / composers should be provided as plugins.

The plugin API currently does not give us enough access to the workspace especially when we talk about visual editors / composers being supported as plugins. The current plugin API just feels hack-ish imo.

Because most users are leveraging Netlify for deploying build times need to be considered. I prominently work with Jekyll so something like a live preview when editing would require rebuild and via Netify this equates to time.

One way to skip rebuilds and achieve seamless preview editing with a generator like Jekyll could possibly be achieved by feeding Dato with a specific version of the site that contains additional tag annotations to the data content acting as connection points to their equivalent modified fields when editing in the CMS - something like this would save having to parse and tokenize any Liquid (in Jekyll’s case that is).

Come to think of it… wouldn’t be all that difficult to achieve. I’d been keen to explore it further if the plugin API allowed it.

1 Like

I’ve thought more about this. It would be really handy to render content outside of the current content pane using the plugin API. The limited frame the plugin API works within prevents us from extending the dashboard and implementing more advanced functionality like a visual composer / live editor.

Providing a new section that we could render an iframe within outside of the content region might be a possible solution which you could do with some minor additions to the SDK.

Main Menu Pane (Plugin Method)

Providing a method via the SDK that could trigger a toggle on the pane. As of now this is handled manually both hovering and clicking the chevron (<).

Main Content Pane (Plugin Method)

The main content pane which contains the model fields, modular content etc is positioned in the center by default. If the SDK could provide a method to set positioning of this pane (left / right).

New Content Pane

The new content pane would need to be appropriately rendered according to position set by the Main content pane (above). Some additional methods provided for this could include a “Jump To” option to switch between models.

Referencing Data (live site preview)

Depending on the projects type this can be handled many different ways. For a global approach where all static site generators could be supported you could employ attribute references on elements contained within the DOM that represent editable data. If a site is using Github you could hook into the Github API and reference code in a particular branch which the live editor could inject. Developers would need to figure it out in most cases.


  • User activates new content pane via button
  • Main menu pane is toggled (hidden)
  • Main content pane position is se, eg: left
  • New content pane is rendered

I was able to generate this by adjusting a few elements via inspector and of course it takes more than that to provide such a feature but given how well the admin architected injecting a pane was very simple. Some food for thought.


hey @nicos

thank you so much for your suggestions!! We’ll consider these for sure in the future for our next iteration.

If we find a way to allow this mainly via plugins by making them more powerful we might actually do it.

We were skeptical of maintaining something like this as it’s too much burden for our small team, but your ideas make sense and maybe this will be possible in the near future. We’ll be in touch!