Dynamic class name

[Sylvain Prat]

What is the proper way to create a node with a dynamic class name?

I tried:

// does not work => "class" property may not be updated. Use the "classes" property for conditional css classes.
h('div', { class: 'color-' + colorIndex }, 'some content');

// does not work => does not remove the previous class when colorIndex change
var classes = {};
classes['color-' + colorIndex] = true;
h('div', { classes: classes }, 'some content');

I guess I have to enumerate all the other possible classes, setting them to false? What if I can't predict the class name? (say, it's a "template" class entered by a user somewhere)

Looking at the code:

• why don't you allow an update of class? For a performance reason?
• why don't you remove the CSS classes that are not in the classes object when updating the node via classes?

[Johan Gorter]

No one has had issues with this before, but I can imagine there are use-cases like you describe.

lets have a look at all possible solutions that maquette provides:

1. Use classes with an object literal containing all possible classes. Most of the time this should work, because the stylesheet also contains all possible classes, but not if the stylesheet is provided by the user
2. Use a dynamic css-selector h('div.color-' + colorIndex). This means the DOM node will be removed and added again if the colorIndex changes.
3. Use the class property, but as you noticed, this may not be updated (because the code for doing that would be weighing maquette down significantly).
4. Use the styles property. With this you can do powerful things like
   h('div', { styles: { color: 'hsl(' + colorIndex + ', 80%, 35%)' } }
5. Use the afterCreate/afterUpdate callbacks to modify the element.classList yourself

Does any of these solutions work for you?

[Johan Gorter]

To answer your second question, see rule number 2: http://maquettejs.org/docs/rules.html This is for performance reasons.

[Sylvain Prat]

Oh, I didn't know about solution 1. I guess I can use 1 or 2 depending on the knowledge I have of the possible values.

About the performance argument: I encountered other issues with classes previously due to this performance argument and I would love to be able to choose how to handle classes updates, like snabbdom does for example. That would allow the developer to choose between performance or developer-friendliness (my application is really small, I don't need to worry about performance for now).

Anyway, problem solved, thanks!

[Matthew Gadd]

we carry the same pain in dojo 2, we basically end up keeping an entire map of classes just so we don't put the burden on the end user of having to track them. snabbdom has a very useful set of extensibility hooks in general compared to maquette. it would be nice in the future for maquette to get the same kind of functionality (it has some arbitrary hook/applicators already in terms of the eventHandlerInterceptor and the styleApplyer as well as afterCreate and afterUpdate).

[Sylvain Prat]

Linking this problem to #121, maybe it can be improved in the next version