Better ScrollView/PageView

[koenbok]

https://github.com/koenbok/Framer/wiki/Contributing:-Wanted-Features#better-scrollviewpageview

[dabbott]

My draft is up at #164 with gratuitous explanation, comments, thoughts

[dabbott]

Feedback regarding the new API at https://github.com/koenbok/Framer/wiki/Proposed-Draggable-API/b4ecaa907725763f70585ff289d696748134868c

Looks fantastic. Some very minor suggestions/questions:

1. Should velocity be {x:n, y:n} instead of just number?
2. Can we make decelerating the same part of speech as bounces? Maybe decelerates. Also, bouncesOptions sounds a little off. It would roll off the tongue better as bounceOptions and decelerationOptions. Though that loses consistency with the bool properties.
3. Is there a use case where updatePosition should and shouldn’t set velocity to 0? If there is, updatePosition(<{x:n, y:n}>, bool:optional).
4. How do I achieve the effect where I can drag past the scrollFrame with resistance? Is that coupled with bounces versus a separate explicit property?
5. I previously had that terrible hack with multipleDraggables for rows within a ScrollComponent… will that use case “just work” with a ScrollComponent? What would the settings of the sublayers that can drag horizontally have to be?

[koenbok]

Great feedback.

1. Yes, I'll change it.
2. I agree. Maybe bounces, bounceOptions, decelerates, decelerationOptions. But meh. Will have to think some more.
3. This one I don't follow :-)
4. I think we should map the bounce and deceleration properties from the ScrollComponent to the draggable.
5. I have to understand this better before I can answer. Ideally it should just work. I think maybe a ScrollComponent can look upward in the layer hierarchy and have special logic for this, while we keep draggable bare bones.

[koenbok]

• decelerate, decelerateOptions, bounce, bounceOptions
• momentum, momentumOptions, bounce, bounceOptions

[tisho]

Miscellaneous Thoughts

On Draggable

container makes me think I should pass in another layer, but it's better than maxDragFrame. Alternatives, not necessarily better:

• boundaries, bounds
• constraints = { top: n, right: n, bottom: n, left: n }
• xRange = [n, n], yRange = [n, n], or rangeX/rangeY to stay consistent with speedX/Y.

Add angle of movement over last 100ms.

directionalLock could also be called snap for short. I'd also prefer lockDirection over directionalLock because it sounds more like a human would say it.

On 3, I think what @dabbott means is that you can call updatePosition in the middle of deceleration and then you have the choice of either zeroing velocity and updating the position (so it will look like the layer stopped moving and just teleported to another position), or just updating the position and letting the velocity influence the final position (so the layer will teleport and then keep drifting). The method signature could be updatePosition(x: number, y: number, preserveVelocity: bool).

On ScrollComponent

I love loadPreset, but it makes me think that I can have my own presets that I can load. Which would be great, but there needs to be an API to create presets. An alternative to this could be a scrollStyle property.

I'm guessing delaysContentTouches would take care of the embedded scrollview/draggable use case?

Add speedX/Y from Draggable to the scrollview.

On PagingComponent

Add next(), previous() and methods to access the index of the current page (currentPageIndex). Would be useful for making paging indicators.

[dabbott]

@koenbok

1. (Markdown makes you put a 1.)
2. So far I like momentum, momentumOptions, bounce, bounceOptions - it's consistent and reminds people that there's physics involved :)
3. tisho eloquently captured what I was trying to say. Building off his comment: if we're assuming velocity of a draggable is readonly, then the developer should never be able to manipulate velocity. Meaning updatePosition should just do the right thing and set velocity to 0 when called, rather than teleporting the view and the view keeps moving. I think it's more consistent to support only this one behavior. That said, I could also imagine a teleporting behavior being fun to play with. Maybe we leave it but don't document it... see if anybody comes up with something cool :P -- On the other hand... do we even need an updatePosition? Shouldn't the developer just set/animate layer.x|y? And we would zero out velocity when these are changed.
4. That makes sense. We could still decouple the concept dragsPastContainerBoundsWithResistance from springsBackToRestingPosition if we wanted to, which right now are captured by bounce. But I prefer the simplicity of bounce encompassing both.
5. Seems reasonable - we can figure that out later on after some of the rest of the implementation is in place.

@tisho

1. For container - I generally pass a Layer to maxDragFrame/maxScrollFrame so I think this captures how it works reasonably well. If we were going to keep the scrolling behavior as part of Draggable, then I would definitely call it bounds or similar.
2. Good point, it will be helpful to expose angle. And we could take it into account when determining directionalLock (since people tend to swipe in arcs which can trigger a false positive)
3. I prefer directionalLock since it's consistent with UIScrollView . snap implies paging to me.
4. next(), previous(), currentPageIndex 👍

I hope to get started on improving Draggable today.

[cleercode]

I should look over this more later, but one note right now:

maxDragFrame right now is a total pain for even something as simple as a long (> screen height) draggable view in which you don't want the top of the view draggable past the top of the screen or the bottom of the view draggable past the bottom of the screen. As far as I can tell, doing this requires some weird math based on the height of the view. tisho's constraints proposal seems better for this use case, at least.

[koenbok]

Ok I updated the proposal with most of the above:

• Settled on constraints (because bounds means frame without location for NSView)
• Added angle
• Settled on momentum
• Settled on bounce
• Made updatePosition like @tisho described
• Settled on lockDirection because it's a tad more descriptive than snap
• Added paging functions that work for vertical and horizontal paging

[koenbok]

I started on this here: https://github.com/koenbok/Framer/tree/scroll-component

My documentation proposal is here: http://goo.gl/lDOqro

[ryngonzalez]

@koenbok This issue is resolved with the latest release, correct?

[koenbok]

Ha, yes indeed!

[koenbok]

That felt good ;-)

[ryngonzalez]

😃