In the previous page we've covered how our visual editor runs your project inside a container. Now let's review how visual editing works.
Our visual editor loads your website's homepage inside an iframe, and uses a code module inside the container to communicate between the iframe and its host page.
Whenever there are changes to the DOM of the rendered page, that code module scans the page for any annotations: HTML data attributes that denote where content items and their fields are on the page. Each content piece is an instance of a model, and all its fields are defined in that model. Placing these annotations in the right page elements is the work of components, which render content into a React virtual DOM tree.
Armed with the knowledge of which DOM elements represent content pieces and their fields, the visual editor now lets you hover over the page and edit content. You can edit text fields and styles right over the elements, or use the dedicated content pane to the left.
When you edit any field or modify any styling option, the editor will update the content at its source. By default, a Git-based CMS is used. We also support Contentful as an external CMS in our premium plans. When connected to Contentful, all edits made in our visual editor immediately update the CMS, which marks that entity as changed in the CMS.
In either case, no changes immediately propagate to the production website.
The project configuration defines which types of content can be instantiated as new pages. When you click on "Add new page", the editor presents you with the list of these content types.
- If there are content presets available for the selected contnet type, you can choose any of them to bootstrap the page with initial values.
- You also need to define the slug of the new page, which determines its URL in your site.
The editor will then store the new content object - either as a file when using the default Git-based CMS (based on the slug name you provided), or as a new content item in a connected external CMS.
The editor also lets you add components to the appropriate places within pages, based on the what the page model allows. To learn more on how pages are modeled to accept content within them, see here.
Since everything in Stackbit is based on content, it shouldn't come as a surprise that site-wide configuration and global styles are also implemented as content well-defined by models. You can fully modify these models like any other.
If you look at the source code of our components, you'll see that these configuration content objects are passed into components in the same way as any other content, propagated from the high-level page layout components down to the most basic components. Of course, component code is also yours to tweak as you need, so you can incorporate any new configuration fields that you've defined.
The only "special treatment" these global content objects get in the visual editor is having dedicated buttons to get into editing them - simply making configuration more accessible for content editors.
The editing pane itself is the same as the one used for any other content - the only thing that's special here is that the UI knows to look for a content item of a specific type when you click on any of the dedicated buttons.
For global styles, the expected model name is
ThemeStyle. To learn more about this model and how its contents get injected into the project's Tailwind configuration, see here.
Next up: the website is ready, let's publish changes and talk deployment options.