React-select v4.2.1 and beyond...

@JedWatson

Greetings everyone,

It's been quite a while since we've had an update so I wanted to talk a bit about how to proceed without spamming subscribers on the previous pinned post.

In full disclosure, I have reached out directly to @JedWatson about a month ago to gauge his interest in having a conversation about the future of the project and identifying ways that I could become a more effective contributor. He replied positively and am still awaiting a date/time we can discuss over Zoom. He likely has hands full with his family and other projects and I am optimistic that we will have a productive discussion when the timing is right for him.

That said, I think what keeps this project alive is the support of the community. Too much has gone into this project to let it die, let alone all the number of existing projects and application that rely on this package. I am also aware that there are still some "open source gardeners" who are actively participating to help quell the creeping tide of "issues" with generally one of two outcomes: 1) Help me fix my code or 2) React-select code/documentation needs update

Number 2 is especially frustrating as the only response available is "Yes it's broken, no ETA on a fix, and even if you fix it, no ETA on a PR". @Methuselah96 has started a fork for this reason, but I think the community is of course hesitant to splinter off onto yet another one of 3.6k forks. I would much rather exhaust all other options.

This leads me to the purpose of this post. A plan forward is better than no plan at all, and I am interested in addressing existing concerns with active community members. The hope is that we can identify a plan forward and to start by having a meaningful conversation about what the future of react-select looks like as a roadmap:

What PR's are still relevant?
What are the bug priorities?
What are the feature priorities?
What features are missing?
What introduces breaking changes?
Missing/broken documentation?
Issue management
What does a regular release cycle look like?

Perhaps @Methuselah96, @Rall3n, @bladey or others would be interested in virtually meeting up to help compile and track what's left to be done or merged. I'm open to whatever communication platform makes sense.

Also curious if anyone else had any ideas for keeping react-select moving forward. Thanks!

@ebonow

Hey @ebonow,

Thanks for reaching out, I agree with all of the above and would like to help put together a plan going forward.

Let's meet up virtually as you suggested - and we'll have that call over Zoom with @JedWatson as well once he's ready.

Interest is definitely there.

Agreed, I am also interested in meeting and helping out in any way I can (apologies if my fork caused any tension, it just seemed like there wasn't very much movement here even after positive conversations like this).

Would you all be interested in a Slack Workspace or a Discord Server where we can talk about steps to maintain the project? We started a Slack Workspace for immutable-js since it's in a similar situation and it has been extremely helpful.

Follow up. I spoke with Thomas and Jed last night on Zoom, and there is momentum as you can see version 3.1.1 was released last night. 🎉

Highlights:

There was a merged PR that caused some type resolution issues that Flow had missed which was holding up taking on other PRs.
The issue was discovered, resolved, passed testing, and released.
I was added as a collaborator to react-select.
An issue template will be added to separate questions/help/feature requests from issues.
Jed began an inquiry to have a discussion section added to address all things that are not issues.
Will be adding more collaborators (hold tight)

The overall message I wanted to convey to everyone is that the plan is to get through as many PR's as possible. This will enable the move from Flow to TypeScript without invalidating the PR's that already exist.

Thank you everyone for your patience and to the existing react-select team. My goal is to at the very least keep the community in communication so that people don't feel like there is radio-silence.

That said, I am curious, if there were any high priority feature/bugs/PR's anyone is waiting on at the moment.

Agreed, I am also interested in meeting and helping out in any way I can (apologies if my fork caused any tension, it just seemed like there wasn't very much movement here even after positive conversations like this).

I understand and appreciate the passion. No one wants to create extra work for themselves, so I recognize it is all in the intention of building tools together so that we can all continue to build and share. I also recognize that you first reached out requesting more contributors so for me the intention is clear that keeping the project alive is what's important.

Communication is difficult on this type of forum because it doesn't really fit as an "issue" which for me inherently makes collaboration feel strained or annoying in threads like these. Filtering out the issues from everything else and creating a space where discussions can happen should help tremendously (which are efforts currently underway). Jed expressed a desire to have the community more involved moving forward in a way that doesn't bloat or break the tools, so these new processes should enable that.

@ebonow

@ebonow This is amazing news, thank you so much for your persistence!

It would be great to have a place where contributors (and anyone else interested) can hop on and message each other so we don't have to clog up these issues unnecessarily. Any thoughts on a Slack/Discord/Gitter?

P.S. Thanks for your understanding, even though I could've handled the situation better.

@ebonow

@ebonow This is amazing news, thank you so much for your persistence!

It would be great to have a place where contributors (and anyone else interested) can hop on and message each other so we don't have to clog up these issues unnecessarily. Any thoughts on a Slack/Discord/Gitter?

P.S. Thanks for your understanding, even though I could've handled the situation better.

All good on my end. Github "Discussions" is a feature currently in beta that some repos already have enabled. Having communication consolidated in Discussions would allow more visibility and would likely solve a lot of problems at once (ie: sections for Help, Show and Tell, Feature Requests, etc...) so fingers crossed 🤞.

@ebonow

Yeah, "Discussions" would be awesome for many reasons. I still think it can still helpful to have instant messaging for certain conversations. I've started a Slack that anyone can join. @ebonow Feel free to hop on, it'd be great to pick your brain on some things without cluttering up everyone's inbox.

@Methuselah96

Can we please have @Methuselah96 added as a collaborator as well? I think he's done tremendous work in maintaining his fork and @types/react-select and is extremely active in responding to Issues and PRs.

Coming from someone who's using react-select in multiple TypeScript projects, I can tell using the library with TypeScript is very much a headache (refer #4308 which will break many pipelines) and could do with a lot of improvement and could use people who're well acquainted with TypeScript.

@Methuselah96

Greetings everyone,

I wanted to share some news with everyone to let everyone know where things are at with ongoing development. @Methuselah96 , @bladey , @JedWatson , and myself have had several meetings with @Rall3n being active in chat an PR reviews/comments.

Preparations are being made to release react-select-v3.2 AND react-select-v4.0.0
The premise is as follows: There are some known bugs and deficiencies that are impacting the current version of react-select. One of the most obvious and visible at the moment are the errors and warnings appearing when using current versions of React.

While we have what seems to be equivalent lifecycles methods in place, replacing class methods with static methods can have negative consequences on performance in different situations. We simply are not sure what those might be without more usage and testing. Therefore, to be overly protective of our users who are using this in production environments, we are erring on the side of caution and moving forward with these changes as a major release.
However, it would also be irresponsible to simply leave users with the risk of updating to a new major version when the existing version has other known deficiencies. Therefore, we will be putting together at least one (and possibly more) minor release to address these.

Back-porting future features will likely happen if it is warranted, but in some cases, it might involve a breaking change or would add extra complexity when time instead could be invested in other milestones we have identified.

What are those milestones? Tentatively we are looking at the following (subject to change)...

v4 - React17 peer dependency support
v5 - Move to TypeScript
v6 - Move to hooks

Version 6 will likely be a sweet spot for most users as we are planning to allow for more composability and flexibility. Expect a smaller package, with better performance, and more powerful subscriber methods to support your custom components or those created from others in the community. Each major version also represents a risk/opportunity to introduce new breaking changes so keep in mind these version numbers could change as new breaking functionality could be deemed necessary.

It should also be noted that we haven't lost sight of other "need to haves" such as required validation and a11y usability (among others as well) and are actively looking for ways that these can be solved for every combination of functionality including single, multi, async, createable and is not searchable. There are other existing issues as well that we're aware of and will continue to support our users as much as possible through these growing pains.

These changes will also likely move us closer to needing new documentation so please be patient with this as well as it's on the way.

I also encourage you all to use the Discussions area for questions, feature requests, sharing cool stuff you built in "show and tell", or offering ideas about how to make react-select easier for developers. This makes it easier for users to identify known bugs and for us all to fix them.

I appreciate everyone's patience. The team has momentum and expect some release notes accompanying shiny new releases coming soon.

We are also looking for feedback from the community on important issues/PRs that have been overlooked. We're doing our best to get through all of them, but it can be easy to miss them with the sheer magnitude of issues/PRs to sort through. So if there's an issue or PR that isn't getting the attention you think it deserves, please let us know. We are currently tracking these through the milestones.

What is the process to get added to the team? I'd love to contribute more often and help to push some of the accessibility stuff through + TS improvements.

@kylemh

@kylemh your contributions are not unnoticed and I know many of us appreciate the help. Staying active with reviews and continuing to help others with issues is a big help. There was a lot of uncertainty about the future of the project and a lot of this recent movement has only begun to happen within the last few weeks, but prior it was about 6-7 months of responding to issues and creating codesandboxes helping people resolve their questions or verifying bugs.

At the moment, I'd say keep being consistent. This is all new and refreshing and there's lots to do for sure especially in regards to accessibility and just the few of us at the moment doing our best to maximize whatever time we can have with Jed. Once we get through the bulk of PR's and get v4 released, I think we'll be able to better identify a plan of action to get more people involved and more things done.

On the topic of accessibility, having combed through past issues, I can tell you that there is a history of providing more support for various aria tags, but apparently there was complexity and issues with uniformity as noted here. It's on my list of things to discuss, but figured it might be a more comprehensive discussion than some of the other questions I have about how things work as I would be interested to know what has been tried prior. I'm also not entirely certain if the extra aria tags add more audible clutter to the aria-live regions.

I personally think in regards to priority with accessibility, #4161 and #3781 are 2 PRs that I'd like to see merged sooner than later since they conform the existing support for the aria-live functionality to better standards while adding localization/custom aria-live messages.

Most of all though, thank you for your support so far.

I'll continue to review. Additionally, please let me know when y'all would like TS work to begin. I'm ready to begin helping with that conversion process.

I personally dislike an option like #4161 because we have the ability to constrain the allowed aria attributes. We certainly don't currently have them all covered, but allowing ANY aria prop isn't correct either.
^ ebonow helped me read this issue correctly

Certainly #3781. I'd recommend others, but I guess that depends on if you agree or disagree with the above stance.

Would also consider #4322 and #4105

@JedWatson

Greetings everyone!

Version 3.2 has been released.

Thank you to @JedWatson , @bladey , and @Methuselah96 for putting in the extra hours to get this long awaited update into the hands of everyone.

While there are release notes, it does not seem like the complete list of all 14 PR updates were generated, so the complete list of merged PR's can be seen here under 3.2 milestones.
I will etch out some time to update the release notes so that there is more visibility into what's been added/fixed.

Some highlights from the list:

Clearing the value from isMulit Select will return the value null to be consistent with current implementation.
- It should be noted that it was discussed that this approach for returning null for multi Select can be confusing and will likely be reverted back to [] in v4.0
Best practices for creating custom Components as well as more thorough descriptions for custom filters were added to the documentation.
Peer dependencies for React 17+ were added
Fix for onCreateOption not always being called
Update aria-live message instructions when tabSelectsValue is true
Pass down extra props to group header as item.data
Enforce Prettier in CI

What's missing, what's next:

Standardize innerProps and className props on customizable components Standardize innerProps and className props on customizable components #4342 needs more review
Fixes for aria-live region Fixes for aria-live region #3781 is using enzyme tests which need to be updated
Kashkovsky intl a11y, attempt 2 Kashkovsky intl a11y, attempt 2 #4161 is a step in the proper direction but has several outstanding implementation concerns.
Added isFocused to several components Added isFocused to several components #3448 Jed's opinion is that the semantics regarding the context of these values can be misleading and will be reviewing this further
[ARIA] Add more Accessible Tags in Input and MenuList [ARIA] Add more Accessible Tags in Input and MenuList #4322, this issue involved a lengthy discussion of earlier approaches before aria live messaging was implemented. Two concerns remain for this PR
- Potential conflicts with aria live messaging especially with new updates being made to ensure aria live messaging is working more predictably. Manual testing will be required to ensure these changes are compatible and likely will require a mechanism for a developer to disable aria messaging.
- Custom use cases may fall outside the realm of listbox/combobox which may lead to broken accessibility for the user. It should also be noted that focus handling and activeElement will differ between the aria-roles mentioned above and the react-select menu so this behavior may experience differing results in different screen readers.
- NOTE: It should be noted that until proper time can be devoted to testing with multiple screen readers, the summation of the changes in the PR can be completed today with custom components.

const Option = props => { 
  const innerProps = { ...props.innerProps, role: 'option', 'aria-disabled': props.isDisabled };
  return <components.Option {...props} innerProps={innerProps} />
}

const MenuList = props => {
  const innerProps = { ...props.innerProps, id: props.selectProps.menuId, role: 'listbox', 'aria-expanded': true };
  return <components.MenuList {...props} innerProps={innerProps} />
}

const Input = props => {
    // aria-label and aria-labelledby are already spread by the existing props if provided
  const ariaProps = { 
    role: props.selectProps.isSearchable ? 'combobox' : 'listbox',
    'aria-owns': props.selectProps.menuId,
    'aria-autocomplete': 'list',
  };

  return <components.Input  {...props} {...ariaProps} />
}

const ariaSelect = props => <Select menuId="unique_menu_id" components={{ Option, MenuList, Input }} {...props} />

Regarding Version 4.0, we are readying this likely as the next release to fully support React 17 and Emotion 11 (including better NonceProvider support to resolve CSP issues).

One more note is that it sounds like more resources may be dedicated to this project so expect to see more collaborator support in the near future.

Thank you all for your patience and I will continue to keep everyone updated as we know more.

@gwyneplaine

Greetings,

It's been awhile since I addressed everyone in this thread and much has gone on in the last month regarding this project.

First of all, in case you have not noticed, there have been FOUR new releases since the last update. I did do a mini summary here in case anyone was curious what kind of progress has been made in the last year or so.

There was some discussion about whether to continue on the same major version, but it was decided in the name of progress to go ahead and release version 4.0.

Breaking changes:

Emotion has been updated to version 11 and as part of this, the NonceProvider will now require a cacheKey
onChange will now return empty array instead of null when there is no value

That's pretty much the gist of it. The cause for the major bump was mostly to safeguard against any regressions that may have occurred from replacing the deprecated lifecycle methods.

Some other cool features that I can think of from the top of my head:

The action meta for clear now includes removedValues that will return an array containing all of the previously selected values.
innerProps and className should now be available for all components as a prop, which will allow more flexibility in applying attributes to your DOM wrapper.

At present moment, there are 127 open issues, and 52 open PR's:

I will be closing this issue thread, but continuing to communicate to the community regularly from here.
Many feature requests have been moved to the discussions area so if you would like something new, feel free to add there or vote up existing requests.
Most anything marked with Waiting-on-author will be closed in two weeks if there is no response, but can be re-opened if necessary.
Many issues and PR's are still in need of a reply

What's next?

@gwyneplaine is hard at work on a completely new documentation
I have been doing quite a bit of work on addressing accessibility and desperately could use some more eyes (and ears) on my PR #4414. I am limited to VoiceOver testing at the moment so anyone looking to volunteer some time to help with JAWS or NVDA support, please reply back.
I am hoping to get this PR into a next release, but we also have several others with milestones attached.
Version 5 is coming soon to address a move from Flow to TypeScript
We will try to get through a lot of of the bigger PR's as we know this move will cause issues for those who have submitted PR's.
With a new major version comes an opportunity to introduce breaking changes though I suspect it should be fairly tame.
There are a plethora of menu positioning issues at the moment.

Thanks everyone for your continued patience.

Greetings,

Version 4.2 has been released.

Release notes here

Here is some background on the new additions:

Aria Live Configuration #4414 Several accessibility concerns are addressed via the aria-live implementation
- ariaLiveMessages is now an available prop which exposes functions to customize the messages read by screen readers for different events. The primary intention is to provide localization but these messages can be customized to fit other accessibility needs as well.
- aria-live is now an exposed prop to enable developers to set the voice to passive, assertive, or off. The hope is that this will give better control to the accessibility experience as our experience has shown that assertive gives a better experience, but those willing to implement their own accessibility solution using roles and attributes are welcome to do so by setting the aria-live to off (though it should also be stated that exposing selected options or support for is-multiple combobox do not have great support via aria attributes alone).
- Much of the accessibility in general has been pulled from the core Select code and pulled into its own internal component called LiveRegion. There is still some level of testing, standardization, and refinement before making it a public component but it is the ambition that we can provide better customization of how these messages are formed and conveyed to assistive technology.
- Aria-Live regions are rendered on mounting of the component to provide better support for some screenreaders.
- Sean and Matt who will be diving more extensively into the matrix of screenreaders to better understand where items are failing.
- There is a list of other touch points regarding where there is still work to be done as well as some other discoveries documented in this PR.
Use accessor props to get value and label in compareOption #4444 When creating a new option with CreatableSelect, options were not properly verifying if the existing value or label already exists using the accessor prop functions (getOptionLabel and getOptionValue). This PR resolves this so that Options with derived labels and values are properly evaluated.
Pass and sanitize commonProps passed to GroupHeader and Input #4391 Resolves two issues:
- GroupHeading no longer renders a data=[Object object] attribute in the DOM element
- Select now properly passes its props into the Styles api
Declare event listeners as non-passive to remove browser warnings #4437 Resolves an issue of Chrome throwing console warnings regarding "passive event listeners". Since the design of the scroll handlers is to block scrolling, they are now set to be explicitly { passive: false }. Note, there is also a polyfill in place to support IE11.
Memoize strip diacritics for input #3827 Memoize stripDiacritics in createFilter for the input with memoize-one so that stripDiacritics is not called for the same string as many times as there are options every time the input changes
Remove browser alias fields #4423 Removed browser alias output from build since the relevant checks for it were being obfuscated anyway
tabIndex as number type #4443 Updated tabIndex prop type to accept Number type as well

What's next?

Typescript - This will mark a substantial refactor but given the number of existing Flow issues, version incompatibilities, and overall popularity, the move to TypeScript should be a welcome move for many.

We will likely try to keep the breaking changes to a minimum to encourage a safe upgrade path to this new major version.

Other things currently being looked at:

AutoSizeInput replacement
Validation
More accessibility specifically in regards to announcing selected values when focusing on the Select, Grouped options support, better counting of indexed options, and possibly multiple aria-live regions.
Menu positioning

Thanks for all your patience and Version 5 with Typescript is coming soon...

@ebonow

@ebonow After upgrade to 4.2.0 the Next.js app build error:

Build error occurred
ReferenceError: document is not defined
at Object. (node_modules/react-select/dist/index-f17570e5.cjs.prod.js:188:1)

@nghiepit Thanks for reporting the issue, check #4476 for updates.

Just a follow up here that Version 4.2.1 was released to patch the issue affecting SSR.

Navigation Menu

Repository navigation

React-select v4.2.1 and beyond... #4293

Version 3.2 has been released.

Version 4.2 has been released.

What's next?

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

React-select v4.2.1 and beyond... #4293

Description

Activity

bladey commented on Nov 23, 2020

Rall3n commented on Nov 23, 2020

Methuselah96 commented on Nov 23, 2020

Methuselah96 commented on Nov 23, 2020

ebonow commented on Nov 23, 2020

ebonow commented on Nov 23, 2020

Methuselah96 commented on Nov 23, 2020

ebonow commented on Nov 23, 2020

Methuselah96 commented on Nov 23, 2020

cseas commented on Dec 2, 2020

ebonow commented on Dec 12, 2020

Methuselah96 commented on Dec 12, 2020

kylemh commented on Dec 14, 2020

ebonow commented on Dec 15, 2020

kylemh commented on Dec 15, 2020

kylemh commented on Dec 15, 2020

ebonow commented on Jan 13, 2021

Version 3.2 has been released.

ebonow commented on Feb 10, 2021

ebonow commented on Mar 5, 2021

Version 4.2 has been released.

What's next?

nghiepdev commented on Mar 5, 2021

Methuselah96 commented on Mar 5, 2021

ebonow commented on Mar 7, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions