Custom component for ElementField

[dan-dazlab]

Is it possible to make something like conditions field?

To show a modal with properties and use element field on the right drower as a preview.
For modal I can create a new Vue app on click.
But for element field I limited with fixed types I think. Could I use a custom component instead type?

[adamberecz]

Yes, here's a demo:
https://stackblitz.com/edit/github-v1tqoqcb-cy9673wz?file=src%2Fcomponents%2FModalDisplay.vue,src%2Fcomponents%2FCustomModal.vue,builder.config.js,vueform.config.js

[dan-dazlab]

Awesome! Thanks!

[dan-dazlab]

Is there a way to pass schema props to slot?

modalOptions: {
        type: 'static',
        buttonLabel: 'label',
        attrs: {
          modalOptions: this.elementSchema.modalOptions,
        },
        slots: {
          default: markRaw(ModalDisplay),
        },
        handleEvent() {
          emit('event', ...arguments);
        },
      },
    };

buttonLabel for example

[dan-dazlab]

It seems I found a way. Instead type: 'static', I can use any registered custom element.

[dan-dazlab]

I stuck in other place I have nested Fields and I need to suport schema path for builder.
Is it possible to send something to the modal except builder$? Or get field element there?

[dan-dazlab]

@adamberecz There are some of my guesses but I checked them and they don't work.

Undocumented functions:

builder$.openModal('button-style', {
    element: element,
    elementPath: element.path,
    elementSchema: builder$.selectedElementSchema
})

I tried passing a second parameter to openModal, but it doesn't seem to affect the modal's context or properties. Could you explain how the openModal function works and what parameters it accepts?

BaseElementField properties

I'm using onChangeSchema and onInitSchema as custom properties because they conflict with existing props when used with a custom element type that extends BaseElementField. I also couldn't find documentation on how properties defined in BaseElementField.schema are passed to custom elements.

Watchers implementation

My understanding is that I could use watchers on a BaseElementField like this:

// In field definition
watchers: {
  // Watch for changes in allow_view_in_progress
  '*.allow_view_in_progress': (value, oldValue, { builder$ }) => {
    const pendingPath = 'cms_action.onAddFormLink.button_states.pending'
    const pendingSchema = builder$.getSchema(pendingPath)
    
    if (pendingSchema) {
      pendingSchema.disabled = !value
      builder$.updateSchema(pendingPath, pendingSchema)
      builder$.refreshConfigPanel()
    }
  }
}

Is this the correct approach?

Schema traversal

Another challenge is that I need to write my own schema traversal functions to access nested elements. I can only get the root element using this.elementSchema. Is there a built-in way to access nested schema elements?

[adamberecz]

I simplified things quite a lot and got rid of many of the files that were unnecessary:
https://stackblitz.com/edit/github-aifdn3x5-anmjgpaz

I would recommend not to use composables and fields with reusable schemas until you have a working proof of concept—it will only increase the mental load for anyone (including you) when trying to solve a challenge. Also, think in terms of reactivity instead of init+watcher—they can really make things easier.

I have not went through all of your issues as I believe many of them are now obsolete. If you have a new challenge while working on this feature lets continue here. I'm happy to help, even step by step as soon as you meet a challenge you aren't sure how to solve.

[dan-dazlab]

@adamberecz

Thank you for the excellent guidance! Following your advice to avoid composables and complex schemas before having a working proof of concept, I've completed the simplified implementation.

Here is the updated working code:
https://stackblitz.com/edit/github-aifdn3x5-xxwprvtb

However, I've found some problems with reactivity when updating button_states.
The builder$.updateBuilder and builder$.refreshConfigPanel methods do not trigger the save function on CmsActionField. It works fine when I use the cms_action.request select.

Vice versa, I've added conditions based on cms_action.button_states.pending that depend on cms_action.request, and it has no effect when request changes, while other parts work well with the same conditions.

[adamberecz]

Ok, now I understand fully what you are aiming at and where your issues arise from. In fact it allowed me to simplify things way much further: https://stackblitz.com/edit/github-aifdn3x5-gwhfte2b

The refreshConfigPanel does not trigger save, that's correct, in fact it does the opposite: triggers the load method again after the element's schema is updated in the background, so that the config panel values can get in sync.

Also, the buttons like cms_action.button_states.pending did not store state/data, they only acted as static intermediaries between the config panel and the model and in that case targeting them with conditions have no effect.

The solution is rather simple, you need to store state (or value) in ButtonStyleOptionElement.vue which also makes it trivial to manipulate only that element's data in the modal instead of refreshing the whole element's schema with updateBuilder . Updating ButtonStyleOptionElement's data will trigger the save method in the CmsActionField and things will be taken care of automatically. This can be achieved by passing the update method and value to the modal directly.

The only caveat right now is that I had to add a default value to msCmsActionButton builder element type that contains the default labels/colors for the buttons, which is I think something you can live with.

This could btw also be avoided by using the default property, but it would go beyond the capabilities of the current defineElement method so you would have to take a different approach because you would need more in-depth customization of the useDefault composable. Which sounds worse than it is: this is the GenericElement that defineElement uses under the hood and you would just create a copy of it instead of using defineElement and use the default export of useDefault instead of text. Then you could just add eg. default: { label: 'Initial', colorType: 'secondary' } to the initial button.

[adamberecz]

Just a sidenote I added builder$ as an injectable in builder child components as of 1.10.0 so you no longer have to provide it externally.