Core UI extending into custom extension

Feature Request
#1

@george how difficult would it be to extend the UI of a core component into a custom component?

Given that the extends functionality works.

dmx.Component("jonl_browser", {
    extends: "browser",
    methods: {
        reload: function () {
            location.reload();
        }
    }
})

Safari 10-03-2023 14.07.30 000268

Unfortunately the UI controls for the browser component are not selectable in the custom_browser_component

Wappler 10-03-2023 14.09.10 000270

Probably hard, right? As you are not using hjson for many of them.

#2

Well we have a few options about this. You can specify a extendOf attribute with array of components you are extension from. Then your properties will be merged with theirs - as different groups then.

You can also optionally provide replaces with a name of component you are replacing if you want to fully replace it. You might also need to supply a priority so that your component match its selector first in case of replacing existing that is.

#3

You can specify a extendOf attribute with array of components you are extension from. Then your properties will be merged with theirs - as different groups then.

This is what is used to convert one component to another like conditional region, right?

And this would merge properties in the panel but not the methods each component implements, right?

In my example, if I extendOf: ['dmx-browser'] I can see in my component actions for a dynamic event all the methods from dmx-browser, but not my newly implemented reload method from jonl_browser

#4

Yes exactly. We have that for attributes currently. Good idea about the dynamic attributes and events extending. Will see what we can do about that as well.

1 Like
#5
#6

I’ve used extendOf but the properties are not being merged.

Check how jonl_browser_property disappears.

Wappler 11-03-2023 11.21.33 000276

Wappler 11-03-2023 11.20.34 000274

I’ve tried several combinations of extendOf and replaces but I can’t seem to achieve one of the most important use cases of extensibility: Add to a Wappler component custom functionality.

I’ve seen a lot of requests in the forum asking for a specific API method or attribute to be added to a Wappler component. Take the calendar as an example.

Say a few methods from the API being used by Wappler component were not added because they were not identified as useful for many people. But maybe it is useful for me. I would like to create a custom component that extends the calendar with the less code possible. This means that I want to keep using Wappler’s calendar but just add one method to the logic and selectable in the UI for that component.

I don’t want to recreate the whole component just to add one method. Is this possible with some combination of extendOf and/or replaces?

If not, a new option called extends for the hjson would be useful. My custom component extends dmx-calendar by adding just one missing method. I would continue using the Wappler calendar component and I would be able to select this custom method in the UI when some sort of event happens.

These properties/methods/attributes would all be labeled with “Extension” or something similar and have a tooltip or popover that points at the custom extension that extends it.

Most probably hooks would have to be added to each Wappler component so that this custom logic can be injected.

Maybe this overcomplicates the matter and there is an easy way.

To summarize it. A way to extend a Wappler component with the least amount of code possible. This means not to recreate the whole component just to add one method. The extendsOf looked promising but as the properties, methods, attributes and events are not being merged in the UI you need to build a whole new UI for the component just to add a missing method.

#7

Actually for just adding dynamic attributes or events you don’t need to extend to a new component at all. Just define those and make them available for the original component.

Also I don’t think that just making new components that are derived from base Wappler ones and just add lung a missing property or method, is a very good idea as we will end up with hundreds of the same components and it will be very difficult to explain to users which component to use.

It is better to let us change the base component and not create a whole jungle of derivations.

#8

True that.

Ok, with the allowedOn.

This is OK if the feature has 30 votes or there is a lot of noise in the forum. But if it’s something that is just useful for my project I fear that it won’t get priority and I will have to copy&pase the full calendar component rules and logic. And maybe that won’t be enough because rules for Wappler components are based on JS code which we can’t use in HJSON.

Still the issue of the properties being merged exists. Is this a bug or something that needs to be implemented?

In other words, if I just need to change a variable in a specific method of Wappler’s calendar component to meet the needs of a project how can I do it without redoing the hjson for the whole calendar component? <- This is basically the ask.

The logic is already extended by the extends property in the component definition.

dmx.Component("jonl_browser", {
    extends: "browser",
    methods: {
        reload: function () {
            location.reload();
        }
    }
})

Safari 10-03-2023 14.07.30 000268

The UI(hjson) is the problematic part.

1 Like