Lowercase props
What is point of lowercase props "tabIndex" vs "tabindex", "onClick" vs "onclick" and etc?
22 Replies
aesthetics, preference
to more easily migrate code from react 👉 solid or html 👉 solid
Ok.... but what if I have component that has default prop, for expamle "tabIndex". Should I care about both "tabIndex" and "tabindex" or only one of?
good question
from my lil experiment in the playground: i think mergeProp takes care of it
wait sorry mb i m wrong
that would be kinda weird actually
ye... that is a bit unexpected behavior
From the compiler perspective it is same
Only depends on order. ("tabIndex" has higher order)
uhu. ok thanks for the q, i m not gonna use lowercase in my own code anymore 🙂
is a good argument of getting rid of lowercase. mb something they could consider for 2.0
That would be nice to have only one props/events style.
By the way it works as it should, because to override
tabIndex
props
should go first as a first argument of mergeProps
.mm no that's not the case
mergeProps is like
{ ...obj1, ...obj2 }
but the image also didn't tell too much since I was just logging tabIndex
I mean mergeProps=(props, {tabIndex: 1})
I guess the issue is: they can not get rid of lowercase, since they just pass any non-prop attribute as an attribute
That should work.
mm no
if
props.tabIndex === 0
then mergeProps.tabIndex
will still be 1Ok(((
you can think of it as
{...{tabIndex: 0}, ...{tabIndex: 1}}
Not exactly preference but the Solid would give recognition to attributes that are named closer to HTML, so
tabindex
is favorable over tabIndex
in practice the camel-case will overwrite regular case tho
I'm not exactly talking about the runtime but the point is we favor it despite the camel-case being supported
In the future we might remove support for it
like surely one favors
for
over htmlFor
and class
over className
for sure
i would be fine w removing support for camel-case
get rid of camel-case and classlist
So as I understand it right, we should prefer "tabindex" instead of "tabIndex" and also concerns to events? ("onclick" over "onClick")
well events are a different case since they aren't exactly attributes
Got it. Thanks!