Hi everyone,
Weweb Head of Front speaking here,
I am currently working on performances and some architecture review inside Weweb editor code.
I have made some decisions, which may have impact on some of your custom code components.
Before making them final I would like your opinion on this. Do you agree? Is this impactful on your existing component?
Please know these information may change, I will publish a complete breaking changes guide when final decision are made, and this will be mainly base on your feedbacks 
Disclaimer: this is touching mostly advanced features
If i am not clear in my description, please take time to ask me clarification
This post is very long, sorry 
.
wwLayout
Currently a bunch of properties of a wwLayout can only be access when the wwLayout is actually mounted on the page.
It is due to the fact that these properties are only provided in the template of custom components. These cause some performance issue on our side because we need to access this “local” context in a bunch of different places in the editor.
It is also causing some UX issues, especially in the navigator (a component can be listed here without being mounted).
These issues will be more and more present if we had more “v-if” component, similar to modal.
Here is the list of changes we want to make
It will mainly mean update ww-config.js and add a key layout: true.
This will also be a good timing to update bindable property values, and only have true/false instead of true/false/repeatable. bindable: true && layout: true will be the same as bindable: repeatable.
** How migrate this **
We will provide warning is the property is not set correctly in the configuration, but used in a wwLayout. If not doing it, the component will still work, but drag an drop will not be available on the navigator
** Potential breaking changes **
This also mean that wwLayout path property will only be able to target flat property.
On all our components, the only use case not cover by this is when you have an array (dynamic number of wwLayout). Its the case for some dropdown, tabs and old version of sliders. Having a type “layoutArray” is enough to cover this usecase.
So flat property + having layoutArray seems enough to cover all cases, enforcing in the same time good practices. But will be happy to have your opinion on this.
Currently, wwLayout component is accepting two props to disable draging and edition inside it (when a component want to master better the children). Its not that much documented + it’s for some corner cases, so I am not expecting lot of people to use them.
This can lead to issue if these components are not rendered (inside modal for example, which has a v-if), as this information will be lost, and navigator will potentially let you drag and drop.
I want to move this to the ww-config.js. This also means that this property could no longer be dynamic, or just rely on rawContent (content without computation of formula/responsive/states)
** How to migrate this **
If you were relying on this, please move them from your template to the ww-config.
** Breaking change **
Dynamic value will not be supported for these options.
On our codebase, this impact only ww-flexbox which was relying on wwProps to set this value.
Our plan is to have a new component, with a slot and never able to drag and drop.
The only place we used ww-flexbox with this option was the datagrid, so migration will be easy.
Currently there is an update listener available on wwLayout (update event). This is used only on some corner case (mainly side effect when you want to know what item was added/remove)
I want to delete this, and instead push a composable to do this.
This will allow to add elements inside a layout without it being rendered (inside a modal for example, by using the navigator for drag and drop).
This will also make easier to add an element to a wwLayout without knowing where it exist, for example with a shortcut.
** Breaking change **
The update event will no longer be supported. I am curious to know if you were using it?
General Weweb Component
This feature is probably not understand that much, but its very crucial for performance and avoid infinite loop. First an explanation on these properties.
Inside some components, we want to update a content property when an other one change. We often use watchers for that. The problem is that content are share between components repeated in wwLayout, so if you are not carefull, your change/sideEffect will be run once for each instance on the page, instead of just once. This is why we have isACopy property and update:content:effect event.
The current way to do is not really understandable, can be buggy in some corner cases, and is not really developper friendly.
I want to remove this and replace this by a composable useContentEffect.
We will be sure this is run only once and the developer experiences will be improve.
** Breaking change **
isACopy and update:content:effect will be marked as deprecated, and you will need to use the composable instead.
This effect will be relying on rawContent, and so cannot depend on local context (formula, props, state, etc). That’s fine because this is usually a very bad practise.
Currently we pass a wwFrontState prop to every Element and Section
This state is the same for everyone, so i proposed to delete these props and expose it on a composable or global variable (wwLib)
** How to migrate **
The wwFrontState will be marked as deprecated first, then will be deleted. Use the global variable instead
** Breaking changes **
At the moment, this is used for access lang, or breakpoints.
The only remaining usecase not cover by this change is the sectionId property, but this should never have been part of this object, and is used only to create dynamically new object.
I propose to just expose a composable to do this, which will retrieve the sectionId automatically, and improved the dev experience in the meantime.
Properties inside ww-config support a navigator property. Inside it you have a hidden property (mainly to hide stuff in the navigator), which can be a boolean or a function (same but depending on content).
The hidden function was receiving a lot of arguments, but will now only receive rawContent
This feature was not documented, so I am not expecting a lot of impact here
This has no impact on our current components at the moment.
New features
Some of our old components are relying on internal editor logic (reading directly the store) to change behavior depending on selection (mainly toggling state to make other element appearing).
This logic have changed, so they need to use something else (and its a good idea to not rely on internal logic)
Most of these usecases are covered by the wwEditorState props and its isSelected key.
We also propose to add a isChildrenSelected.
If you have some usecase relying on this, I will be happy to hear about it
(on our side, its mainly UX inside the editor, by switching some internal states when selection change)
Sometime you want to add some info available in all children context (the context property in formulas).
This is mainly what wwLayout do, by providing iteration context (item/index) to its children.
Currently, some component already use wwLayoutItemContext to provide the same kind of effect on a custom template loop (ww-kanban for example).
wwLayoutItemContext is mean to provide context for a loop, and have some mandatory props which are not relevant for other usecase. Also context provided like this adds a depth (its an object with a key parent pointing to previous context. Usefull for imbricated loops).
Sometimes you wish to have something simpler, and just add a key to this context.
I want to provide a wwContext component just for that.
Do you think it is usefull? Do you have a usecase in mind?
