repository·main·Indexed 43 days ago
https://github.com/deneb-viz/denebA tool for creating declarative visualizations in Power BI using the Vega and Vega-Lite languages. It provides a powerful alternative to native Power BI visuals, featuring a specification editor powered by Monaco, a template catalog, and a specialized rendering lifecycle coordinator to manage Power BI host integration.
The @deneb-viz/editor package provides the advanced Deneb editing interface. It is built on top of @deneb-viz/app-core and includes the following functional areas:
@deneb-viz/json-processing package serves as a centralized utility library for handling JSON and JSONC (JSON with comments) processing within the Deneb ecosystem. It leverages node-jsonc-parser to provide consistent JSON handling across different Deneb components.The Overlay Scrollbars v2 implementation aims to resolve two specific issues: (1) Vega SVG rendering 10px larger than its container on fitted specs, and (2) native scroll containers reserving gutters for scrollbars.
The solution uses a two-layer approach:
autosize: { type: 'fit', contains: 'padding' } into Vega-Lite specs. This ensures the rendered SVG (including padding) fits the container exactly.<div> scroll containers in visual-viewer.tsx and preview-area.tsx with <OverlayScrollbarsComponent> from overlayscrollbars-react. This provides true overlay behavior with zero gutter reservation and allows for user-styled scrollbars via a shared getScrollbarStyleVars helper.The @deneb-viz/eslint-config package provides shared ESLint configurations used across the Deneb monorepo. It includes a base configuration for all packages and a specialized configuration for managing dependency boundaries in application packages.
Available configurations:
base.js: The shared flat configuration that every workspace package should extend.boundaries.js: A configuration used to enforce a layered dependency matrix. It is initialized via createBoundariesConfig({ entry, layers }). This is intended for application packages like app-core and editor. You should pass the specific folder layers that the package contains, and the dependency matrix will be filtered accordingly.Deneb manages the rendering lifecycle (started, finished, error) through a central coordinator. To prevent race conditions between synchronous updates and asynchronous React/Vega painting, Deneb uses a pending-render binding mechanism.
coordinator.bindPendingRender(id) synchronously within the same execution frame as the update() call. This binds the current update identity to the coordinator.onRenderingStarted, onRenderingFinished, or onRenderingError).pendingRenderId at the moment of the call. If a newer update has already superseded the current one (e.g., via a new open(B) call), the late-arriving callbacks from the old update (A) are treated as no-ops.skip, fetch-more, or recover) use coordinator.closeCurrent() to close the current lifecycle immediately.bindPendingRender(id) and rely on the eventual invocation of onRendering* callbacks to signal completion or failure.update() dispatch, the catch block routes to coordinator.failCurrent(e).When consolidateFieldParameters is enabled in the project settings, you can manually treat a regular field as a field parameter. This wraps the field's values in a single-element array and adds a companion __names field to ensure compatibility with specifications designed for field parameters.
This state is managed via the treatAsParameter flag within the SupportFieldFlags type in @deneb-viz/data-core.
export type SupportFieldFlags = {
highlight: boolean;
highlightStatus: boolean;
highlightComparator: boolean;
format: boolean;
formatted: boolean;
treatAsParameter?: boolean;
};In Deneb, when a specification fails to parse or compile, the visual is designed to render blank for report consumers (in reader or view mode). There is no in-canvas error message, overlay, or banner displayed to the end user.
log-viewer.tsx).compilation.result.errors), and the stale view/DOM is cleared during the error process (vega-embed.tsx).The Overlay Scrollbars v2 design addresses two distinct issues: SVG overflow and non-styled scrollbars. It uses a two-layer architecture to separate sizing logic from scrollbar rendering:
Layer 1 (Sizing): Handled by patchVegaLiteResponsiveSizing in @deneb-viz/vega-runtime. This layer ensures that Vega-Lite specs using width: 'container' and height: 'container' actually fit their containers without the 10px overflow caused by default padding. This layer is verified first; if successful, fitted specs will show no scrollbars at all.
Layer 2 (Rendering): Handled in @deneb-viz/app-core via visual-viewer.tsx and preview-area.tsx. This layer manages legitimate overflows using the overlayscrollbars and overlayscrollbars-react libraries. It replaces the native browser scrollbars with styled overlay scrollbars that respect user-configured width and radius settings, providing true overlay behavior with zero gutter reservation.
To prevent the 10px SVG overflow issue (where the chart is container + 2×padding in size), Deneb must inject specific autosize settings instead of zeroing out padding.
When Deneb injects width: 'container' and height: 'container', Vega-Lite defaults to autosize.contains: 'content', which places padding outside the container dimensions. By setting autosize: { type: 'fit', contains: 'padding' }, the total rendered size (including padding) is forced to fit within the container. This approach preserves user-specified padding while ensuring the SVG does not trigger unwanted scrollbars.
// The target configuration to inject:
autosize: { type: 'fit', contains: 'padding' }The packages/app-core package follows a strict, single-direction dependency model based on bulletproof-react layering. This ensures that features are self-contained and the application remains maintainable.
app/ (Composition) $\rightarrow$ features/ (Domain Logic) $\rightarrow$ shared/ (components/ + lib/)
| Layer | May import from | May NOT import from |
|---|---|---|
app/** | features/**, components/**, lib/**, state/**, context/**, i18n/**, catalog/** | — (Top of stack) |
features/X/** | components/**, lib/**, state/**, context/**, i18n/**, catalog/**, sibling files within features/X/** | features/Y/** (any other feature), app/** |
components/** | lib/**, state/**, context/**, i18n/**, catalog/** | features/**, app/** |
lib/** | state/** (read-only via selectors), context/**, i18n/**, catalog/** | features/**, components/**, app/** |
state/**, context/**, i18n/**, catalog/** | each other, sibling files | features/**, components/**, lib/**, app/** |
src/index.ts) re-exports some feature primitives. This is a temporary measure for Power BI compatibility.state/ may import shape types from features, but only via the feature's types.ts file (no UI or runtime code).A general rule for this codebase: When a useMemo, useCallback, or useEffect calls into an externally-stateful service (such as VegaViewServices) rather than computing purely from React props and state, every channel that signals "the external state may now differ" must be included in the dependency array.
In the context of view-bound hooks consuming VegaViewServices, renderId is the canonical signal that the bound view has been replaced.
Rule: renderId is mandatory in the dependency arrays of any hook that reads from the current View. Omitting it is a code smell that leads to stale data during spec re-runs or view replacements.