Solvedclassnames Update the package using the clsx implementation?

clsx by @CLSx provides an interesting improvement over the actual classnames package implementation, it's faster and lighter. He has done an awesome job!

However, given how popular classnames is and the relatively small performance improvement of clsx compare to the other dependency we are dealing with (often ~10 kB gzipped & ~10k ops/s). I have some doubt about the advantage of migrating from classnames to clsx: mui-org/material-ui#14152. It's very likely that people will see classnames and clsx in their bundle, resulting in a negative outcome.

@JedWatson Do you have any plan updating this package implementation using clsx as inspiration? I think that it's a path that would really benefit the React community. Thank you.

18 Answers

✔️Accepted Answer

Thanks for raising this @oliviertassinari

I've read through the clsx implementation and have some questions - it is probably faster because it does a lot less safety checks (e.g skips hasOwnProperty and Array.isArray in favour of detecting .push on objects)

Things like that make me concerned because although it's faster and lighter, it's pretty easy to imagine those shortcuts causing problems out there in the real world.

So I wouldn't take the implementation directly but will see if any other optimisations can be made safely. If anyone else wants to suggest something please do.

As a side-note, someone kindly reached out to me and pointed out that I've been missing a bunch of notifications from this repo and it really deserves some love, so I'm fixing that ❤️

Other Answers:

You probably missed the point of open source.

For people interested in performance, they might enjoy https://github.com/merceyz/babel-plugin-optimize-clsx. We are using it on Material-UI, it has yielded a nice free small bundle size reduction.

@TrySound shit%) instead of "edit" pressed "delete" =\

for the history, my comment was:

TrySound maybe because my one at least faster that clsx? correctly handle nulls and does not generate some insane output when unexpected input sneaked?

clsx(()=>{console.log("HELLO")}), null, "WORLD!"); // => "()=>{console.log("HELLO");} null WORLD!"

And if to follow your logic: why clsx created? why classcat created? why they're polluting npm while there were classnames?

The answer is because their authors thought that they creating something better than original lib.
clsx - faster on strings and objects input and ESM-compatible.
classcat - superiorly faster than classnames and clsx but has less handy API and ESM-compatible.
cnbuilder - has same API as classnames, but in some cases even superior classcat in speed, ESM-compatible and written in TS.

Nothing stopped you from talking with maintainer of clsx.

  1. none will rewrite their lib to TS (cause it'll force to change the whole development pipeline).
  2. i'll be the guy who made the PR but not the guy who made the lib.