Name should default to id

[goatfryed]

I'd like to discuss something similar to #346.

That issue wanted to use id as name, which is a problematic default behavior, since id requires more strictness than name.

Now, I think that the other way around is an expected default behavior for most users. Well, atleast I was quite surprised that name autogenerates something, if id is specified.
It's also difficult or impossible to implement in plugins.

The core logic should be rather straight forward. Along the lines of node.name = node.props.name ?? node.props.id ?? generateName(...). But I can't find a way to check whether name was provided as a prop. Why is name omitted von node.props anyway?

I honestly don't see a single use case, where users would actually want an entirely different name autogenerated, when they already specified an id. I rather expect that they

• specify both explicitly, because they need it
• specify both redundant, because they have to
• don't care about one of both

But I honestly can't imagine a single case, where a user would omit one, but require it to be different, or require that a different field has the same name (but not id!) as my other field with that id and another name. Is there actually a valid use case why name must not default to id?

#346 explicitly requested the other way around and I totally agree with the rejection there, so I open this as a new feature request. Yet I'd like to point out that the author was mostly concerned about the duplication, not really about the direction.

[justin-schroeder]

I wouldn‘t say there is some doctrine on why name couldn’t default to the id. Mostly this comes down to semantics and thats a very ticky-tacky "battle ground" where no one emerges with clear consensus. So with that lens, a hazy and subjective lens, I would say that making this change would proliferate the usage of id in FormKit codebases, and this would be a net negative in my opinion. In the context of reactive frameworks, the id attribute should be used sparingly as it implicitly (and I would say often unintentionally) means the owning component can only be used once per DOM — not a metric we are accustomed to think about. This gets even more insidious when considering complex forms with repeaters, steps, or conditionals. In these cases we should avoid the id.

Additionally nodes with explicit id’s are automatically added to the global node registry. Having duplicate ids would not only be a semantic woopsies on the DOM side, but could lead to unpredictable control flow logic in the form itself.

I’m sure these issues are no problem for you but in my experience maintaining FormKit I’m constantly surprised by the lack of basic HTML and JavaScript fundamentals exhibited by developers. Many are unaware that id even has a semantic HTML meaning, so these unintended side effects would be quite a surprise.

Now that being said, like you, I find name, label, and id very redundant in FormKit. Most of the time we could infer everything from a single value. I’ve even thought it might make sense to just make a composable that takes a string of names and produces a form:

const schema = createForm('username,password,confirm_password,accept_terms')

In the meantime I’m not sure there is one way or another that is a super clear win — but honestly you could talk me into it with compelling examples of how this improves the DX and reduces errors.

[goatfryed]

I understand and second your point. Ids shouldn't be used lightly and it shouldn't be promoted over the usage of name.

I questioned a bit why I want to specify id and name and why I want them to be the same. Because honestly, I usually name my properties in camelCase and my html ids in kebab-case, so that's already a difference, although a minor.

You asked a good question and the more I think about it, the more I think that I still haven't understood properly what issue I'm actually trying to solve. So I will think a bit more about it, until I've cleared up my mind. I probably agree with your reasoning.

Even though I explicitly asked about id as name, the better solution might be to create a plugin to generate the id based on the name

[fenilli]

The only reason I would not make name default to id is because ID should be unique, and name isn't unique in a sense of the form, you can have a name be inside a nested group with the same name as one not nested, and both would share the same id, so now its impossible to find the correct one using getNode and in HTML world, that would also not be a thing.