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.

Sign up for GitHub

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

Jump to bottom

Expose DragStart, DragAt and DragEnd Variants #15

Open
decapo01 opened this issue Dec 28, 2020 · 3 comments · May be fixed by #16
Open

Expose DragStart, DragAt and DragEnd Variants #15

decapo01 opened this issue Dec 28, 2020 · 3 comments · May be fixed by #16

Comments

@decapo01
Copy link

I'm building a UI that updates the url when the slider is updated. Currently it's hammering the history API and I'm getting an error in firefox that states Too many calls to Location or History APIs within a short timeframe and the ui freezes. It would be nice to have access to the sub messages (especially DragEnd). All this requires is changing the Msg to Msg(..) in the module exposing statement.

The user would still need to account for the generalized message handling so the example would look something like this

update msg ({ percentageSlider, timeSlider } as model) =
    case msg of
        PercentageSliderMsg m ->
          case m of
            DragEnd _ ->
              -- do whatever you need to do on drag end and return (Model, Cmd)
            _ ->
              let 
                updatedModel = RangeSlider.update m percentageSlider
              in
                ( Model updatedModel timeSlider, Cmd.none )

I'm sure the above can be refactored.

I've already cloned, updated and tested this (manually) and will have a PR soon.
@decapo01 decapo01 linked a pull request Dec 28, 2020 that will close this issue
Open
@stephenreddek
Copy link
Owner

Hi! That's an interesting use case. I think exposing the Msg variants is a bit of an antipattern because then it limits the library's ability to change the internals of how things are handled and allows for the user to accidentally not wire it up right.

One alternative would be to return a "reply" from the update function when the values change. It could look something like update : Msg -> Model -> (Model, Maybe (Float, Float)).

Another option is for you to keep track of the last value in your model and diff it with the values coming from the slider. After every update, you could check the new values on the updatedModel and see if it's different.

How does the second option sound to you? It's something like implementing a throttle based on the value changing.

@decapo01
Copy link
Author

I guess I'm not fully following. How would one know when the drag event had ceased? On the second option, even if you keep track what distinguishes when you need to change the model.

@stephenreddek
Copy link
Owner

Ah! I'm sorry, I forgot how this worked! getValues returns the value mid-drag. I was thinking there was a notion of a value being committed but that is not the case. Without introducing a Process.sleep, I don't know of another way to debounce. Perhaps the "reply" approach will work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Exposed DragStart, DragAt and DragEnd Message Variants decapo01/elm-range-slider
2 participants
@stephenreddek @decapo01