A small discussion with community. After bit of discussion we've decided to get rid of following API...

# compose-web

[[JB] Shagen]

A small discussion with community. After bit of discussion we've decided to get rid of following API method:

classes {
   +"a"
   +"b"
}

and suggest everyone to use just classes("a", "b"). Since previous release this method behaves cumulative and there are no cases that can be covered with "regular" API call compared to the builder counterpart.

If you know such cases or think that the builder version is still preferable in some cases - let's discuss. We are not making any promises but it would be very helpful at least to take into consideration any points we've missed.

Speak now or never )

[Big Chungus]

Would also be good to get classesFromString() or something that'd allow us to declare all classes via single string (like in html) to make converting components from other frameworks easier.

[[JB] Shagen]

Well personally me like the idea of keeping the core API as small as possible. What you are describing is easily achievable but not necessarily should be in the framework itself. But good point actually, thank you for letting know - we'll discuss this as well.

[Big Chungus]

Might be worth spinning up composex package to shove things like that then?

[louiscad]

compo sex? 🙈

[Big Chungus]

Also, I think it's important to be able to remove a class from component as well.

[Big Chungus]

Not sure if it's possible already

[louiscad]

What are your use cases?

[Big Chungus]

Styling mainly. Think of colouring a button to represent on/off states

[louiscad]

It's just an if?

[louiscad]

If the condition changes, recomposition triggers, and if the different code path doesn't set the classes, they are gone.

[Big Chungus]

Ah, you're right!

[[JB] Shagen]

@Big Chungus we've tried to come up with scenario where one is removing class but failed to invent one. If there's a real-life example we can discuss - sure, let's discuss. But I'm with @louiscad on that )