React Select v2 and the future

I’ve spent the last few months cleaning up react-select v1 and thinking about the future. Now I’m ready to share some exciting news, and begin discussing plans openly.

The project has grown way beyond my original use-case to become one of the most popular react components: with nearly a million downloads per month, statistically over one in seven people installing react-dom also install react-select 😆

Over the years the API has also grown organically to accommodate a huge amount of flexibility and customisation, and I’ve been reluctant to do much that would break it or invalidate open PRs before they can be reviewed.

On to the news: for the last half-year, with several team members from Thinkmill I’ve been working with Atlassian to develop their new UI library Atlaskit which is being used in Jira, Stride, Confluence, Bitbucket and many other products. We’ve had the opportunity to do a lot of deep thinking on component architecture, and are now turning our attention to Select components… which I am hoping to use react-select as the base for.

With that in mind, I’m embarking on a rewrite of the component using these new ideas and much more modern techniques. I’ve got a working prototype of the new architecture, and from now I’ll be working publicly in a v2 branch. Here’s what you need to know:

• v1.x is stable and will continue to be maintained, at least until v2 is released with feature parity
• The v2 branch is experimental; I’ll update here as it evolves
• v2 will use css-in-js (my current prototype uses glam, this may change) and will continue to be themeable
• v2 won’t include less/scss stylesheets. I’ve got some ideas on how to continue shipping a classNames-based API for everyone who’s already invested in stylesheet customisations… we’ll see
• I’m working on a new concept for customising the component which will consolidate a lot of the current props and make the component more modular, more maintainable while increasing flexibility
• Despite re-writing the architecture, much of the existing code will be brought forward; there is a huge amount of maturity in this project that I’m keen to protect

Some specifics:

• I’m using flow
• Internal state management has been cleaned up significantly - how options are handled and data is passed are both more powerful and more consistent
• You’ll be able to override all the components to completely customise the UI
• Some functions will also be configurable when you want custom behaviour
• Accessibility, performance and flexibility are all first-class concerns

My goal is that many of the requirements people open issues and PRs for will become easily customisable so they don’t require changes to the react-select core. If (if) I get this right, it’ll both make the component more useful and also help me stay on top of things as a maintainer. It also opens the potential for an ecosystem of packages and customisations to start developing on top of react-select, instead of the many forks that currently exist.

[JedWatson]

@frankievx I’m not keen on maintaining two type definitions, at least not yet. If there’s enough demand in the community and someone wants to step up to maintain it, I might be open to it down the track, but right now it would be a burden on our core development and/or get out of date (both of which would be bad)

I know this could be disappointing for typescript users and that’s a shame, I do wish there was an easy way to maintain both… but at this point I’m optimising for maintainability.

[franklixuefei]

@JedWatson @jossmac Will V2 also include typescript definitions?