[Proposal] A “expression-binding” api to avoid gesture move js-native bridge cost

[wintercn]

Everyone knows when response to a gesture event like pan, there is three steps:

start ==> move ==> end(cancel)

For "start", "end" and "cancel" event, it's OK to raise the event to JS. But for move event, it's triggering too rapidly and there is not enough time for calling js-native bridge. At this state, it's really hard to implement fancy effect related to gesture with weex

To resolve this issue, I'm thinking of a “expression-binding” system, described as following:

• When gesture start, (js code) create a "expression-binding" between a property and the gesture.
• During the gesture moving process, native code automatically execute the expression with argument from gesture and set it to the binding property.
• When gesture is end or canceled, destroy the binding.

The code might like the following

element.onPanGestureStart = function(event){
    event.createBinding(element, "transform.translate", "{x: x, y: y+10 }")
    event.createBinding(element, "opacity", " (abs(x) + abs(y)) / 100 ")
}

Now, the most necessary gesture is pan and two-finger touching.

Available variables in expression:

pan
    x : the displacement x from original point
    y : the displacement y from original point
    translate:  the translate of the point

two-finger
    x : the displacement x from original point
    y : the displacement y from original point
    translate: the translate of the two points' middle point
    rotate : the rotation from original line(in rad)
    scale : the scaling rate from original line
    transform: the combined transform of the two finger points

Available tool-functions in expression:

    abs
    acos
    asin
    atan
    atan2
    ceil
    cbrt
    cos
    exp
    floor
    log
    max
    min
    pow
    round
    sign
    sin
    sqrt
    tan

Available consts in expression:

    E
    LN10
    LN2
    PI

Available operators in expression:

  ( … )
  ! …
  ~ …
  + …
  - …
  … * …
  … / …
  … % …
  … + …
  … - …
  … << …
  … >> …
  … >>> …
  … < …
  … <= …
  … > …
  … >= …
  … == …
  … != …
  … === …
  … !== …
  … & …
  … ^ …
  … | …
  … && …
  … || …
  … ? … : …

Interface design:

event
    createBinding
        parameters:
             @element : the element to bind to the event
             @propertyPath: the property path of the element
             @expression: the property value expression
             @rangeCheckExpression[opt]: A expression to check if the bind will be execute, returns true of false
        return value
             undefined

[HiZhaoxiaoyang]

I do remember when a pen drawing on a canvas , the basic principle is logging what coordinates the pen reached. here's we need an array to log it, Queue, FIFO. .. tbc

[Hanks10100]

Great! contribution welcome. 😃

[Jinjiang]

It's absolutely useful to do better perf for gesture events model. My concern is whether it's enough for some extreme cases or boundary conditions? For example an element should be stoped when people move it out of the screen by an "expression-binding". It's common and how to finish it with our current design?
Thanks.

[YorkShen]

I think this proposal can solve some problems related to js-native bridge communication.

• Boht js->native and native-> js communication will cause precision lost as <meta name="viewport" content="750, initial-scale=1"> is set by default.

• As sampling problem in pan gesture, there will also be precision lost.

• js->dom->ui and ui->js threads communication may delay the UI response to user's action