profile
viewpoint

JedWatson/react-select 21711

The Select Component for React.js

LightSys/kardia_android_crm 5

A Kardia CRM app for Android

davidboy/rc-tree 0

React Tree

Methuselah96/advent-of-code-js 0

JavaScript solutions to challenges from Advent of Code 2018

Methuselah96/babel-plugin-react-css-modules 0

Transforms styleName to className using compile time CSS module resolution.

Methuselah96/base16-js 0

Base16 themes in JS

Methuselah96/console-expect 0

Wraps the console so you can test it better

pull request commentJedWatson/react-select

Upgrades Emotion to v11

@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.

majgaard

comment created time in 2 hours

issue commentJedWatson/react-select

React Select v2.4.4 is unstyled and displaying aria message text

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.

NikhilAnand95

comment created time in 4 hours

issue closedJedWatson/react-select

Better positioning system

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.

closed time in 10 hours

FezVrasta

issue commentJedWatson/react-select

Better positioning system

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.

FezVrasta

comment created time in 10 hours

issue closedJedWatson/react-select

Critical accessibility issues: aria roles and aria-label

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. Form elements must have labels

Certain ARIA roles must be contained by particular parents

closed time in 11 hours

geoffrich

issue commentJedWatson/react-select

Critical accessibility issues: aria roles and aria-label

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 Screen Shot 2021-01-18 at 11 48 43 AM

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.

geoffrich

comment created time in 11 hours

issue commentJedWatson/react-select

isMenuOpen is broken when menuPortal is set

Confirming that this is still broken in 2.4.4 and 3.2

younes0

comment created time in 11 hours

issue commentJedWatson/react-select

isSearchable + starts with functionality

Thanks

ariel-zap

comment created time in 12 hours

issue commentJedWatson/react-select

Warnings: componentWillReceiveProps in strict mode, Legacy context API, findDOMNode is deprecated

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

bladey

comment created time in 13 hours

issue commentJedWatson/react-select

Redundant option highlight when opening the menu

 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!

omriavigdor

comment created time in 15 hours

issue commentJedWatson/react-select

word wrap instead of ellipses

@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?

paigeflourin

comment created time in 18 hours

issue openedreduxjs/redux

TypeScript Redux CodeSandbox 404

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

created time in 20 hours

issue commentJedWatson/react-select

Screen reader read's selected value as 'blank'

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.

ericj17

comment created time in a day

issue commentJedWatson/react-select

Dark theme for documentation

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

Applied this to the body and it's certainly a start. Screen Shot 2021-01-17 at 7 17 31 PM

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

vitaly-zdanevich

comment created time in a day

issue commentJedWatson/react-select

[BUG] "Grouped" options breaks screen readers

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?

Screen Reader + Browser SR behavior
JAWS 17 + IE 11 SR announces the option value along with label name.Ex: Apple (Fruits), Banana(Fruits)
NVDA 2015 + FF 47 SR does not announce the label when options are not expanded. But when user hits space key, the options list expands and SR announces as Fruits grouping – Apple 1 of 3 – Level 2 for each of the options.
Voiceover iOS9 + Safari Screen reader appends the word ‘heading’ for labels (Fruits, Juices…)Ex: Fruits Heading, Apple, Banana
Talkback V6.0 + FF Screen reader appends the word ‘disabled’ for labels (Fruits, Juices…)Ex: Fruits disabled, Apple, Banana.

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.

carsonpowers

comment created time in a day

issue closedJedWatson/react-select

`useState` does not update inmediately with select

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!

closed time in a day

gino

issue commentJedWatson/react-select

`useState` does not update inmediately with select

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.

gino

comment created time in a day

issue commentaspnet/Announcements

Changes to Nullable Reference Type Annotations in .NET 6.0

- 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?>!
pranavkm

comment created time in a day

issue commentJedWatson/react-select

`useState` does not update inmediately with select

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

comment created time in a day

issue commentJedWatson/react-select

`useState` does not update inmediately with select

@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.

gino

comment created time in a day

issue commentJedWatson/react-select

[BUG] "Grouped" options breaks screen readers

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.

carsonpowers

comment created time in a day

issue openedJedWatson/react-select

`useState` does not update inmediately with select

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!

created time in a day

issue commentAzure/app-service-announcements

Platform upgrade for Azure Functions v2 apps coming in October 2020

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

anthonychu

comment created time in a day

issue closedJedWatson/react-select

Typescript runtime error with 3.1.0 "TypeError: newProps is undefined"

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.

closed time in a day

varzaman

issue commentJedWatson/react-select

Typescript runtime error with 3.1.0 "TypeError: newProps is undefined"

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.

varzaman

comment created time in a day

issue commentJedWatson/react-select

[BUG] "Grouped" options breaks screen readers

@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.

carsonpowers

comment created time in a day

issue commentJedWatson/react-select

Keep selected option index after selecting value in multiselect

@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.

5ebastianMeier

comment created time in 2 days

issue closedJedWatson/react-select

React-Select should automatically supply aria-label default same as id

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.

closed time in 2 days

amandapouget

issue commentJedWatson/react-select

React-Select should automatically supply aria-label default same as id

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.

amandapouget

comment created time in 2 days

issue commentJedWatson/react-select

Improve documentation

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

comment created time in 2 days

more