Update to JedWatson/react-select v1.0.0-rc.1#40
Conversation
This will allow synchronization of component id’s on both the server and the client.
Apply less changes to scss versions
replace `blacklist` dependency by using the spread operator
update npm badge
…er-Side-rendering
Giving Thinkmill credit for being able to commit time to this at work :)
Fix link to Thinkmill
Default reset value to [] when multi=true
…er-Side-rendering
Update Select.js
…endering Added an optional instance id property
Add onCloseResetsInput option w/tests
Index should not be added unless the component is in `multi` mode
- TODO: Select with props onBlur should focus on the input when the menu is active
Replace npmcdn.com with unpkg.com
All but one test passing
Added new Creatable HOC that wraps Select and adds support for creating new options. This HOC provides reasonable default behavior (eg create a new option on ENTER/TAB/comma) but also allows users to override defaults via props. No create-option-specific logic is inside of the base Select component and the logic within Creatable is fully customizable. Added new onInputKeyDown prop to Select (a mirror to onInputChange) that allows users to tap into key-down events and prevent default Select handling. (This is key to how new options are created.) Pulled default filterOptions and menuRenderer props out of Select and into separate modules. I think this lines up with @JedWatson's long-term goals. It was also necessary to enable better sharing between the base Select and the new Creatable HOC.
Implement allowCreate and newOptionCreator in 1.x
This was done as the result of user feedback (see issue #1179). A user requested that we remove the arrow entirely but I felt that made the control look like an <input> instead of a <select>.
Handle touch outside to dismiss menu
|
Woo, nice @TrevorBurnham ! One question:
It's not clear if/where you modified option groups feature to get this working...? Or did it all work together and I misunderstood? Look forward to giving this a test run! |
Sorry, I was a bit unclear. From a functional standpoint, nothing has changed. Option groups will continue to work as they previously did in HubSpot/react-select-plus; option creation will work as it does in JedWatson/react-select; and the two features should work in conjunction (though I should add unit tests to ensure that). What I mean by "tricky" is that there were merge conflicts that I had to resolve in a non-trivial fashion. Much of the same code that was modified to make option groups work in HubSpot/react-select-plus was also modified in order to make option creation work in JedWatson/react-select. In particular, the new upstream code broke one implicit assumption on our end: That the result of So the new approach here is:
Step 3 introduces some inefficiency, which is why I mentioned it in the PR description as an area for future optimization, but I don't think it's bad enough to be a blocker. |
TrevorBurnham
force-pushed
the
update-to-upstream-rc.1
branch
from
ca038c6 to
dc47801
Compare
|
I've redone this branch to fix a bug in my original I've also cherry-picked an upstream patch to fix a bug that was breaking our code that scrolls the menu to the selected option when it opens: JedWatson/react-select#1211 I expect to merge this tomorrow. |
17 participants
This is a huge update, with the long-awaited feature of allowing new options to be created (see JedWatson/react-select#1187). Getting this new feature to work with option groups (the signature feature of react-select-plus) was tricky, but I'm reasonably satisfied with the approach here.
In the future, it would be nice to prevent
unflattenOptionsfrom being called on everyrender, as it's a bit of a perf hit.