3.x TODO

[gwyneplaine]

Remaining MVP work for 3.x release

• Upgrade to Emotion 10 emotion 9 --> emotion 10 #3321
• Add support for CSP nonces (blocked by the above) @mitchellhamilton @gwyneplaine to discuss
• Normalize Values
• Convert to mono-repo (yarn workspaces) Add yarn workspaces and changesets #3530
• Separate entrypoints for Async, Creatable, AsyncCreatable Entrypoints #3541
• Replace raw rollup build step with preconstruct build step Use preconstruct #3528
• Deprecate UMD builds
• require React 16.8 as a peer dep Misc package.json fixes #3548
• Shepherd Aria Messages PR @gwyneplaine Issue #3352: Aria messages cannot be localized and one of the message… #3358
• Shepherd Async Select Refactor PR @JedWatson async-select-refactor #3372

[gwyneplaine]

@mitchellhamilton @JedWatson circa the separate entrypoints question.
This is my initial thinking around how we might want to organise 3.x
Thoughts appreciated and welcome

// react-select
export default manageState<ElementConfig<typeof SelectBase>>(SelectBase);
export { mergeStyles } from './styles';
export { defaultTheme } from './theme';
export { components } from './components';
export { createFilter } from './filters';

// react-select/base (?)
	// the select that isn't wrapped in the statemanager. 

// react-select/animated 
	// this should point at the .src/animated/index 
	// the main export here would be the makeAnimated fn, but we could also probably export the default animated components here if we really wanted to ¯\_(ツ)_/¯

// react-select/async 
        // this should point at ./src/Async 

// react-select/creatable 
	// this should point at ./src/Creatable 

// react-select/async-creatable
	// this sould point at ./src/AsyncCreatable

[emmatown]

react-select/(createFilter || filter ?)

I would say react-select/filter so it can have filtering things other than a single thing called createFilter

react-select/AsyncCreatable

react-select/AsyncCreatable seems strange since the other components are in lower case. Maybe react-select/async-creatable? Or maybe make all the others pascal case?

[gwyneplaine]

react-select/(createFilter || filter ?)

I would say react-select/filter so it can have filtering things other than a single thing called createFilter

👍

react-select/AsyncCreatable

react-select/AsyncCreatable seems strange since the other components are in lower case. Maybe react-select/async-creatable? Or maybe make all the others pascal case?

Agreed, changed to async-creatable

[emmatown]

I've been thinking about this and I think we need to ask the question: why do we have multiple entrypoints?

I think the main answer is: To allow consumers to use one part of a package without incurring the cost of having to load all parts of the package.

(Am I missing anything with the above?)

So I think in general to answer "Should something be in its own entrypoint?" there are some questions that need to answered

• Is the thing rarely used and large?
• If it's a dependency of something else exposed by the package(the dependent), will someone want to import it without also importing any dependents of this or is it likely that the dependent will be changed so it doesn't depend on the thing in the future?

I think async, creatable, async-creatable and animated all make sense as separate entrypoints since I think there's a high chance they won't be used by most people and they're sizable.

I think base also makes sense as a separate entrypoint since I think people will sometimes want to use the base select without the state stuff on top.

I'm not sure if components and filter make sense as entrypoints since I'm not sure if they will ever be used without also having the base select and I also doubt that the select will stop using the contents of components and filter.

I'm not sure if styles make sense as an entrypoint since defaultTheme will always be used by the base select and I doubt that people will want the defaultTheme and not the base select and mergeStyles, even though I assume it's rarely used, it's really small and should work perfectly with tree shaking anyway so it's not a big deal.

[gwyneplaine]

@mitchellhamilton very salient point, and this all makes sense to me, only one I'm a little ambivalent about is createFilter / diacritics. Uncompressed it's 7kb+ of code (Async being 5kb). That said, given that it's used in 80% of the cases, and that we aren't dynamically importing these at the moment, it's probably fine not to have a separate entry point for for 3.x.

I've updated the post above to reflect this

[emmatown]

That said, given that it's used in 80% of the cases

What are the 20% of cases?

[gwyneplaine]

What are the 20% of cases?

Consumers who want to write their own filter because their logic is not enabled by changing the config passed to createFilter.

Consumers who don't need diacritics. (this is the more likely one tbh and can probably be solved by dynamically importing diacritics)

[emmatown]

Ahhh, so the problem is people loading the filter logic when people don't need it, not people loading the base select when they only need the filter logic.

can probably be solved by dynamically importing diacritics

Doing dynamic imports is an interesting problem. The problem isn't really the dynamic imports themselves, that's pretty simple and would work. The big problem though would be that a search could be asynchronous which could cause testing and potentially other problems.

I think this will be plausible when Suspense is ready everywhere and widelyish used because then a part of React Select's API can be "It might suspend" and people will have to handle that.

Another solution would be having a component that doesn't have a default for filterOption.

[gwyneplaine]

I think this will be plausible when Suspense is ready everywhere and widelyish used because then a part of React Select's API can be "It might suspend" and people will have to handle that.

Yes, I was thinking the same 🎉

Another solution would be having a component that doesn't have a default for filterOption.

Of two minds about this at the moment, as filterOption is called in the Select component.
Does this mean perhaps baseSelect doesn't have a default filterOption?

Option filtration is a significant enough piece of logic that I'm not sure should be detached from the baseSelect. That said making the base Select as light as possible is also not a bad thing 🤔

or does this mean we create an abstraction that encapsulates the menu building operation (the only place where we call filterOption)?

This seems enticing, though right now menu building is a pretty messy process, invoked in several parts of the react lifecycle. Optimizing this (perhaps turning parts of this process into a hook) might uncover opportunities to do the above.

I think what this means for this particular body of work though is that it's probably ok for createFilter to be exported in the main entrypoint

[MattMorrisDev]

Any rough ETA's on a release date? Looking forward to Emotion 10 support!

[gwyneplaine]

@MattMorrisDev looking to release 3.0.0 by the end of the week

[zaventh]

Hi, is nonce support in v3 of react-select now? How can I supply an nonce value to react-select for the dynamic styles?