Walker.js docs

Custom (create your own)

How to write your own walker.js destination
Creating your own destinations is easy. A valid WebDestination.Function consists of a config object, and the two methods init and push: To customize the destinations config use the generic types CustomConfig and CustomEventConfig.
import { WebDestination } from '@elbwalker/walker.js';
declare global {
interface Window {
xxx?: Function; // global window objects}
export declare namespace DestinationXXX {
interface Function
extends WebDestination.Function<CustomConfig, CustomEventConfig> {}
type Config = WebDestination.Config<CustomConfig, CustomEventConfig>;
interface CustomConfig {
// XXXs custom settings
interface CustomEventConfig {
// Custom destination event mapping properties
import { DestinationXXX } from './types';
declare global {
interface Window {}
export const destinationXXX: DestinationXXX.Function = {
config: {},
init(config) {
if (config.loadScript) addScript();
// Do something initializing
return true;
push(event, config, mapping = {}) {
// Do something magical
function addScript(src = 'https://XXX_DOMAIN/xxx.js') {
const script = document.createElement('script');
script.src = src;
export default destinationXXX;


Set all necessary parameters and handle the states. It's separated to keep control of the destination once it's been added to the walker using destination.config.


push: (
event: IElbwalker.Event,
config: Config<Custom, EventCustom>,
mapping?: EventConfig<EventCustom>,
) => void;
The default interface the walker uses to deliver events to each destination.


This function is optional. It has to return a boolean if initialization has worked out properly. As long as init returns false no events will get pushed but each time an event occurs walker.js tries to init again.
The walker checks the config.init value to see if a destination has been initialized, or not. This way you can add a destination that has already been initialized.
Feel free to take a look at the available utils to standardize usage

Final words

We highly recommend writing a corresponding test. We plan to enhance the Config continuously. To prevent overriding or naming conflicts use the custom object.
Feel free to contribute your destination.