Problem: the hexagonal refactor churns the backend tree for nine more phases; the UI delivery stack (web/ SPA, cmd/desktop Wails wrapper, compose/web image) must move to its own repo first so doc/layout rewrites land once on a backend-only tree. Change: - New repo git.hubris.network/dtoro/oikos-web (v0.33.0): web/, desktop/ (updateURL repointed to oikos-web releases), compose/, own CI (web + desktop jobs), own deploy script (CI-green gate, TOCTOU guard, version-tagged images, prune-to-3), own webhook receiver on :9798 + launchd unit, own compose project publishing the same 8091:80. - Cutover executed on mac-mini in order: oikos stack's web service stopped+removed, oikos-web project brought up on 8091; outer Caddy untouched (targets the published port) — serving + Authentik flow + /wails 404 quirk verified post-cutover. - Stripped from oikos: web/, cmd/desktop/, compose/web/, desktop CI workflow, ci.yml web job, Makefile ui/desktop/desktop-package/install targets, the compose web service, oikos-web from deploy.sh's fallback prune list; wails + go-keyring dropped from go.mod, vendor synced. - README / CONTRIBUTING / AGENTS.md / .agents dev+operations docs now point at the new repo; mbse + mascot design docs carry a path note. Risk: production SPA serving depends on the new pipeline now; rollback is versioned-image re-up of the old web service from a pre-split checkout (port 8091). Desktop builds installed before the split still check dtoro/oikos releases — one manual reinstall, noted in the oikos-web release notes. Verification: go vet, make test (race), make generate-check, golangci (no new findings; baseline down 400→365); post-cutover curls — localhost:8091 200, /wails/runtime.js 404, outer Caddy 302 Authentik.
5.2 KiB
d3-dispatch
Dispatching is a convenient mechanism for separating concerns with loosely-coupled code: register named callbacks and then call them with arbitrary arguments. A variety of D3 components, such as d3-drag, use this mechanism to emit events to listeners. Think of this like Node’s EventEmitter, except every listener has a well-defined name so it’s easy to remove or replace them.
For example, to create a dispatch for start and end events:
const dispatch = d3.dispatch("start", "end");
You can then register callbacks for these events using dispatch.on:
dispatch.on("start", callback1);
dispatch.on("start.foo", callback2);
dispatch.on("end", callback3);
Then, you can invoke all the start callbacks using dispatch.call or dispatch.apply:
dispatch.call("start");
Like function.call, you may also specify the this context and any arguments:
dispatch.call("start", {about: "I am a context object"}, "I am an argument");
Want a more involved example? See how to use d3-dispatch for coordinated views.
Installing
If you use npm, npm install d3-dispatch. You can also download the latest release on GitHub. For vanilla HTML in modern browsers, import d3-dispatch from Skypack:
<script type="module">
import {dispatch} from "https://cdn.skypack.dev/d3-dispatch@3";
const d = dispatch("start", "end");
</script>
For legacy environments, you can load d3-dispatch’s UMD bundle from an npm-based CDN such as jsDelivr; a d3 global is exported:
<script src="https://cdn.jsdelivr.net/npm/d3-dispatch@3"></script>
<script>
const d = d3.dispatch("start", "end");
</script>
Try d3-dispatch in your browser.
API Reference
# d3.dispatch(types…) · Source
Creates a new dispatch for the specified event types. Each type is a string, such as "start" or "end".
# dispatch.on(typenames[, callback]) · Source
Adds, removes or gets the callback for the specified typenames. If a callback function is specified, it is registered for the specified (fully-qualified) typenames. If a callback was already registered for the given typenames, the existing callback is removed before the new callback is added.
The specified typenames is a string, such as start or end.foo. The type may be optionally followed by a period (.) and a name; the optional name allows multiple callbacks to be registered to receive events of the same type, such as start.foo and start.bar. To specify multiple typenames, separate typenames with spaces, such as start end or start.foo start.bar.
To remove all callbacks for a given name foo, say dispatch.on(".foo", null).
If callback is not specified, returns the current callback for the specified typenames, if any. If multiple typenames are specified, the first matching callback is returned.
Returns a copy of this dispatch object. Changes to this dispatch do not affect the returned copy and vice versa.
# dispatch.call(type[, that[, arguments…]]) · Source
Like function.call, invokes each registered callback for the specified type, passing the callback the specified arguments, with that as the this context. See dispatch.apply for more information.
# dispatch.apply(type[, that[, arguments]]) · Source
Like function.apply, invokes each registered callback for the specified type, passing the callback the specified arguments, with that as the this context. For example, if you wanted to dispatch your custom callbacks after handling a native click event, while preserving the current this context and arguments, you could say:
selection.on("click", function() {
dispatch.apply("custom", this, arguments);
});
You can pass whatever arguments you want to callbacks; most commonly, you might create an object that represents an event, or pass the current datum (d) and index (i). See function.call and function.apply for further information.