VizzJson
The @@ convention for turning static JSON into dynamic, parameterized configurations — library-agnostic, CMS-ready, runtime-resolved.
Static configs don't scale.
Every map team hits the same wall: JSON configs that are rigid, duplicated, and impossible to maintain as variations grow.
Static JSON has no feedback loop
Map configs are opaque until rendered. Changing an opacity or a color means editing raw JSON and refreshing — you can't see the effect until the whole cycle completes.
Tunable values are buried in config
Opacity, colors, radii — scattered across deeply nested JSON objects. There's no inventory of what's adjustable, no defined ranges, and no way to surface them as controls.
Designers can't experiment without developers
Trying a different palette or adjusting a radius requires someone comfortable editing raw JSON. Non-technical teammates are locked out of the exploration loop.
No clear boundary between template and state
When everything is hardcoded, there's no way to know what's configurable. With explicit parameters, you know exactly what to persist in a URL, save to a database, or sync across sessions.
One convention, four capabilities.
@@#params.XRuntime parameter injection"raster-opacity": "@@#params.opacity"@@function:Named function dispatch"@@function:setQueryParams"@@type:Class or React component instantiation"@@type": "BasicLegend"@@=[...]Inline expression → function"@@=[case, [">", ...], ...]"A single recursive pass.
Every @@ prefix is resolved in a single pass — no multi-stage builds, no compilation step.
One engine, many visualizations.
Layers
Configure deck.gl layers from JSON with @@type prefixes
Components
Instantiate React components declaratively via @@type
Parameters
Bind live controls to any value with @@#params references
Edit JSON. Tweak params. See it resolve live.