Feature Request: Allow multiple classNamePrefixes

[andrew-aladev]

Please refer issue 4230.

classNamePrefix="react-select" is not enough for everyday react select styles customization. react-select can be used in separate component with its own styles together with styles for parent component. Please add ability to use classNamePrefixes={["react-select", "react-select__for-component-x"]}.

Developers don't want to use styled components of other inline styles solutions for political reasons. We have seen enough projects where styles was mixed with business logic inside single javascript file. We have spent a lot of time on refactoring unmaintainable code: inline styles always ends badly.

For now there is only one available workaround: use classNamePrefix="react-select__for-component-x" and .react-select__for-component-x { @extend .react-select }. But this solution is not acceptable from the following perspective:

const A = ({ className }) => (
  <div className={classNames("a", className)}
    <Select classNamePrefix="react-select__for-a" />
  </div>
);

.react-select {
  # common styles.
}

.react-select__for-a {
  @extend .react-select;
  # custom styles.
}

User of component A is able to customize <div class="a my-class-name"> by adding class name. But user is not able to customize <select>. Please imagine that we need to customize component A from component B:

const A = ({ className, selectClassNamePrefix }) => (
  <div className={classNames("a", className)}
    <Select classNamePrefix={selectClassNamePrefix || "react-select__for-a"} />
  </div>
);

const B = () => (
  <div className="b">
    <A className="a-inside-b" selectClassNamePrefix="react-select__for-a-inside-b" />
  </div>
);

.react-select {
  # common styles.
}

.react-select__for-a {
  @extend .react-select;
  # custom styles.
}

.react-select__for-a-inside-b {
  @extend .react-select__for-a;
  # custom styles.
}

We can see that developer of B component have to know implementation of component A to properly extend his class react-select__for-a-inside-b with react-select__for-a (internal class for component A).

And vice versa: developer of A component can't rename react-select__for-a class name prefix without touching other components (like B).

Please review the following proposed solution:

const A = ({ className, selectClassNamePrefixes }) => (
  <div className={classNames("a", className)}
    <Select classNamePrefixes={["react-select", "react-select__for-a", ...selectClassNamePrefixes]} />
  </div>
);

const B = () => (
  <div className="b">
    <A className="a-inside-b" selectClassNamePrefixes={["react-select__for-a-inside-b"]} />
  </div>
);

.react-select {
  # common styles.
}

.react-select__for-a {
  # custom styles.
}

.react-select__for-a-inside-b {
  # custom styles.
}

Every developer implements its own component and know nothing about other components (except its interfaces).

If you will accept this solution, i can prepare a pull request, thank you.

[Rall3n]

In my opinion this does not need a change in the source code. You can easily achieve the same thing using a combination of classNamePrefix and className:

.prefixed__control {
    background: red;
}

.withClass .prefixed__control {
    background: blue;
}

<Select classNamePrefix="prefixed" />
<Select classNamePrefix="prefixed" className="withClass" />

CodeSandbox example

[andrew-aladev]

@Rall3n Hello, className is related to container with input only, users want to customize everything including menu. User is able to customize menu only by using classNamePrefix. Another solution will be to add xxxClassName for every component like containerClassName and menuClassName.

[ebonow]

Greetings @andrew-aladev from an everyday user who prefers stylesheets to styled components.

First of all, className as a react-select prop is defined pretty well in the documentation

className string
Sets a className attribute on the outer component

Take this example from the Discussions Code Gallery:
https://codesandbox.io/s/react-select-inline-83kdi?file=/example.js

It exemplifies a common use case of wanting to apply some modifier from the parent applied to the other custom components. In this case an inline react-select is given the className react-select react-select--inline and the classNamePrefix react-select. The menu can then be targeted as:

Base class
.react-select .react-select__menu
Modified class
.react-select--inline .react-select__menu
Extra specificity modified class
.react-select.react-select--inline .react-select__menu

If you wanted more customization, className is provided as a prop on custom components so that you can specify a className for a particular custom component.

eg:

const Menu = props => <components.Menu className="a-in-b-custom-menu" {...props} />
const MySelect = props => <Select components={{ Menu }} {...props} />

.a-in-b-custom-menu { /* css stuff */ }

As a roadmap note, Jed has expressed interest in creating an api similar to styles but for component classNames to make it easier for those using UI libraries like Tailwind to style components exclusively using classNames.

Please lt me know if any of this helps, or please provide some example that is not satisfied by what @Rall3n or myself have responded with.

[wibed]

@ebonow

this suggestion as proposed here would be a marvelous solution. but my styles keep getting overwritten.
especially for a custom control such as in

const controlClass = [
  "ring-transparent",
  "shadow-none",
  "border-none",
  "outline-primary",
  "focus:ring-transparent",
  "focus:shadow-none",
  "focus:border-none",
  "focus:outline-primary"
].join(' ')
const Control = props => (
    <components.Control {...props}
      className={`${controlClass}`}
    />
)

even the style attribute is ommited because styling is appended afterwards.
maybe i dont get something here. could you elaborate on this?

it is working fine using the styled components approach

const customStyles = {
  control: (provided, state) => ({
    ...provided,
    border: "none",
    
  })
}

which is unusable because i need jit values get rendered

[wibed]

fyi i have ended up working around it using static styles.

but am still intrigued if one could use tailwindcss as it is considering dynamic states such as dark light mode

[andrew-aladev]

@ebonow, Hello. There is a special option: in portaling docs: menuPortalTarget. It detaches menu from container and user is not able to customize it anymore. So classNamePrefix or classNamePrefixes becomes the only one possible option that doesn't affect related react-select functionality. Please review the following example.

Custom components is a good solution, but not universal. If first developer implemented custom select component based on react-select he may not use custom components. Second developer wants to customize custom select for current component just a bit, but he can't. He have to make heavy refactoring of first custom select and add custom components with class names inheritance.

[ebonow]

@andrew-aladev

Good point regarding portalling. A custom MenuPortal would likely be needed to pass in some derived className perhaps even passed in as a custom selectProp.

const MenuPortal = props => 
  <components.MenuPortal className={props.selectProps.menuPortalClassName} {...props} />

From there, writing a Menu/Option styling mixin for Sass would likely be a way to make it easier to address these custom use cases.

To your concerns about being universal, my preference is that there is a base Select that everyone uses with agreed standards so that users do not need to re-engineer similar custom components. I suppose this is simply a personal preference, but I prefer to abstract my implementation away from the base component to either swap out later or add new functionality that I want shared among all my selects.

For example, I prefer the idea of a floating label as opposed to a Placeholder component, and instead pass the placeholder as an attribute to the input when the user focuses on it (blur removes it to avoid overlap). It wouldn't make sense to import and pass this custom Input component to every one of my 100+ Selects, but again to each their own.

That all said, this seems to come down to personal preference and convenience and not so much an actual issue so I will rename this title and have it converted to a Feature Request discussion.

Perhaps this will be addressed in the discussed as a future roadmap item as we look at how to apply classNames to components without the need for writing a custom component simply to pass in a new className.