[Reusable Components] A few feature proposals

I’m just gonna drop here my two cents about what I miss often in the new reusable components, after very great feedbacks for the first thread, and seeing that a lot of those made sense to WeWeb, and the amazing team ended up implementing some of them :slight_smile:

Translatable fields

This is a big one, so far I personally, have worked mostly on multilingual apps, meaning that this feature is gonna be causing a lot of struggles.

Repeater field type

Yes, you can bind an array for now, but for no-code purposes, this would be a nice to have, like for example you have in datagrid, or in Custom Code Elements, you can define this as an array I’m guessing, and it just works out of the box.

Field groups

This is a big one for me personally, I use many options as I tend to go really crazy with my components. And it tends to end up really cluttered really quick, for now the workaround of hiding fields conditionally was suggested.

I’d like to hear also other’s experiences with this still fresh and so far amazing feature as well :slight_smile:

Hi @Broberto!

I completely agree with all your suggestions. The repeater field is optional for me, but translations are currently a bit challenging, and it would be great to be able to group properties.

A few things that are an issue for me:

Naming of the props
I can’t really use camelCase to name the properties, as they are truncated at some point:

image

This isn’t a major issue, but it forces me to use names like “Maximum Size” instead of “maximumSize”. It just makes it slightly inconsistent throughout the app, as all my other variables are named using camelCase. One option could be to have a label field per prop that is displayed on the outside and one name for the variable inside the component. Just like with the custom coded components.

Component actions
I’m sure you mentioned it in another post, but I what is the biggest show stopper for me is that I cannot use component actions (like “Focus element” on input fields) within the component. That makes it hard to isolate logic.

1 Like

Hi everyone,

For label, its because it a label, internally there is an id use as a “name”. Do you write the label somewhere inside the component when you need it? I am not fan of having two labels like setup, as I will not be sure when use one or the other (this is use a lot through the interface)

For component actions, its in QA, should arrived pretty soon :slight_smile:

Translation is on my watch list, as it is already possible in custom code component, but it will require to use a formula on your side, like translate(myVar) instead of just myVar, does it seems okay for you?

Repeater field (we call them List) has been qualified and are on their way :slight_smile:

Field group: Do you mean small group of properties with a border around, or section grouping like big togglable category?

Yes, like for example this one.

1 Like

+1 for this.

1 Like

+1 too please

I would love it if component variables were automatically exposed globally like how they are if you add, for example, a text input field.

After the latest update, you actually can do this :)) I’m gonna be remaking my components to be using these globals, so a lot of work ahead.

1 Like

:man_facepalming: I just replaced a radio group component I made with the default one because I thought it wasn’t possible. Good to know!

Internally, I would prefer to name the variable “maxLength” while it displays as “Max Length” on the external interface. I cannot maintain a concise naming convention if I have to use “Max Length” in my code within the component. This is not a deal breaker, but it makes it difficult to adhere to a naming convention. All variables we use in WeWeb are named in camelCase, except the props in the components, because it is not possible. If I could assign a separate label, this would solve the issue.

A formula is fine for me.