Question about syntax

Hi, Yesterday I took your package to replace withStyles from material-ui for yours. I have a question about construction <div ...css(styles.classname1, styles.classname2)/> As for me that syntax is slightly redundant and also with that I can’t use “classname” package, as example: { classnames(css(styles.classname1)), {classnames(css(styles.classname2)): this.state.error } }, or simply add some static styles, as example: <div className="error", {...css(styles.classname)}> or <div className={classname({ classnames(css(styles.classname1)), {error: this.state.error})}.

It’s only two cases that I’ve run into in a few days. I’ve wrapped some methods and now it works as always, as example: <div className={classnames(styles.firstLink, styles.secondLink, {error: true})}> That’s work with JSS and Aphrodite.

Methods that I wrap:

const cssWrapper = (...params) => css.apply(css, params).className;
const aphroditeInterfaceCustom = {
    ...aphroditeInterface,
    create (styleHash) {
        const styles = aphroditeInterface.create(styleHash);

        return each(styles, (value, key) => {
            styles[key] = cssWrapper(value);
        });
    }
};

So, maybe I don’t know or missed something, please explain for me why you chose this approach.

[Nazerbayev]

So, if I want to make a shareable component and I want it to be flexible allowing the other party to add their own classnames in the inner pieces of my code then the solution is to make the other party add an additional dependency to their project (and learn how to use it) instead of using the usual pattern of a simple prop?

I apologize if im not understanding something basic, but it seems to me that it goes totally agaisnt the main premise of this library, citing from the very first line of the readme: components without being tightly coupled to one implementation.

Edit: I want to clarify something, i’m not complaining for the sake of complaining, my case is that i’m reading through the source code of react-dates looking for a way to override some style choices that it has, probably making a fork if i have to, and I stumbled upon this library.

[Nazerbayev]

I do agree with The idea is that you don't use class names or inline styles at all, the problem is for example if you are developing a component that will be used as a dependency on other projects. Ideally the component should be flexible enough to allow the users to override your styles, and the easiest way to do that is having one or more props with custom static classnames defined by the user, not the component developer.

Edit: I dont know if adding external static classnames via props is currently possible, at least it is not clear enough how to do that on the current documentation.