@majgaard looks like @emotion/jest is not updated to the latest version, it is still pointing to jest-emotion, and is used here, https://github.com/JedWatson/react-select/blob/master/packages/react-select/src/tests/Select.test.js#L15 I found this while I was forking and updating to emotion-11 using the codemod rule "@emotion/pkg-renaming": "error"

Not sure this is a blocker for this PR to go.

I was also experiencing the same issue using a CRA application. When running locally there is no issue, but when I build and deploy using CSR the Select components are "unstyled" and display aria message text as described by @marcopaivaa and @NikhilAnand95.

I'm using the following packages:

• react: 16.8.6
• react-select: 3.2.0
• @emotion/react: 11.1.1
• @emotion/styled: 11.0.0

The Select component is used in multiple components (Components A). There is one component that contains both the Select component and an @emotion/styled component (Component B). Upon initial observation the Select appears to be intermittently "unstyled", however upon further inspection it would appear that @emotion/styled is overwriting the styles for the Select component.

Scenario 1

1. Navigate first to Component B and the Select is styled correctly.
2. Navigate to any Component A and the Select is still styled correctly.
3. Navigate to either Component A or B and the Select is still styled correctly.

Scenario 2

1. Navigate first to Component A and the Select is styled correctly.
2. Navigate to Component B and the Select is "unstyled" and aria message text displayed.
3. Navigate back to Component A and the Select is "unstyled" and aria message text displayed.

Scenario 3

1. Navigate first to any Component A and the Select is styled correctly.
2. Navigate to any Component A without navigating to Component B and the Select is still styled correctly.

It would appear that @emotion/styled is overriding the styles for the Select component if the @emotion/styled component is rendered after the Select component is first rendered as suggested by @ebonow.

To fix the issue I replaced @emotion/styled with the styled-components package and there were no longer any conflicts between the packages.

Right now react-select positions the dropdowns right below the originating input element. This is problematic in situations when there's not enough space on the bottom of the page or of its scrollable container because the page will be enlarged to make the dropdown fit.

If you used a positioning engine like react-popper the dropdown could be positioned where there's more available space. The library is very lightweight and supports all your use cases.

The prop menuPlacement has been created since the creation of this issue. While the merits of @jossmac's suggestion doesn't go unnoticed, the move to react-hooks is a much larger undertaking and there are other existing issues to address menu positioning concerns (ie: available space defined from "bottom of window" instead of "bottom of ancestor node with no overflow"). As such, I will be marking this as closed.

When running the Axe accessibility tester against the react-select v2 code-sandbox, two critical issues are identified:

• Form elements must have labels. While you can pass aria-label as a prop to the Select component, it is not assigned as an attribute to the #react-select-2-input HTML element. Adding this attribute satisfies the Axe tester.
• Certain ARIA roles must be contained by particular parents. Each .select__option has role="option"; however, the parent div .select__menu-list does not have role="listbox". Adding this attribute satisfies the Axe tester. Note that I had to use React Developer Tools to set menuIsOpen on the StateManager to see this violation.

Below are screenshots of the Axe test results.

Greetings,

This issue was reopened due to the use-case of the aria-label not being applied to the "DummyInput" which impairs accessibility to the Select when isSearchable = false.

I can confirm that this behavior has been addressed here: https://github.com/JedWatson/react-select/pull/3090 demo: codesandbox

Since the described behavior which caused this issue to be reopened has been resolved, I will be closing this issue again with the understanding that this will give more visibility to remaining accessibility issues.

Confirming that this is still broken in 2.4.4 and 3.2

Thanks

I am still getting this issue. I thought this was working with react 17?

 const depOptions = filtersResponseObj.dep.map(f => ({ value: f.id, label: f.label }))
 const [activeDep, setActiveDep] = useState<ValueType<OptionType>>(depOptions[0])
 
  <Select
        value={activeDep}
        onChange={option => setActiveDep(option)}
        options={depOptions}
        getOptionValue={option => option.label}
      />

This finally working for me. getOptionValue={option => option.label} was what I was missing. Thanks!

@Rall3n I am facing issue in version 1.2.1. I have created a stack overflow question. Can you please guide me on this? https://stackoverflow.com/questions/59031421/word-wrap-instead-of-ellipses-in-react-select-v-1-2-1-with-multi-false

How did you fix the issue?

What docs page needs to be fixed?

• Recipes:
• Usage With TypeScript:

What is the problem?

the "The full source code is available on codesandbox here. " points to 404

What should be changed to fix the problem?

Point to an existing code sandbox :-) I found something similar here - https://codesandbox.io/s/redux-typescript-example-forked-medu6 but it's a fork and I'm not sure what are the changes between it and the original code

Greetings and apologies for the long delay in a response from the collaboration team.

I noticed that this is a screenshot from v1 and was wondering if this is still an issue for v2 or v3? I am uncertain what accessibility strategy was used at the time, but for now, aria-live is being used for a11y.

Based on the behavior, I would be apt to believe that the screenreader is reading "blank" because the input is cleared on blur. It would seem reasonable to perhaps set the aria-label onChange, onBlur, or perhaps even onFocus depending on timings.

I want us to be able to address accessibility in an intelligent way, and for now that focus is on aria-live for v3.3, but we will continue to look into ways to support WIA-ARIA following that to ensure that we are not introducing conflicts related to competing audio cues.

I will be marking this as awaiting-author-response to see if there is anyone that confirm that this is still an issue within the library or if this is simply expected behavior. I also am not sure what the status of this is versus aria-live, so please feel free to add any findings so we can appropriately handle this issue.

Greetings @vitaly-zdanevich and sorry for the long wait for a reply.

Applied this to the body and it's certainly a start.

My question for this would be the expectation of a dark theme for react-select itself as its presented throughout the documentation. On one hand, it would fit the documentation better, but on another, it could potentially add complexity to all of the code examples for the sake of documentation aesthetics.

@bladey would you be able to inquire a bit more internally about any existing atlaskit dark themes? I'm curious if something like this already exists.

Otherwise @Jeffshek shared his dark theme in an open thread here: https://github.com/JedWatson/react-select/issues/3692#issuecomment-671084399 that can be applied to react-select

I read that opinion here but it's also worth mentioning that the article is over 9 years old... so there's that.

Here is another article I came across from a few years ago that shows a few different representations of how different SR's treat optgroup which shows a bit of variation

I'm interested in taking on aria-live support for this, but unsure what expectations would be.

@carsonpowers it appears that SR behavior can vary. Does this behavior noted from the second link seem accurate to you, or is this out of date?

What seems most relevant and at what point? It seems reasonable with aria-live that when new results are returned we announce the total, and then as they focus on new options we can give them the count within the group: ie: "7 items, focused on "Apple, Fruit, 1 of 3"

WIA-ARIA support for groups might be a bit more complicated, so interested in how we might want to approach it.

Hi there.

I am trying to save the selected value of the menu to a state using the useState hook, but unfortunately, the state does not immediately update and I have no clue if this is an issue on the react-select side. I also tried this same thing multiple times but it does not seem to update:

Using a normal useState hook like here:

const [selected, setSelected] = useState(null);

Then I try to actually call the function in the onChange event like here:

onChange={(a, b) => {
  setSelected(a.value);
  console.log(selected);
  // I expect 'selected' to be my value of the selected option (but this one still outputs "null", like the initial state).
  // After changing the selected option for the 2nd time, the first option (that was before selected) gets logged.. 
}}

It looks like my state is not immediately being updated, but I am not sure. Could this be because I am using Next.js and importing the library through this way:

const SelectMenu = dynamic(() => import("react-select"), {
  ssr: false,
}) as Select;

I don't think this should make a difference, without using that, I get a bunch of SSR errors.. but really strange issue and I can't get the correct selected value because of this.

I hope someone is able to help me out, thank you!

Greetings @gino,

To piggyback off of @manvydasu, this is likely the bit of documentation worth looking at that might resolve some confusion. https://reactjs.org/docs/hooks-faq.html#why-am-i-seeing-stale-props-or-state-inside-my-function

I will be closing this issue now as it does not appear to be an issue with react-select, but is instead the expected behavior when using react hooks. Please feel free to ask any other questions here or in the Discussions area.

- Microsoft.AspNetCore.Authentication.Cookies.ITicketStore.RetrieveAsync(string! key) -> System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.AuthenticationTicket!>!
+ Microsoft.AspNetCore.Authentication.Cookies.ITicketStore.RetrieveAsync(string! key) -> System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.AuthenticationTicket?>!

Hello @gino I believe it would be good for your to go through react docs again to understand how state works.

In your case, 'selected' is still pointing to the old state. Componenet has to re-render for it to have new value. Anyways, in your onChange function, you should use a.value instead of selected if you want to do something with the new value.

@gino This has nothing to do with this library. This is a common mistake which happens when you are using the React hooks.

The state is being updated, no question. But the value of the selected variable inside your onChange handler will always be null. That is because the function itself is never changing. It is being declared once and never updated.

For that you have to use the useCallback hook.

Coverage without using optgroup exists here FWIW; however, semantic markup is always preferable...

Where did you read about there being poor support for optgroup? Obviously, this doesn't look ideal...

I'm interested in hearing from a JAWS user on grouped dropdown items. I've never looked into grouped select options.

Hi there.

I am trying to save the selected value of the menu to a state using the useState hook, but unfortunately, the state does not immediately update and I have no clue if this is an issue on the react-select side. I also tried this same thing multiple times but it does not seem to update:

Using a normal useState hook like here:

const [selected, setSelected] = useState(null);

Then I try to actually call the function in the onChange event like here:

onChange={(a, b) => {
  setSelected(a.value);
  console.log(selected);
  // I expect 'selected' to be my value of the selected option (but this one still outputs "null", like the initial state).
  // After changing the selected option for the 2nd time, the first option (that was before selected) gets logged.. 
}}

It looks like my state is not immediately being updated, but I am not sure. Could this be because I am using Next.js and importing the library through this way:

const SelectMenu = dynamic(() => import("react-select"), {
  ssr: false,
}) as Select;

I don't think this should make a difference, without using that, I get a bunch of SSR errors.. but really strange issue and I can't get the correct selected value because of this.

I hope someone is able to help me out, thank you!

Update 01/17/21: Deployment to all regions completed on 01/15/21. Please post any follow up questions on discussion issue Azure/app-service-announcements-discussions#175

I have minimal information right now, but I wanted to bring this to attention while I was gathering more information.

I haven't been able to reproduce this in codesandbox yet.

I'm running a React-Native-Web project on React-Native 0.57.30, React 16.6, and TypeScript 3.5.3.

I have been running React-Select 3.0.8 with no issues. After upgrading to React 3.1.0 I not receive an error every time I open up the dropdown in the app that is simply

TypeError: newProps is undefined

It looks like this is the location the error is happening from my bundle.js

In Select.js

        const [newProps, newSelectValue] = (newArgs: [Props, OptionsType]);
        const [lastProps, lastSelectValue] = (lastArgs: [Props, OptionsType]);

        return isEqual(newSelectValue, lastSelectValue)
          && isEqual(newProps.inputValue, lastProps.inputValue)
          && isEqual(newProps.options, lastProps.options);

This causes a runtime error that makes our app unusable.

It looks like to me that somehow newProps is undefined and so when tit goes to get the inputValue, that is when it errors out.

I'm not sure why I haven't been able to get a codesandbox of this with similar parameters as in our app, so that part would require some investigation on my part, but it seems like it should be able to be solved from erroring out with an undefined checker at the very least.

Greetings @varzaman and apologies for the extremely late reply. Thank you for reporting this.

Upon closer review, the behavior you are describing seems to be consistent with another open issue: https://github.com/JedWatson/react-select/issues/3452

Please refer to the above issue and see if there is anything present there that could help you resolve your build issues. I will be closing this as a duplicate so please feel free to reply or add any extra questions or concerns there so that we can consolidate our support efforts.

@carsonpowers I have been attempting to read a bit more about how screenreaders handle optgroup. It appears that OSX VoiceOver does indeed list all of the options under the total amount, but additionally, optgroup tags are focusable but disabled. I have also read that WAI-ARIA has poor support for optgroup so it's also unclear to me what could/should be done for that approach.

From an accessibility perspective, I am curious if @kylemh has any thoughts regarding best practices for supporting groups.

@5ebastianMeier

My thoughts are that the behavior you are describing is too narrow of a use-case to be considered as a built-in feature request given the complexity of criteria, so this would be a pass from me and likely the other collaborators.

Perhaps better are some discussions being had in regards to https://github.com/JedWatson/react-select/pull/4080 to better define what the default focused option should be when the menu opens giving the user more control to define what should be selected.

Given your use-case and wanting to preserve the focus option, I would err on the side of simplicity and consider an existing implementation of Select that would better fit what you are trying to achieve. Since you are already using closeMenuOnSelect, have you also looked at hideSelectedOptions?

From a UX perspective, it sounds like the use-case is that the user is very likely to want to select consecutive items. Keeping the selected options maintains the context of the last selection as opposed to focusing an option that may appear arbitrary.

This would allow the selected option to remain focused which benefits the user by giving them more context as to what is focused. Generally this approach is better clarified by providing providing checkboxes in front of each option and seems more in line with achieving what the UX you are looking for. This approach also takes into account what happens if a user does open/close the menu or decides to type more filter text.

<Select 
  isMulti={true} 
  closeMenuOnSelect={false}
  hideSelectedOptions={false}
  {...otherProps}
/>

https://codesandbox.io/s/codesandboxer-example-forked-wdq8n?file=/example.js

If you are steadfast on your approach, then it could be complex to obtain with the existing api. For starters, it won't be as responsive as it would have to rely on onMenuOpen and as of now, the menuListRef isn't immediately accessible so a timeout is required to query it and find/set the option you'd like to focus on.

I'm believer that this library is not meant to be everything for everyone, but rather anything for anyone, so while I don't think the proposal fits as a feature request, I could try to assist with such an implementation for your own use-case if you create a sandbox.

As described here, with simple examples: https://github.com/testing-library/dom-testing-library/issues/714

Per the referenced spec, label does not associate with "div" by id, unless "aria-label" or "aria-labelled-by" are supplied.

I propose that when aria-label is not supplied by the caller, that it default to the same as id, so that the label and "pseudo input" div from react-select are associated as required by the spec.

Greetings @amandapouget and apologies for the long delay in getting a response.

I responded to the thread included in the link above, but for context, it would appear that a label was being created with the intention of being applied to the Select.

However, react-select does not generate any labels so this is a specific user implementation.

When creating a label to be used for the Select, it's imperative to use the correct id for the for attribute and in this case, the inputId of the Select should be used instead of the id.

Hopefully this clears up the confusion and resolves any issues regarding HTML validation. I will close this issue now, but feel free to reply if this doesn't resolve your use case and we can continue the discussion or re-open this if necessary.

• [ ] Add Accessibility section
• [ ] Add examples for debounce with async