Standardize innerProps and className props on customizable components

[Methuselah96]

Resolves #2909.

See #4289 (comment) for the explanation of why we spread innerProps to all components.

This PR:

• Adds innerProps to components that were missing them (Group, MenuPortal, ValueContainer, IndicatorsContainer).
• Adds classname prop to MenuPortal.
• Moves all of the innerProps spreads to be the last prop for consistency so that all props are overridable if desired.

[changeset-bot]

🦋 Changeset detected

Latest commit: 11aea80

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
react-select	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 11aea80:

Sandbox	Source
react-codesandboxer-example	Configuration

[ebonow]

Looks good! Thanks for the quick turnaround on this.

[JedWatson]

Moving this to 3.3 because it needs more review, and 3.2 is about to be released

[ebonow]

@Methuselah96 I was hoping to get your thoughts on one more thing. What are your thoughts on adding Emotion labels to the Indicator components like many of the other components?

This would be add consistency and I think achieves a bit more visibility especially for automated testing as there is no reliable method to identify the specific indicators to reliably trigger menu down or trigger a clear event.

Here is what I have in mind for indicators.js

const indicatorCSS = (label: string) => ({ ...baseCSS, label });

export const dropdownIndicatorCSS = indicatorCSS('dropdownIndicator');
export const loadingIndicatorCSS = indicatorCSS('loadingIndicator');

The indicatorSeparator and loadingIndicator can have their labels applied directly to their CSS objects, but I think the dropdown and clear indicators are probably the most important (as well as multiValueClear) to create some kind of more reliable DOM selection attributes for these 3 interactive components which each reliably trigger some action.

Thoughts?

[Methuselah96]

@ebonow Yeah, I'm not opposed. Looks like both dropdownIndicator and clearIndicator share the indicatorContainer label, so it would be a breaking change if we wanted to distinguish between the two. (You mentioned loadingIndicator in your comment, but it looks like loadingIndicator already has a unique label.)

Either way, it probably makes to keep the changes in a separate PR so the current changes don't get held up.

[ebonow]

Totally fair. I think I mistook indicatorsContainer and indicatorContainer. It makes sense that they have the same label given they share the same css. Also a bit confusing since there is no specified indicatorContainer.

[JedWatson]

👍