Important: This documentation covers Yarn 1 (Classic).
For Yarn 2+ docs and migration guide, see yarnpkg.com.

Package detail

westures-core

mvanderkamp87MIT1.3.0

The core engine of Westures, a robust n-pointer multitouch gesture detection library for JavaScript.

multitouch, gesture, libary, tap, pan, pinch, rotate, press, swipe, swivel, track, simultaneous, gestures, touch, mouse, pointer

readme

westures-core

Node.js CI Coverage Status Maintainability

Westures is a robust n-pointer multitouch gesture detection library for JavaScript. This means that each gesture is be capable of working seamlessly as input points are added and removed, with no limit on the number of input points, and with each input point contributing to the gesture. It is also capable of working across a wide range of devices.

This module contains the core functionality of the Westures gesture library for JavaScript. It is intended for use as a lighter-weight module to use if you do not want to use the base gestures included with the standard westures module.

Visit this page for an example of the system in action: Westures Example.

Westures aims to achieve its goals without using any dependencies, yet maintain usability across the main modern browsers. Transpilation may be necessary for this last point to be achieved, as the library is written using many of the newer features of the JavaScript language. A transpiled bundle is provided, but the browser target list is arbitrary and likely includes some bloat. In most cases you will be better off performing bundling, transpilation, and minification yourself.

Westures is a fork of ZingTouch.

Quick Example

// Import the module.
const wes = require('westures-core');

// Declare a region. The default is the window object, but other elements like
// the document body work too.
const region = new wes.Region();

// Define a Gesture subclass
class Follow extends wes.Gesture {
  move(state) {
    return state.centroid; // Reports the {x, y} of the average input position
  }
}

// Locate an element to attach the gesture to.
const element = document.querySelector('#follow');

// Instantiate a Gesture for an element within the region.
const follow = new Follow(element, (data) => {
  // data.x ...
  // data.y ...
});

// Add the gesture to the region.
region.addGesture(follow);

Table of Contents

Features

  • Full simultaneous multi-touch gesture support.
    • Continuous use of pointer input allows seamless flow from gesture to gesture without interruption.
  • Robust, simple to understand, easy to maintain engine.
  • Inertial smoothing capabilities for systems using coarse pointers (e.g. touch surfaces).
  • Ability to enable / disable gestures with keys (e.g. ctrlKey, shiftKey)
    • This allows for easy implementation of single-pointer flows that provide the equivalent behaviour as multi-pointer flows. For example, holding 'CTRL' on a desktop could switch from panning mode to rotating mode.
  • Allows for easy implementation and integration of custom gestures using the four-phase hook structure.

Overview

There are seven classes made available by this module:

Name Description
Gesture Base class for defining westures gestures
Input Track a single pointer through its lifetime
Point2D Store and act on a 2-dimensional point
PointerData Record data pertaining to a single user input event for a single pointer.
Region Listen for user input events and respond appropriately
Smoothable Datatype which provides inertial smoothing capabilities
State Track inputs within a Region

Additionally, two support files are defined:

Name Description
constants Constant values used throughout the engine
utils Helpful utility functions

Basic Usage

Importing the module

const wes = require('westures-core');

Declaring a Region

First, decide what region should listen for events. This could be the interactable element itself, or a larger region (possibly containing many interactable elements). Behaviour may differ slightly based on the approach you take, as a Region will perform locking operations on its interactable elements and their bound gestures so as to limit interference between elements during gestures, and no such locking occurs between Regions.

If you have lots of interactable elements on your page, you may find it convenient to use smaller elements as regions. Test it out in any case, and see what works better for you.

By default, the window object is used.

const region = new wes.Region(document.body);

Defining a Gesture Subclass

In order to use the engine, you'll need to define gestures. This is done by extending the Gesture class provided by this module, and overriding any or all of the four phase hooks ('start', 'move', 'end', and 'cancel') as is appropriate for your gesture.

Defined here is a very simple gesture that simply reports the centroid of the input points. Note that the returned value must be an Object!

// Define a Gesture subclass
class Follow extends wes.Gesture {
  move(state) {
    return state.centroid;
  }
}

Instantiating a Gesture

When you instantiate a gesture, you need to provide a handler as well as an Element. The gesture will only be recognized when the first pointer to interact with the region was inside the given Element. Therefore unless you want to try something fancy the gesture element should probably be contained inside the region element. It could even be the region element.

Now for an example. Suppose you have a div within which you want to detect the Follow gesture we defined above. The div has id 'follow'. We need to find the element first.

const element = document.querySelector('#follow');

And we also need a handler. This function will be called whenever a gesture hook returns non-null data. For Follow, this is just the move phase, but the handler doesn't need to know that. The data returned by the hook will be available inside the handler.

function followLogger(data) {
  console.log(
    'The centroid of the points interacting with #follow is:',
    'x:', data.x,
    'y:', data.y,
  )
}

Now we're ready to combine the element and its handler into a gesture.

const follow = new Follow(element, followLogger);

We're not quite done though, as none of this will actually work until you add the gesture to the region.

Adding a Gesture to a Region

Simple:

region.addGesture(follow);

Now the followLogger function will be called whenever a follow gesture is detected on the #follow element inside the region.

Implementing Custom Gestures

The core technique used by Westures is to process all user inputs and filter them through four key lifecycle phases: start, move, end, and cancel. Gestures are defined by how they respond to these phases. To respond to the phases, a gesture extends the Gesture class provided by this module and overrides the method (a.k.a. "hook") corresponding to the name of the phase.

The hook, when called, will receive the current State object of the region. To maintain responsiveness, the functionality within a hook should be short and as efficient as possible.

For example, a simple way to implement a Tap gesture would be as follows:

const { Gesture } = require('westures-core');

const TIMEOUT = 100;

class Tap extends Gesture {
  constructor() {
    super('tap');
    this.startTime = null;
  }

  start(state) {
    this.startTime = Date.now();
  }

  end(state) {
    if (Date.now() - this.startTime <= TIMEOUT) {
        return state.getInputsInPhase('end')[0].current.point;
    }
    return null;
  }
}

There are problems with this example, and it should probably not be used as an actual Tap gesture, it is merely to illustrate the basic idea.

The default hooks for all Gestures simply return null. Data will only be forwarded to bound handlers when a non-null value is returned by a hook. Returned values should be packed inside an object. For example, instead of just return 42;, a custom hook should do return { value: 42 };

If your Gesture subclass needs to track any kind of complex state, remember that it may be necessary to reset the state in the cancel phase.

For information about what data is accessible via the State object, see the full documentation here. Note that his documentation was generated with jsdoc.

Default Data Passed to Handlers

As you can see from above, it is the gesture which decides when data gets passed to handlers, and for the most part what that data will be. Note though that a few properties will get added to the outgoing data object before the handler is called. Those properties are:

Name Type Value
centroid Point2D The centroid of the input points.
event Event The input event which caused the gesture to be recognized
phase String 'start', 'move', 'end', or 'cancel'
type String The name of the gesture as specified by its designer.
target Element The Element that is associated with the recognized gesture.

If data properties returned by a hook have a name collision with one of these properties, the value from the hook gets precedent and the default is overwritten.

Nomenclature and Origins

In my last year of univerisity, I was working on an API for building multi-device interfaces called "WAMS" (Workspaces Across Multiple Surfaces), which included the goal of supporting multi-device gestures.

After an extensive search I found that none of the available multitouch libraries for JavaScript provided the fidelity I needed, and concluded that I would need to write my own, or at least fork an existing one. ZingTouch proved to the be the most approachable, so I decided it would make a good starting point.

The name "westures" is a mash-up of "WAMS" and "gestures".

Changes

See the changelog for the most recent updates.

Issues

If you find any issues, please let me know!

westures

westures-core

changelog

Changelog

1.3.0

  • Introduce "headless" mode, which allows westures to be run in a server environment.

1.2.0

  • Switch to "parcel" from "parcel-bundler"
  • Add a list of the PHASES to constants.js
  • Provide Input.elapsedTime
  • Provide Point2D.anglesTo()

1.1.0

  • Switch to using pointer events by default, combined with setting touch-action: none on the gesture elements (not the region itself).
  • Provide options on the Region for choosing whether to prefer pointer events over mouse/touch events (preferPointer) and what to set the touch-action property to on gesture elements (touchAction).
  • Default to using the window as the region if no element provided.
  • Add mouseleave to the CANCEL_EVENTS

1.0.0

  • Official first release! This engine is no longer considered to be in beta.
  • Refactor Smoothable to be a data type, not a mixin.
  • Remove the Binding class and integrate with the Gesture class. It was more of a hindrance than a help on its own.
  • Provide automatic detection of enabled and disabled gestures, including using keys to enable and disable, in a simple way such that gestures don't need to check if their enabled inside their hooks.
  • 'cancel' phase is now properly called.
  • Region class now takes an optional 'options' object instead of lots of arguments.
  • Remove the 'getProgressOfGesture' method from the Input class. Gestures should track their progress internally, on their own instance!
  • Remove the 'radius' property from the outgoing data. It didn't seem useful and was just cluttering the output.
  • Use Sets for tracking Gestures inside the Region instead of Arrays. (Faster access operations).

0.6.5

  • Update dev support packages and switch to parcel-bundler for the distributable instead of browserify. This bundle is now found in the dist/ folder, along with a source map. Support for the old 'bundle.js' and 'bundle.min.js' is approximately maintained by providing two copies of 'dist/index.js' under those names. They will be removed in subsequent releases.

0.6.4

  • Remove confusing and unnecessary console.warn() statements.

0.6.3

  • Add a check that ensures smoothing will only ever be applied on devices that need it. That is, devices with 'coarse' pointers.

0.6.2

  • [POSSIBLE BREAKING] But only for those who have implemented their own Smoothable gesture with a non-zero identity value (e.g. Rotate has an identity of 0, as that represents no change, and Pinch has an identity of 1, as that represents no change). Such gestures will now need to declare their own identity value after calling super() in the constructor.
  • The smoothing algorithm used by the Smoothable mixin has been simplified. There is no delay to emits, as analysis of the data revealed this really only occurred for the first emit. Instead a simple rolling average is maintained.

0.6.1

  • Add babelify transform for bundle. (Add's Edge support, or at least it should...)

0.6.0

  • Add centroid and radius to base emitted data.
  • Give preference to gesture's data over base data, in the case of name collisions. (So that a gesture can overwrite parts of that data, for example if a tap gesture wants to write its own centroid).
  • The system now tries to obtain pointer capture on inputs.
  • Add radius to state's convenience fields.

0.5.3

  • Treat 'touchcancel' and 'pointercancel' the same way as 'blur'.
    • This is an unfortunate hack, necessitated by an apparent bug in Chrome, wherein only the first (primary?) pointer will receive a 'cancel' event. The other's are cancelled, but no event is emitted. Their IDs are reused for subsequent pointers, making gesture state recoverable, but this is still not a good situation.
    • The downside is that this workaround means that if any single pointer is cancelled, all of the pointers are treated as cancelled. I don't have enough in depth knowledge to say for sure, but I suspect that this doesn't have to be the case. If I have time soon I'll post a ticket to Chrome, at the very least to find out if this is actually a bug (my read of the spec tells me that it is).
    • The upside is that this should be pretty fail-safe, when combined with the 'blur' listener on the window.

0.5.2

  • Add 'cancel' support for touchcancel and pointercancel.
    • For many gestures, it will be the same as 'end', but in some cases it must be different, specifically gestures that emit on 'end'.
  • Add a 'blur' listener to the window that resets the state when the window loses focus. This should help maintain the viability of the system. I'm trying it out anyway. Let me know if this causes any serious issues.

0.5.0

  • Rename Region#bind() -> Region#addGesture() and Region#unbind() -> Region#removeGestures().
    • I was not happy with the way that the 'bind' naming clashes with the 'bind' function on the Function prototype.
  • Simplified "unbind" function. It now returns null, as the Bindings should not be exposed to the end user.
  • Sped up Binding selection in the Region's arbitrate function, while simultaneously fixing a critical bug!
    • Only the bindings associated with elements on the composed path of the first input to touch the surface will be accessed.
    • In other words, this batch of bindings is cached instead of being recalculated on every input event.
    • Previously, if the user started one input in one bound element, then another input in another bound element, the bindings for both elements would think they have full control, leading to some potentially weird behaviour.
    • If you want this behaviour, you'll now have to simulate it by creating a separate region for each binding.
  • Removed Region#getBindingsByInitialPos
  • Removed State#someInputWasInitiallyInside
  • Improved test coverage a bit