Extract option, value and single value to components and allow getting customized ones#328
Extract option, value and single value to components and allow getting customized ones#328jniechcial wants to merge 0 commit intoJedWatson:masterfrom jniechcial:master
Conversation
|
👍 for this one. Sounds like powerful solution. |
|
👍 |
1 similar comment
|
👍 |
|
It looks quite good, it could solve many styling problems. |
|
Be good if you could rebase this on master, and drop the "Build" commit - you only need to submit the src and test changes in a PR, otherwise there's too many conflicts. I've tried rebasing this on my even-more-tests branch, and just one test fails - using a valueRenderer with multi=false, but that could have been my bad rebase, as it was in this area I got a conflict. |
|
Why closed? :( |
|
I am currently rebasing it on other than master branch on my fork as I also got some conflicts and need to take a closer look on this to make sure it works. I will open new PR with rebased your master from my fork. Actually, I did not know that it will close the PR automatically. |
|
Oh, you should just be able to force push to your old branch, and github should just update the PR - then the comments remain. Hey ho! |
|
@bruderstein I forced push to master but GH did not update it - see https://github.com/jniechcial/react-select/tree/master. It's already rebased, no conflicts, tests run and linter checked. |
I recently bumped into case where we needed to make some customization of options and values render. I checked the options that are provided (similar to select2 formatResult) and somehow probably would deal with it this way.
However, I am pretty sure that better solution would be to wrap all these parts that often demands customization (like option/value renders) into components that can be provided via props by the user. Of course, they would need to handle proper API that should be documented.
This way, eventually react-select would become free of tens of customization props (classes, formaters, etc.). All of this could be handled directly by the user providing customized components based on default ones and handle basically every edge customization case.
What do you think? I prepared a fork that meets my requirements and is ready to merge, despite the lack of additional documentation that I can add. There is also an additional example showing how it can be useful with integrating 3rd-party components (in this example its react-gravatar.
I would love to hear your opinion.