A PRACTICAL GUIDE

Build a connected workspace.

Combine the libraries without duplicating state.

One model, not several copies

Compose independent components through application-owned models. Dockyard provides the workspace; RibbonWeb routes commands; your editor or grid owns its document model. ReactiveWeb can coordinate UI state, while DynamicDataWeb projects changing collections into views.

The diagram on the home page is a suggested composition. It is not a claim that every package has a mandatory dependency on the others.

Define ownership first

Give the application a single owner for each document and collection. Views borrow models. Selection and command state are coordinated deliberately, rather than being synchronized through independent copies of every field.

Integration pattern
// A retained host is ordinary DOM content.
const content = document.createElement('div');
content.style.cssText = 'height:100%;min-height:0';

const documentPane = new LayoutDocument({
  ContentId: 'diagram-editor',
  Title: 'Diagram',
  Content: content
});

// After the host is attached and measurable:
const drawing = new DrawingControl(content, { engine });
// On final teardown: drawing.dispose(); engine.dispose();

Coordinate edits through the engine

Route an undo button to the document engine’s history, not a separate UI history. Use DrawingWeb’s explicit data-binding APIs where two-way shape/record updates are needed. For a collection view, subscribe to a change-set pipeline and dispose it with that view.

Keep adapter boundaries small

Use stable IDs for persisted docking content. Do not assume an object from one package is accepted by another merely because its property names look familiar. Test adapters for selection, ownership and teardown.


Component APIs and compatibility boundaries are documented in their upstream repositories. Each component page links to its own source and guide.

Put it into practice
↑ ↓ to explore · Enter to openEsc to close