-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
React-select v4.2.1 and beyond... #4293
Comments
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:
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. |
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 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 🤞. |
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. |
Can we please have @Methuselah96 added as a collaborator as well? I think he's done tremendous work in maintaining his fork and Coming from someone who's using |
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 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. 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)...
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 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 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.
Certainly #3781. I'd recommend others, but I guess that depends on if you agree or disagree with the above stance. |
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. Some highlights from the list:
What's missing, what's next:
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. |
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:
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:
At present moment, there are 127 open issues, and 52 open PR's:
What's next?
Thanks everyone for your continued patience. |
Greetings, Version 4.2 has been released.Here is some background on the new additions:
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:
Thanks for all your patience and Version 5 with Typescript is coming soon... |
@ebonow After upgrade to
|
@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. |
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:
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!
The text was updated successfully, but these errors were encountered: