Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entirely controlled component #94

Open
andreyvital opened this issue Sep 13, 2019 · 8 comments
Open

Entirely controlled component #94

andreyvital opened this issue Sep 13, 2019 · 8 comments

Comments

@andreyvital
Copy link

Is there a way to make the <Slider> entirely controlled? So it would only move the handles if I pass values down to the component.

Right now I don't think it is like this since the state is being kept inside <Slider />.

@sghall
Copy link
Owner

sghall commented Sep 13, 2019

Hmmm...good question. I think if you just pass disabled={true} then you can update it manually and all the user interaction is turned off. You control the styles so it doesn't have to look "disabled."

What is the use case for this? Just curious.

You can fork one of the sandboxes and try it out. This is a basic one:
https://codesandbox.io/s/plzyr7lmj

@andreyvital
Copy link
Author

Sorry for the delay @sghall.

Well, say for instance that you want to control certain aspects of a slider's behaviour. For instance, the user drags the handle but then if they don't "release" it, it won't commit the update. Or if they press "Esc" I couldn't restore the value to the one that it was before (the current one in the state).

The issue is that, since the library is managing the state for me I have no control over it. Maybe you could provide a fully-controlled version of <Slider> so no BC's and all you do is pass the state down the tree to the components that need 'em.

Not sure if the example above is the best, but would make more sense to me to reason about how it changes over time if I am controlling it. Thoughts?

@sghall
Copy link
Owner

sghall commented Sep 21, 2019

This is interesting. Seems like when a developer wants a "completely controlled" version of a component they actually want the markup or styles (content) that it renders because there's some value there, but not the state. Otherwise, why use the component at all? What are they getting from the component? (real question, not rhetorical). This library doesn't really render anything. It's just a basic structure for you to plug in some components and some logic and math.

So I'm wondering what this library actually offers you for the use case you are talking about. Do you want the scales to figure out percentages? Seems like that has some value. I don't define any of the content so if you want to make a fully controlled component I'm not sure what that would look like.

You said above:

Maybe you could provide a fully-controlled version of so no BC's and all you do is pass the state down the tree to the components that need 'em.

Sure I could do that, but why? I don't think you need this library to do that. That, if I understand correctly, would be a very simple component. Maybe I could export the scales and some other helpers. I have thought about re-writing this using hooks and just composing the slider as set of custom hooks that get exported. That way you could just make use of some of the scales and calculations without the rest of the components.

Thoughts?

@andreyvital
Copy link
Author

This is interesting. Seems like when a developer wants a "completely controlled" version of a component they actually want the markup or styles (content) that it renders because there's some value there, but not the state. Otherwise, why use the component at all? What are they getting from the component? (real question, not rhetorical). This library doesn't really render anything. It's just a basic structure for you to plug in some components and some logic and math.

Yeah normally that's the case. But look at Downshift state reducer. Downshift comes with certain behaviours that sometimes you want to change / toggle off.

https://github.com/downshift-js/downshift/blob/52b57403e65cd6eadbb00a75a1c3199b8417c000/src/hooks/useSelect/README.md#statereducer

Maybe I could export the scales and some other helpers. I have thought about re-writing this using hooks and just composing the slider as set of custom hooks that get exported. That way you could just make use of some of the scales and calculations without the rest of the components.

Not a bad idea too! You could also export the functions that I'd have to pass to the event handlers (just like Downshift's) so I don't have to worry about what needs to be bound & where.

@sghall
Copy link
Owner

sghall commented Sep 24, 2019

Ahh, interesting. Have not seen this state reducer idea. It would take some work, but that's worth exploring. Thanks for pointing that out.

@palashkaria
Copy link

@sghall I had a use case where we want to add an input box for each handle, with 2 way data binding on the input.
I think having a controlled component would help a lot in such cases!
For making a combination of both types, I think it's also worth looking at jquense/uncontrollable

@burtontanner
Copy link

@andreyvital what did you end up doing? I also need the same functionality you were looking for.

@slutske22
Copy link

I'm finding myself in the same situation - I need to use this as a controlled component. Anyone come up with a solution for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants