Events

A set of global events on $bindary, covering the WebSocket connection, data binding and the route lifecycle. Unlike a controller method, which Bindary calls by looking up a specific name, these are ordinary subscribable events, anything can listen, from anywhere.

Subscribing

.add(handler) on the event. .once(handler, args) is also available for a handler that should only run the next time the event fires.

$bindary.onLoad.add(function (args)
{
    console.log('route loaded', args.data);
});

Cancelling

Several of these events carry a cancelToken, { cancel: boolean }. Set cancelToken.cancel = true in your handler to cancel whatever that event's default action is. This is the event-cancellation pattern, distinct from the "return false to cancel" convention used by controller hooks, that's a separate mechanism for a separate system.

$bindary.onPreLoad.add(function (args)
{
    if (someCondition)
        args.cancelToken.cancel = true;
});

Data binding

onPreDataBind fires before a data-bound input updates the underlying value, useful for validation. The handler receives { templateItem, field, dataBind, cancelToken }, field is the input element, dataBind is a function you can call to trigger the bind yourself and cancelToken governs whether the default automatic bind happens.

$bindary.onPreDataBind.add(function (args)
{
    if (args.field.value.length > 100)
        args.cancelToken.cancel = true; // reject: value is not applied
});

onPostDataBind fires after binding is applied, receiving { templateItem, field, model, value }, the data object the value was set on and the value itself.

I'd previously documented these as taking positional arguments, (item, element, apply), based on how core.fireEvent('preDataBind', [item, el, fn]) is called internally in Renderer.js. This typedef says listeners receive a single named object instead. The two aren't necessarily in conflict, fireEvent may wrap the positional internals into this object before dispatching to listeners, but I haven't directly confirmed that wrapping step, only the two ends of it. Worth a quick check before relying on the exact property names above.

Errors

onError fires when a returned data object carries isError: true, with a single error property carrying the details returned by the server.

$bindary.onError.add(function (args)
{
    console.error(args.error.message, args.error.id);
});

Route lifecycle

These mirror the per-route controller hooks covered on Controller, but fire globally regardless of which route is active, useful for app-wide concerns rather than one specific route's own controller.

onPreLoad: { cancelToken }, before a route's data and sources start loading.
onDataRequest: { dataRequest, routeReady, cancelToken }, when the view's data is requested; dataRequest is the requested data identifier, routeReady is a callback to continue loading the route.
onLoad: { data }, after a route's data and sources have loaded, the loaded route data.
onPreDataUpdate: { dataMessage, cancelToken }, when new data arrives, before the client data updates.
onPostDataUpdate: { data }, after the client data has updated.
onPreRender / onPostRender: no arguments, around the view rendering. Not to be confused with the per-element b-pre-render/b-post-render attributes or the route-level controller hooks of the same name, both covered on Controller, this is the third, separate thing sharing that name, the global event and it's the only one of the three that receives nothing.
onPostLoad: { data }, once the route has fully loaded, same shape as onLoad.
onUnload: { routeIndex, routePath, cancelToken, pageHide }, after a route unloads, either because a new route was requested or the page itself is going away, pageHide distinguishes which.

routeIndex/routePath here refer to the route being unloaded, the outgoing one. That's the opposite of the unload controller hook on Controller, whose same-named parameters refer to the requested, incoming route. Same property names, different route, worth keeping straight.