You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is no way to "name" pure-function based components like you can for froact.c components. This encourages a semi-bad practice of making every component that could be a function into an actual component with it's extra overhead.
A way we could solve this is via a froact.name() function, that sets the "name" of the next element created by froact.
localfunctionCoolButton(props: { text: string })
froact.name("Cool Button") -- the next textbutton will be called "CoolButton" instead of "TextButton" in the explorerreturnfroact.TextButton({
Text=props.text,
})
end
You would be able to use froact.name in lists, like so:
if multiple names are set in a row, only the oldest name will apply until the name is consumed by creating a froact element, to allow the patterns such as above, where the name "Open Button" overwrites "Cool Button"
This would probably deprecate the key feature in the list's config. I think the key feature isn't very valuable, since it's not able to be derived from multiple props. By having froact.name() be a function, components could name themselves programmatically according to their props, such as froact.name(`Player-{props.userId}`)
This could potentially allow us to replace all children fields with a froact list, which would make writing code a lot simpler, since you won't have to name every single child, and won't run into the issue where children are named like "1", "2", "3", "4", etc, which is terrible for debugging in the explorer. Another solution to the 1 2 3 4 error is proposed here: #10
The text was updated successfully, but these errors were encountered:
Actually, I just realized, we could just expose Name as a property. that would probably be better and more intuitive. We can do this by making the default key in froact.list set to "Name" for Roblox elements, and name for components, similar to how we set LayoutOrder for Roblox elements, and layoutOrder for components.
Although, I do like the idea of setting the names of instances being done in a single unified way. Names of instances are inherently separate from components and even elements I feel, it's mainly just a debugging feature when looking in the explorer.
I do realize this is also impossible, since element creation is done from the most nested element to the outermost nested, so there'd be no way to easily see which element is "next"
Currently, there is no way to "name" pure-function based components like you can for
froact.c
components. This encourages a semi-bad practice of making every component that could be a function into an actual component with it's extra overhead.A way we could solve this is via a
froact.name()
function, that sets the "name" of the next element created by froact.You would be able to use froact.name in lists, like so:
if multiple names are set in a row, only the oldest name will apply until the name is consumed by creating a froact element, to allow the patterns such as above, where the name "Open Button" overwrites "Cool Button"
This would probably deprecate the
key
feature in the list's config. I think thekey
feature isn't very valuable, since it's not able to be derived from multiple props. By havingfroact.name()
be a function, components could name themselves programmatically according to their props, such asfroact.name(`Player-{props.userId}`)
This could potentially allow us to replace all children fields with a froact list, which would make writing code a lot simpler, since you won't have to name every single child, and won't run into the issue where children are named like "1", "2", "3", "4", etc, which is terrible for debugging in the explorer. Another solution to the 1 2 3 4 error is proposed here: #10
The text was updated successfully, but these errors were encountered: