Allow replacing of previous class names about classnames HOT 13 CLOSED

👍 on this.

from classnames.

As long as there isn't a negative performance impact, I think this is a reasonable change to the API.

from classnames.

I personally don't think de duplication is the responsibility of this library, given it is entirely a user input problem.

from classnames.

Can someone put forward the use-case that is driving this requirement? (I mean big picture, not simple example)

Looking at the complexity of implementation I'm inclined to agree with @dcousens

from classnames.

So my use case is that a React component which uses this library to allow class name overwrites w/ a specific set of default classNames, so something like classNames('foo', extraStuff).

Conceptually since this library allows a chaining/combining a set of class names, specifying {foo: false} at the end of the chain and have it still appear in the output makes it very hard to debug, as you basically have to crawl down the chain of abstractions and figure out which layer injected foo in. And since foo will always be there you need to have hacky CSS rule to make certain selectors more specific and/or throw !important in there.

from classnames.

I agree with @dcousens but I also have 2 compelling reasons for adding this in anyway:

1. In order to do the de-duplication outside of the library one would have to parse the inputs and do most of the work that the library already does.
2. Allowing later arguments to overwrite previous arguments is more idiomatic and almost expected behavior (think _.extend).

from classnames.

@cezar-berea We're having some discussion in the PR itself. @JedWatson mentioned exposing .dedupe (or .merge if we wanna be similar to _.merge) and I think that's probably best as an opt-in due to performance impact

from classnames.

@JedWatson what is your conclusion here, .dedupe?

from classnames.

can someone get that merged?

from classnames.

@3den will land it this weekend.

from classnames.

@JedWatson as .dedupe?

from classnames.

Closing this in favour of #31

from classnames.

Just released 2.1.0 with this included.

from classnames.