allow css() to take a string (normal css class name) & add it to the className

[jaredly]

so that you can do css(styles.something, "MyLegacyClassName") instead of css(styles.something) + " MyLegacyClassName".

It's a little thing, but I'd sure like it.

[ethangodt]

Have been using classnames for this. Would be great to just do it with aphrodite.

[jaredly]

another common case: css(styles.something, this.props.className)

[xymostech]

I feel like we've discussed this before, but I can't find the conversation. Overall though, I'm against this change.

For one, the point of having a css() function (and not just being able to use classNames with Aphrodite-generated class names) is to ensure that later styles override earlier styles. Since we have no control over the styles in the class name, we wouldn't be able to ensure this for the class names passed in, which would be sad.

Compounding on that, JavaScript is dynamically typed, so I can no longer tell by your css() call what is going to happen, which seems annoying to me. It might generate styles and append a class name, but someone could try passing aphrodite styles to it which would be different.

I'm happy to hear arguments for, but making Aphrodite do more to save a tiny bit of typing doesn't seem worth it to me.

[jaredly]

I actually see the second point as a plus :D "what's going to happen" is "aphrodite will do the appropriate thing". It's unfortunate that there's no way to enforce precedence when using legacy CSS class names, but I don't think that's a deal breaker. the css() function already handles nulls nicely, and so being able to do css(styles.something, this.props.isActive && "Legacy_active") or something would also be great.

It's fine if you don't want to add it, but I feel like it will make gradual adoption of aphrodite more appealing.

[tkh44]

@xymostech I tend to agree with not having the strings appended, but the argument that you won't know what will happen is not a very solid one. Because of !important on the styles (in default mode) you know that your aphrodite generated styles will take precedence.

We might as well list some pro's for this feature

• Having a base set of classes that define layout so that when you measure your elements on mount they are sized correctly

  • This could actually be a feature because you can inline "critical" styles

• When migrating from style sheets to aphrodite this will let you do things in stages

[wellguimaraes]

For now, I'm using a helper fn (workaround) as a replacement of css fn. It's basically a wrapper of css and classnames to achieve this feature.

import { css } from 'aphrodite';
import classNames from 'classnames';

export default function() {
  const styles  = [];
  const classes = [];

  [].forEach.call(arguments, it => {
    if (it && it._definition && it._name)
      styles.push(it);
    else
      classes.push(it);
  });

  return classNames.apply(null, [ ...classes, css(styles) ]);
}

[lencioni]

This was discussed in #8

[winterbe]

I like the proposal of @jaredly because it'd make the integration of Aphrodite into existing projects much easier without the need for helper functions like @wellguimaraes described.

[lencioni]

Considering how easy it is to achieve your desired result by using a wrapping function, I don't see any compelling reason to expand Aphrodite's API to support this use-case.

[lencioni]

This issue seems stale, and the maintainers who have commented seem to be against this proposal, so I'm closing it out. Thanks for the suggestion @jaredly!

[gabssnake]

Both mentioned use cases are quite common for us, what is the "proper" way to handle them?

// Modify styling via props?
css(styles.something, this.props.className)

// Integrate with legacy/external CSS code?
css(styles.something, "MyLegacyClassName")

[tremarkley]

you could also just className={`${css(styles.something)} ${this.props.className}`}

[emin93]

Unfortunately this doesn't do false-checking, so you'll end up having undefined, false, etc. class names. <MyComponent className={isActive && 'my-active-class'} /> would render false as a class name which you probably don't want. I tend towards using the classnames library as long as the maintainers are against including it in the css function.