react-input-range icon indicating copy to clipboard operation
react-input-range copied to clipboard

Published 20 hours ago • verified publisher icon davidchin

make more customizable

Open jedwards1211 opened this issue 7 years ago • 7 comments

I wanted to do some more detailed customization than is possible with classNames and formatLabel. This PR allows you to pass in your own Track, Slider, and Label components to InputRange as props. It also exports the default components for those so that you can wrap them if necessary. It also allows you to pass in extra children to InputRange and Slider.

jedwards1211 avatar Sep 30 '16 15:09 jedwards1211

It would be good if there is any functionality for showing a Scale with the slider. So that its easily understandable how much you are dragging each time

chosenvictim avatar Jan 24 '17 11:01 chosenvictim

Hi @davidchin! Wondering if you were planning to merge this PR? Amongst other things, it would also resolve #35 and make it easier to achieve #64 (tooltip issue I just raised).

oyeanuj avatar Mar 07 '17 05:03 oyeanuj

This is exactly what I wanted to do. ~~Another good addition would be to export the default Label, Slider and Track components so the InputRange parent components can use wrappers that manipulate the props in some way, but defer to the default behavior.~~

Nvm, the fork already does this! I rebased it on top of the current master and added the Typescript types, if anyone else needs it: https://github.com/Pathgather/react-input-range/tree/more-customizable

@davidchin, if you're interested, I could add some specs and perhaps we can merge it.

guncha avatar Dec 27 '17 18:12 guncha

@davidchin Thoughts on merging this?

oyeanuj avatar Jan 08 '18 20:01 oyeanuj

Hey @oyeanuj and @jedwards1211, thanks for bringing this to my attention. Sorry I couldn't respond to you earlier as Github notifications tend to get lost in my inbox. Anyway, I think it's a good idea - so you can pass in your own definition of Track, Slider and Label. I suggest we should document the interfaces for these components (i.e.: the required props and callbacks etc...), so that people know exactly what they need to implement. Also, we (as maintainers) need to make sure we don't change them inadvertently as they will become a part of the public interface of this library.

davidchin avatar Jan 13 '18 22:01 davidchin

@jedwards1211 @guncha Can your forks be merged (or do they need to be updated) since @davidchin is in favor of this idea?

oyeanuj avatar Mar 06 '18 18:03 oyeanuj

@oyeanuj I'll just bring up my branch with master and open a new PR with some extra documentation.

guncha avatar Mar 06 '18 23:03 guncha