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
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.
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.
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.
Activating
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.
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!
Just want to second fabrizio’s suggestion. It takes a bit of setup (wish that part was easier), but once the code was refactored to support this live preview mode, it became super convenient.
Make some changes, save, open the preview mode window. Changes are instantly there, no re-build needed (in preview mode, Next.js bypasses static rendering and queries the CMS directly). Make some more changes, click save, and the preview window auto-updates a second or two later, without a refresh needed.
While not as quick (or easy to set up) as an integrated visual composer, it has the benefit of being an actual full-fidelity preview, since it inherits all the styles and other components of your live site.
Example:
It works great. It’s just kinda a pain to set up… the Next.js preview mode is cookie-based, which means you have to set up an secret-based API route to enable the mode, create your own “preview mode active” banner to let editors know, and provide a way to unset the cookie in order to disable the preview mode. Worth it though. As a bonus, this even works on the production server (like Vercel) as long as you’re serving Next.js in a hybrid mode and not pure static.
Not sure how it’d work on Netlify or Gatsby or similar =/
With Gatsby Cloud we support incremental builds so the experience there is very similar. A bit slower of course, as it’s not local, but still pleasant.
Honestly, I love Dato and i have for years now - however, my clients constantly ask to preview and make live changes which made me look at Storyblok and more importantly React Bricks, which is an amazing first experience but isnt half as easy as dato. I really think this should be integrated as part of dato for sure. Is there a plugin yet? If not, im going to have to look at other solutions rather soon…
