Aral Balkan
Web dev folks, I’m implementing the ability to pass classes to components in Kitten and could use your thoughts…
Passing a class is easy: <${MyComponent} … class='myClass'> (same as any DOM element). However, in the component, you can’t get a property named “class” as that’s a reserved keyword. Even if you could, I’m worried about polluting the prop namespace (we also have “slot”).
So, I’m thinking, ALL CAPS for special props?
- Won’t clash
- Stands out
- I’m allergic to $ prefixes
Thoughts?
Aral Balkan
@sirber Yes, I know that :) Which is why you can guarantee that the framework-injected ones will not clash (that’s the whole idea) :)
Captain Steph
@aral in JavaScript, variables are in camel case.
Aral Balkan
@virtulis Thanks. I did consider that, but for Kitten I‘m trying to keep things as simple as possible so I discounted it. Not least of all because it might also create the expectation that any DOM property you set on a custom component will be available on the component (which is not the case). I’ll keep it in mind, though… thanks again :)
Meh as a Service
@aral IMO `{ name, slot, class: className }` (or something).
So that the attribute is still named normally and passed under the same name, then in the function you can remap it to whatever you like.
Aral Balkan
@virtulis Right, so CLASS or even Class, now that I think about it 🤔, shouldn’t pollute the property namespace since (by convention) property names are in JavaScript are in camelCase :)
Meh as a Service
@aral polluting the namespace with special stuff is a bigger concern (I will sometimes need to use a prop named `key` in Preact and will struggle to understand why it's not working every damn time).
Tom Boutell
@aral a lot to type, a lot to read. But is there any actual magic around this or is it just a question of what convention you want to propose for it? Does it actually behave any differently from any other prop in other words
Aral Balkan
@boutell The only magic with clas is that the 'class' attribute is translated to something else for you so you don’t have to rename the property to avoid clashing with the keyword. So the parser does the equivalent of the following for you:
function MyComponent ({ class: classList }) { … }
Aral Balkan
@sirber (I feel semantically is does make sense too since these are framework constants you’re not expected to use but not change… changing a slot or the class/classes passed from where the component is being used doesn’t make sense.)
My biggest qualm is how it looks but it looking jarring is actually the idea so I think I’m talking myself into it :)
寮
Aral Balkan
@yetzt *ouch!* :)
yetzt
@aral use clAss to express your annoyance.
Aral Balkan
Folks, thanks for your feedback, appreciate it :)
I think I’m going to implement it as-is (which means the magic slot property in Kitten components now becomes SLOT and the little less magic class property is exposed as CLASS). If any other magic props are added in the future, they’ll follow the same naming convention to differentiate them from regular props and to avoid namespace clashes).
I’ll update the docs, etc., today.
:kitten: 💕
Aral Balkan
@McNeely Thanks! That was one of the things I considered but what happens if Sarah’s building an app for a school and there are a list of classes that get passed into the Timetable component as… you guessed it… classList :)
(As much as I want to keep “slot” – all lowercase, for aesthetic reaons – and would have loved to use “classList” for the reasons you mentioned, I feel avoiding polluting the namespace for authors should take higher priority…)
McNeely
@aral lean into standards and pass an array of strings called classList. This matches the HTML spec and isn't a reserved keyword. Then just always cast to an array if one isn't passed and add them to your element with classList.add
Aral Balkan
@McNeely Yeah, I hear you. On the other hand, they’re special properties injected by the server/framework that you’re expected to use but not change so I guess we can stretch the semantics a little. But, yeah, tradeoffs… ;)
McNeely
@aral all caps are a sensible choice when you're balancing tradeoffs. My only gripe is that using something in all caps typically denotes a constant which classes are not necessarily. But I think that's a relatively minor complaint overall 🤷♂️
Aral Balkan
@McNeely (And thanks again, great to be able to bounce it off of someone.) :)
Aral Balkan
@McNeely Exactly (just using the same name) :)
McNeely
@aral I'm not sure I follow this hypothetical scenario, why are a list of classes getting passed as the third argument? Or do you mean it could potentially just be using the same name (classList) as my proposed third argument array is called?
Aral Balkan
@McNeely e.g., totally fabricated example typed out in Mastodon:
import TimeTable from './TimeTable.component'
const classList = db.classes.where('year').is(2023).get()
export default (request) => {
const studentId = request.session.student.id
return html`
<h1>
<${TimeTable} studentId='${studentId}' classList='${classList}' />
`
}
Aral Balkan
@McNeely Haha, and in this case, there really is a reason for it. Without it being a server and without its focus on simplicity, getting people their own Small Web place in ~30 seconds without technical knowledge to set it up/maintain it would just not be possible. And I see that as a prerequisite for the Small Web having a chance to exist.
McNeely
@aral that's what the internet is for 😁
I've been following you build Kitten out slowly. After all how, can you even call yourself a web developer if you haven't built out your own framework/build system?!
０７６萌ＳＮＳ is a social network, courtesy of ０７６. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All ０７６萌ＳＮＳ content and data are available under the Creative Commons Attribution 3.0 license.