Hi everyone!
On September 25th, we will release a big update that we call “Clean DOM”.
This update will greatly improve the code generated when you publish a WeWeb app because it will clean up the DOM of your live apps by removing superfluous wrappers.
But it will also impact how you work with custom coded components in WeWeb.
I’ve done my best below to explain the technical choices we made and what steps you should take if you’ve been leveraging custom coded components in your WeWeb apps.
A bit of context
For historic reason (mainly interaction in the editor), all WeWeb element were wrapped in a WeWeb Vue component, which was also adding a div in the DOM.
So when your custom code component was <input type="text" /> , it was rendered like this by WeWeb: <div><input type="text" /></div> .
If you put it inside a flexbox, it became <div><div><div><input type="text" /></div></div></div>.
This was causing several issues:
- The DOM depth was growing too fast in complex apps, causing performance issues at times.
- It made it difficult to build more modular and reusable components (like a simple input, or table).
- It made it harder for you to add custom styles and for us to improve how we manage CSS in WeWeb.
Removing these superfluous wrappers was not easy because some features were relying on them:
- Links were supported by this.
- Background videos were supported by this.
- All the editor interface (menu, selection border, etc) were supported by this.
- Some style properties were on this wrapper instead of the element itself.
But here we are, it is done, and we are happy 
Now that you understand what has been removed, you can understand that it can have an impact on custom coded components. We have updated all our own coded components. Here is a a guideline for you, developers, to update yours.
Updating your custom coded components
The tricky part will be to review all your coded components to check that the config is up to date.
In itself, the action of updating a coded component is pretty straightforward: in most cases, all you need to do is change one line in the config file.
We’ll explain everything below but taking a look at our updated repositories can also be helpful if you prefer that approach
And of course, if you have questions, please feel free to post them in reply to this topic so that we can help!
Style is now directly applied to your element
Before, style was applied to the WeWeb wrapper. Now, it is applied directly to your element.
It means that if your custom code component has css properties on its root that are also defined by the WeWeb editor, those property values will be overwritten by the WeWeb editor values.
Display property
The most common example we encountered on our own elements was the display property (we wanted flex for some designs, but WeWeb was applying block). Because WeWeb also handles the display none use case, the display property is handled differently from other properties.
You should use the new options displayAllowedValues property inside the ww-config.js file to whitelist values. It should be an array of allowed values, the first one being the default value if no property is defined (or the fallback if someone bound to a value that has not been explicitly whitelisted).
Example:
Note that, by default, the default value is ['block', 'inline-block'] so if your design requires a different value, you need to define it in the config file.
Other properties (e.g. overflow, background, etc.)
For other properties, we added another configuration key: ignoredStyleProperties. This configuration key allows you to disable WeWeb from handling a specific property.
The properties you add in the ignoredStyleProperties array will be removed from the Editor panel and disappear from the style generated by WeWeb, meaning the style you defined in the coded component will be applied.
Example:
Cleaning unnecessary CSS
Before, when developing a coded component, you sometimes had to add CSS to handle the wrapper. You can now remove this superfluous CSS.
In our own coded components, it was mostly done on width: 100% and border-radius: inherit .
Removed 2 technical classes
While the previous sections summed up the most common ways that this “Clean DOM” update will impact style in custom coded components, this one is more of a corner case.
After the “Clean DOM” release, ww-object and ww-object-elem will no longer exist.
A few very old components on our side were targeting them, and you may have custom css using it. Removing these wrapper should allow you to find a better and cleaner solution to apply your custom style.
Best practices for coded components
Always have one root element (no fragment)
That has always been our recommandation, but it is more important than ever now because WeWeb is using your component to anchor some Editor behavior (selection for example) but also for published behavior like scroll listener
Do not use inheritAttrs: false on your custom coded components
Editor behavior and advanced behavior (like scrolling listener or component actions) are relying on some data-attribute. If you use inheritAttrs and move this to the non root element of your element, you may break certain features.
If you really need it to move style, id or class to an internal element, you still can, but let the attributes in place.
Note: we will update this post closer to the release with a link to an example from our ww-input-advanced-placeholder component so you can take a look at how we implemented this on our side.
Do not disable pointer-events on the root element
In the past, it was one of our “trick” to add pointer-events: none in editing mode, so you could safely select a coded component without interacting with it (focusing select for example while what you want is to edit/select the element).
This is no longer a suitable solution because it will also disable the event we need to support the selection/editing behavior. Our fallback has been to add a pseudo element intercepting the event.
Note: we will update this post closer to the release with a link to an example from our ww-video component so you can take a look at how we implemented this on our side.
New options added to support links and backgroundVideo
We will detail these options at a later date in our developer documentation. In the meantime, you can see both in ww-flexbox if you really need to implement them.
Ok, that’s it for now! As I mentioned above, we will be adding links to a couple of examples in the next few weeks.
In the meantime, if you have any questions, please don’t hesitate to let me know 