🦋 Changeset detected

Latest commit: 4c97750

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Thanks for the PR @JorisAerts!

I worry a bit about the complexity and performance implications of making classMap() itself this expressive, vs allowing users to use whatever plain JS utilities they want to build up the ClassInfo object. We've already had report of classMap() being slow compared to string concatenation, and I'm wary of making it bigger and slower without some more benchmarking.

The recursive object walk can be done with object spread.

The nested array support is equivalent to

const classInfo = Object.fromEntries(classes.flat(Infinity).map((c) => [c, true]));

...${classMap(classInfo)}

and I'm concerned that people would use arrays unnecessarily, when they could just put static classes in the attribute next to the classMap() expression.

I'm more on board with the fixes for #3095 and #2153

Thanks for the review @justinfagnani!

I based the functionality on how Vue.js handles the class attribute. In Vue.js, it's part of the internals, whereas in Lit you have to use classMap.
I also read into the issue about the String concatenation, but I don't see how you can create any function which evaluates user input, versus plain and simple string concatenation. This will always be slower, no matter what.

For performance, I extracted the regex to the module's global scope so it doesn't need recompiling every other time. For the recursion, I made one quite simple function that calls itself so it can get warmed up real quick.

Your solution with .flat maybe worth looking into to avoid recursion.

The reason this function is rather slow, I'd suspect, is possibly heavy DOM manipulation during update(....), because classes get added and removed one by one in for-loops, which causes a DOM manipulation for each class change upon each update. Complex CSS (using computed units like em, lh, ... for example) may require a lot unnecessary recalculation of the styles that way.
I'd also have to look into the JS engines to see how they optimize this, but normally speaking, when having the regex defined inside the function's scope would also have an impact on performance.

Next to that, each classMap-instance also holds reference to two separate Sets for calculating updates.

I would also look into how performance is measured. When long lists get rendered that use classMap, they may trigger — as stated above — a lot of separate DOM updates. Combine that with inefficient component updates at the user's side and you'll be running a lot of unnecessary logic.

If users want to use nested arrays, they now can at their own responsibility, it's not opinionated. That's the flexibility and responsibility I'd put into users' hands. The benefit is that — in a component framework for example — it's easier to compose class-objects and class-arrays using references that are managed elsewhere / in another scope. It enables composition, which was my goal here.