-
Notifications
You must be signed in to change notification settings - Fork 476
Proposed Draggable API
The new scrollview implementation poses a question that we have been able to avoid for some time: what is a layer and what is a view. The reason is that when you create a custom scrollview you need at least two layers; one masking layer for the viewport and one with the content that you drag around. Other components like a tableview may consist of many more layers than two.
In terms of naming, iOS uses Layers vs. Views. I think this is confusing because the word views does not imply that it's built out of multiple layers. To make matters worse layers were called views up until Framer 3.
So I propose to use the word Component, as in ScrollComponent, GridComponent, TableComponent etc. I like the word because it implies that you can re-use it, build it yourself, consists of multiple building blocks (layers). It also helps that it seems other interface toolkits like React and Polymer are settling on the same definition.
A Layer is the fundamental drawing unit. A Component is a re-usable set of layers that are configured for a specific task.
On a somewhat higher level there is always the question with Framer how much inner workings you expose when people need to get things done. There is an obvious advantage to getting users to understand what a scroll component actually is. It will make them better designers, realize that they can build these themselves and make tweaking them really obvious. But if you just need scrolling for a prototype now, then you need to be able to throw in a scroll component and it should just work.
- constraints
<x:n, y:n width:n height:n>(the old maxDragFrame) - horizontal
<bool> - vertical
<bool> - overdrag
<bool> - overdragScale
<number> - momentum
<bool> - momentumOptions
<{friction:n, tolerance:n}> - bounce
<bool> - bounceOptions
<{friction:n, tension:n, tolerance:n}> - velocity
<x:n, y:n>(readonly) - angle
<n>(readonly) - speedX
<number> - speedY
<number> - updatePosition(
<{x:n, y:n}>) (to override the actual setting with whatever) - lockDirection
<bool> - lockDirectionOptions:
<{thresholdX:n, thresholdY:n}>
- DragStart
(event, layer) - DragWillMove
(event, layer, {x:n, y:n}) - DragDidMove
(event, layer, {x:n, y:n}) - DragMove
(event, layer)(same as DragDidMove for compat) - DragEnd
(event, layer) - DidStartDecelerating
(event, layer) - DidEndDecelerating
(event, layer) - DidStartBounce
(event, layer) - DidEndBounce
(event, layer) - DidStartDirectionalLock
(event, layer, {x:bool, y:bool})
- content
<Layer> - contentOffset
<{x:n, y:n}> - contentSize
<{width:n, height:n}> - contentInset
<{top:n, right:n, bottom:n, left:n}> - scrollFrame
<{x:n, y:n, width:n, height:n}> - scrollHorizontal
<bool> - scrollVertical
<bool> - speedX
<number> - speedY
<number> - delaysContentTouches
<bool> - loadPreset(
<"ios"|"android">) - scrollFrameForContentLayer(
<x:n, y:n>)<{x:n, y:n, width:n, height:n}> - closestContentLayer(
<x:n, y:n>)<Layer>
- (all of the draggable events)
- ScrollStart -> DragStart
- ScrollWillMove -> DragWillMove
- ScrollDidMove -> DragDidMove
- scroll -> DragMove (html compat)
- ScrollEnd -> DragEnd
- pagingOptions
<{friction:n, tension:n, tolerance:n}> - pageToContentLayer() (to override which layer to page to, by default closestContentLayer)
- pages
[<layer>, <layer>](set an array of layers that you like to use as pages) - pageIndex(
<layer>) - pageToNext()
- pageToPrevious()
- pageTo()
- previousPage
<layer>(readonly) - nextPage
<layer>(readonly) - currentPage
<layer>(readonly)
- PagingDidStart
(event, PagingComponent, contentLayer) - PagingDidEnd
(event, PagingComponent, contentLayer)
- Click and DragStart get messed up. We will handle this with
delaysContentTouches. - [Another case Devin sent me]