zebulonj / apostate Goto Github PK

The goal of this optimization is to ensure that rendering is not triggered more often than once per animation frame, regardless of the timing of signals and action execution.

The current implementation of per-frame processing, which executes on every animation frame regardless of whether there is a state change or pending animations, puts too much load on the processor.

Automatically detect conflicting updates to model data.

There's a need for multiple scheduling queues. Certain user interactions require immediate (at least current thread) execution, while there are other contexts where it would be nice to aggregate or delay updates (e.g., to user the animation frame).

import API from 'api';

engine.inject({ api: API({ url_root: '/api' }) });

In this example, API( ... ) returns a factory function that is used by Apostate to prepare the utility (an API in this example) for use within the engine. The prepared utility is exposed to each action like so:

function fetch( state, params, { api } ) {
  return api.activity.list( params );
}

function load( state, params ) {
  state.set( 'activity', params );
}

Add 'em.

Allow prioritization of signals. Two levels: normal and background. Background signals should only be processed after all pending normal signals are processed. For example, we want user input to be processed immediately, when when tiles are loading asynchronously.

There are some risks of signals being processing in an inappropriate order, if this is not used carefully. Background priority should only be used for signals for which the order of processing does not matter.

Related to #10.

I want to be explicit about how dispatched signals are scheduled for processing. This is particularly important in the context of cascading signals, where a secondary signal is generated from within an action (triggered by a prior signal).

In the case of secondary signals, processing should be queued for after completion of the current and any pending signals.

In the case of primary signals (triggered by user action), I'm less certain but inclined to give the same treatment.

This should (a) allow easier reasoning about the timing of actions and (b) improve performance by breaking up otherwise long running processes.