# \[Reusable Components\] A few feature proposals
**URL:** https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756
**Category:** Developer corner
**Created:** [February 2, 2024, 12:01am UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756 "2024-02-02T00:01:01Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@Broberto](https://community.weweb.io/u/Broberto)
#### Post date: [February 2, 2024, 12:01am UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/1 "2024-02-02T00:01:01Z")
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 🙂
### 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 🙂
---
### Author:  [@Max](https://community.weweb.io/u/Max)
#### Post date: [February 2, 2024, 6:19am UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/2 "2024-02-02T06:19:21Z")
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:
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.
---
### Author:  [@aurelie](https://community.weweb.io/u/aurelie)
#### Post date: [February 2, 2024, 8:55am UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/3 "2024-02-02T08:55:52Z")
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 🙂
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 🙂
Field group: Do you mean small group of properties with a border around, or section grouping like big togglable category?
---
### Author:  [@Broberto](https://community.weweb.io/u/Broberto)
#### Post date: [February 2, 2024, 9:11am UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/4 "2024-02-02T09:11:44Z")
> [@aurelie](#):
>
> Do you mean small group of properties with a border around, or section grouping like big togglable category?
Yes, like for example this one.
---
### Author:  [@MichaelLovell](https://community.weweb.io/u/MichaelLovell)
#### Post date: [February 2, 2024, 9:48pm UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/5 "2024-02-02T21:48:49Z")
+1 for this.
---
### Author:  [@Profound5753](https://community.weweb.io/u/Profound5753)
#### Post date: [February 2, 2024, 10:06pm UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/6 "2024-02-02T22:06:36Z")
+1 too please
---
### Author:  [@carrano\_dot\_dev](https://community.weweb.io/u/carrano_dot_dev)
#### Post date: [February 2, 2024, 10:29pm UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/7 "2024-02-02T22:29:46Z")
I would love it if component variables were automatically exposed globally like how they are if you add, for example, a text input field.
---
### Author:  [@Broberto](https://community.weweb.io/u/Broberto)
#### Post date: [February 2, 2024, 11:07pm UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/8 "2024-02-02T23:07:44Z")
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.
---
### Author:  [@carrano\_dot\_dev](https://community.weweb.io/u/carrano_dot_dev)
#### Post date: [February 2, 2024, 11:10pm UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/9 "2024-02-02T23:10:06Z")
🤦♂️ I just replaced a radio group component I made with the default one because I thought it wasn’t possible. Good to know!
---
### Author:  [@Max](https://community.weweb.io/u/Max)
#### Post date: [February 3, 2024, 6:54am UTC](https://community.weweb.io/t/reusable-components-a-few-feature-proposals/6756/10 "2024-02-03T06:54:23Z")
> [@aurelie](#):
>
> 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)
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.
> [@aurelie](#):
>
> 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?
A formula is fine for me.