SliderComponent Update

[benjamindenboer]

SliderComponent Update

This update focuses on implementing two new features:

1. A way to define a custom-sized tap/hit area for smaller sliders (so clicking outside — but near still triggers the slider)
2. Allow for bounding the knob to the width of the slider (so instead of the center of the knob defining the min and max values, it's now the left edge and right edge.

---

Set Changes

• Fixed the borderRadius warning by not using percentages to round the knob anymore.
• The values are now also updated from within the setter. So setting the value from another source will also update the fill. (Many thanks, @marckrenn!)
  See a video demo of this here — http://cl.ly/e5bS

---

Changes Up For Discussion

Property: hitArea

• The hitArea property allows you to create larger, easier clickable/tappable sliders. It creates two layers that are always placed on top of both the knob and the slider itself. Previously, I called this property tapSize, but hitArea seems to be preferred. (@koenbok, @jordandobson).
  Here it is visualized: (these layers are transparent by default)

slider = new SliderComponent
    hitArea: 50

• These layers are called knobOverlay and sliderOverlay. I feel like these could be hidden from the Layer Panel. But this would be a first. What do you guys think?

---

Property: bounded

• The bounded property prevents the knob from ever exceeding the width (minX, maxX) of the slider. This is preferred for Desktop/Web sliders. The naming of this property is tricky.

slider = new SliderComponent
    bounded: true

Alternatives by @edwinvanrijkom:

• constrainToTrack (and move the property onto knob)
• constrainKnobToTrack
• centerKnob (true by default)

I'm not a fan of using "track" - since we never use this term in the component iself. In Framer, the track is simply the slider itself. I like constrainToSlider, but it's also quite verbose.

---

Would love your input on these, guys. Wanted to fix the open issues, implement the value emitting and turn it all into a single pull-request so I could provide a single, neat little overview. Let's all continue here.

/cc @koenbok @edwinvanrijkom @marckrenn, @jordandobson

[edwinvanrijkom]

Thanks @benjaminnathan! So it looks like the only remaining thing to do is to decide on the final name of what's currently called "bounded". Some more alternatives:

• knobOverlaps (true by default)
• overlap (true by default)

Or to make things really complicated (but more versatile) we allow to set modes for X and Y anchorage:

• knobAnchorX (center, left, right, constraint) AND
• knobAnchorY (center, top, bottom)

[benjamindenboer]

Instead of the bounded property, me and @edwinvanrijkom propose the following syntax:

slider.knob.constrained = true 

We don't want to the property to become overly verbose (constrainToSlider), yet at the same time it has to be clearer than the term "bounded" currently is. Making it a property on the knob instead helps. The knob is either constrained (to the slider), or not. (Technically it is always constrained, but not within the slider).

Latest commit contains these changes, and has this property implemented.

[jornvandijk]

+1

[jordandobson]

👌🏻
On Fri, Dec 18, 2015 at 6:51 AM Jorn van Dijk [email protected]
wrote:

+1

—
Reply to this email directly or view it on GitHub
#274 (comment).

[koenbok]

LGTM