@thatopen/services 0.0.2 → 0.0.3

package/docs/ui-components/sections-layout.md

@@ -1,123 +1,123 @@
-# Panel Section Layout
-
-## Composition mental model
-
-A panel section has zones that follow a natural sequence reflecting how the user processes the panel: first they act on the context (controls), then understand the current state (messages), then operate on the selected item (toolbar), then see the data (main content), and finally execute high-impact actions (bottom).
-
-```
-<bim-panel-section label="..." icon="..." fixed?>
-  [controls bar]      ← search or selector + action buttons
-  [status messages]   ← conditional bim-labels (warn, success, info)
-  [actions toolbar]   ← bim-toolbar when there are many actions on the active item
-  [main content]      ← table, list, or sub-component
-  [primary actions]   ← 1-2 high-impact buttons at the bottom
-</bim-panel-section>
-```
-
-Not all zones are always present. This sequence is a guide, not a mandatory template — if the panel's content breaks that flow in a way that improves the experience, propose the layout that makes the most sense and explain the reasoning.
-
-### Forbidden nesting
-
-Inside a `<bim-panel-section>` it is **never** valid to place:
-
-- Another `<bim-panel-section>`
-- A `<bim-panel>`
-
-This mistake is most tempting when the user asks to "group" sections. The correct answer is **not** nesting — it is creating independent templates. A template does not decide how it is grouped with others; that is the consumer's responsibility. If the content truly belongs in one section, use the existing internal zones (`controls bar`, `toolbar`, `main content`). If it needs to be split into multiple sections, each section is its own independent template.
-
----
-
-## Controls bar
-
-Always a `<div style="display: flex; gap: 0.5rem;">`. There are two main variants:
-
-**Search** — when the user filters over a list or table:
-```ts
-return BUI.html`
-  <bim-panel-section label="Elements">
-    <div style="display: flex; gap: 0.5rem;">
-      <bim-text-input @input=${onSearch} vertical placeholder="Search..."></bim-text-input>
-      <bim-button icon=${icons.ADD} @click=${onCreate}></bim-button>
-    </div>
-    ${table}
-  </bim-panel-section>
-`
-```
-
-**Selector** — when the user picks the active item from a dropdown. The gap is tighter (`0.25rem`) because the dropdown already takes most of the width:
-```ts
-return BUI.html`
-  <bim-panel-section label="Proposals">
-    <div style="display: flex; gap: 0.25rem;">
-      ${proposalsDropdown}
-      <bim-button icon=${icons.ADD} @click=${onCreate}></bim-button>
-    </div>
-    ${content}
-  </bim-panel-section>
-`
-```
-
-Action buttons in the controls bar are always icon-only (`icon=` without `label=`). The search `<bim-text-input>` always has `vertical` and `debounce="200"`.
-
----
-
-## Status messages
-
-Conditional `<bim-label>` elements that appear between the controls and the content to communicate the state of the active item — warnings, confirmations, relevant info. Built as optional variables:
-
-```ts
-let statusMessage: BUI.TemplateResult | undefined
-if (item?.status === "sent") {
-  statusMessage = BUI.html`<bim-label>This item has been sent and can't be modified.</bim-label>`
-}
-
-return BUI.html`
-  <bim-panel-section label="...">
-    ${controls}
-    ${statusMessage}
-    ${content}
-  </bim-panel-section>
-`
-```
-
----
-
-## Actions toolbar
-
-When there are many actions on the active item (more than 3-4 buttons), use `<bim-toolbar>` with `<bim-toolbar-section>` instead of a plain flex div. The toolbar goes after the status messages and before the main content:
-
-```ts
-const toolbar = BUI.html`
-  <bim-toolbar style="border: 1px solid var(--bim-ui_bg-contrast-20);">
-    <bim-toolbar-section>
-      ${addItemBtn}
-      <bim-button style="flex: 0" icon=${icons.SELECT} @click=${onSelect}></bim-button>
-      <bim-button style="flex: 0" icon=${icons.DELETE} @click=${onDelete}></bim-button>
-    </bim-toolbar-section>
-  </bim-toolbar>
-`
-```
-
-Buttons inside the toolbar always have `style="flex: 0"` to prevent them from stretching.
-
----
-
-## Conditional content
-
-When the panel content changes completely based on state (e.g. "select something first" vs. showing data), assign to a variable before the `return`:
-
-```ts
-let content: BUI.TemplateResult
-if (hasSelection) {
-  content = BUI.html`<bim-table ...></bim-table>`
-} else {
-  content = BUI.html`<bim-label>Select an element to see its data.</bim-label>`
-}
-
-return BUI.html`
-  <bim-panel-section label="...">
-    ${controls}
-    ${content}
-  </bim-panel-section>
-`
-```
+# Panel Section Layout
+
+## Composition mental model
+
+A panel section has zones that follow a natural sequence reflecting how the user processes the panel: first they act on the context (controls), then understand the current state (messages), then operate on the selected item (toolbar), then see the data (main content), and finally execute high-impact actions (bottom).
+
+```
+<bim-panel-section label="..." icon="..." fixed?>
+  [controls bar]      ← search or selector + action buttons
+  [status messages]   ← conditional bim-labels (warn, success, info)
+  [actions toolbar]   ← bim-toolbar when there are many actions on the active item
+  [main content]      ← table, list, or sub-component
+  [primary actions]   ← 1-2 high-impact buttons at the bottom
+</bim-panel-section>
+```
+
+Not all zones are always present. This sequence is a guide, not a mandatory template — if the panel's content breaks that flow in a way that improves the experience, propose the layout that makes the most sense and explain the reasoning.
+
+### Forbidden nesting
+
+Inside a `<bim-panel-section>` it is **never** valid to place:
+
+- Another `<bim-panel-section>`
+- A `<bim-panel>`
+
+This mistake is most tempting when the user asks to "group" sections. The correct answer is **not** nesting — it is creating independent templates. A template does not decide how it is grouped with others; that is the consumer's responsibility. If the content truly belongs in one section, use the existing internal zones (`controls bar`, `toolbar`, `main content`). If it needs to be split into multiple sections, each section is its own independent template.
+
+---
+
+## Controls bar
+
+Always a `<div style="display: flex; gap: 0.5rem;">`. There are two main variants:
+
+**Search** — when the user filters over a list or table:
+```ts
+return BUI.html`
+  <bim-panel-section label="Elements">
+    <div style="display: flex; gap: 0.5rem;">
+      <bim-text-input @input=${onSearch} vertical placeholder="Search..."></bim-text-input>
+      <bim-button icon=${icons.ADD} @click=${onCreate}></bim-button>
+    </div>
+    ${table}
+  </bim-panel-section>
+`
+```
+
+**Selector** — when the user picks the active item from a dropdown. The gap is tighter (`0.25rem`) because the dropdown already takes most of the width:
+```ts
+return BUI.html`
+  <bim-panel-section label="Proposals">
+    <div style="display: flex; gap: 0.25rem;">
+      ${proposalsDropdown}
+      <bim-button icon=${icons.ADD} @click=${onCreate}></bim-button>
+    </div>
+    ${content}
+  </bim-panel-section>
+`
+```
+
+Action buttons in the controls bar are always icon-only (`icon=` without `label=`). The search `<bim-text-input>` always has `vertical` and `debounce="200"`.
+
+---
+
+## Status messages
+
+Conditional `<bim-label>` elements that appear between the controls and the content to communicate the state of the active item — warnings, confirmations, relevant info. Built as optional variables:
+
+```ts
+let statusMessage: BUI.TemplateResult | undefined
+if (item?.status === "sent") {
+  statusMessage = BUI.html`<bim-label>This item has been sent and can't be modified.</bim-label>`
+}
+
+return BUI.html`
+  <bim-panel-section label="...">
+    ${controls}
+    ${statusMessage}
+    ${content}
+  </bim-panel-section>
+`
+```
+
+---
+
+## Actions toolbar
+
+When there are many actions on the active item (more than 3-4 buttons), use `<bim-toolbar>` with `<bim-toolbar-section>` instead of a plain flex div. The toolbar goes after the status messages and before the main content:
+
+```ts
+const toolbar = BUI.html`
+  <bim-toolbar style="border: 1px solid var(--bim-ui_bg-contrast-20);">
+    <bim-toolbar-section>
+      ${addItemBtn}
+      <bim-button style="flex: 0" icon=${icons.SELECT} @click=${onSelect}></bim-button>
+      <bim-button style="flex: 0" icon=${icons.DELETE} @click=${onDelete}></bim-button>
+    </bim-toolbar-section>
+  </bim-toolbar>
+`
+```
+
+Buttons inside the toolbar always have `style="flex: 0"` to prevent them from stretching.
+
+---
+
+## Conditional content
+
+When the panel content changes completely based on state (e.g. "select something first" vs. showing data), assign to a variable before the `return`:
+
+```ts
+let content: BUI.TemplateResult
+if (hasSelection) {
+  content = BUI.html`<bim-table ...></bim-table>`
+} else {
+  content = BUI.html`<bim-label>Select an element to see its data.</bim-label>`
+}
+
+return BUI.html`
+  <bim-panel-section label="...">
+    ${controls}
+    ${content}
+  </bim-panel-section>
+`
+```

package/docs/update-grid-elements.md

@@ -1,46 +1,46 @@
-# Update Grid Elements
-
-## When to use
-
-`app.grid.updateComponent` pushes a state update to a specific named grid element. Use it when a BIM component event needs to refresh the state of a template-based section mounted in the grid.
-
-This is different from `uis.custom.get(...).updateInstances()` — that re-renders all instances of a UIManager template regardless of where they're mounted. `updateComponent` targets a **specific grid slot by name**, which makes it the right choice when the element lives in the grid and you want precise, typed control over what state it receives.
-
----
-
-## API
-
-```ts
-app.grid.updateComponent[componentName](updatedState)
-```
-
-- **`componentName`** — the element name as declared in the `App` type (e.g. `"qtosSection"`)
-- **`updatedState`** — partial state; only the provided fields are merged
-
-The call is fully typed: the accepted state shape is inferred from the `{ComponentName}GridElement` type in `app.ts`.
-
----
-
-## Where to call it
-
-In a setup file (`setups/{custom}.ts`), in response to a BIM component event:
-
-```ts
-// setups/qto-manager.ts
-export const qtoManager = (components: OBC.Components) => {
-  const app = getAppManager(components)
-  const qtoManager = components.get(QtoManager)
-
-  qtoManager.onResultsChanged.add((results) => {
-    app.grid.updateComponent["qtosSection"]({ results })
-  })
-}
-```
-
-Never call `updateComponent` from inside a template function — templates receive state passively and should not trigger updates themselves.
-
----
-
-## Type safety
-
-Because `app.grid` is typed via the `App` type in `app.ts`, TypeScript knows which names are valid and what state shape each one accepts. Passing an unknown name or a mismatched state shape produces a type error at the call site.
+# Update Grid Elements
+
+## When to use
+
+`app.grid.updateComponent` pushes a state update to a specific named grid element. Use it when a BIM component event needs to refresh the state of a template-based section mounted in the grid.
+
+This is different from `uis.custom.get(...).updateInstances()` — that re-renders all instances of a UIManager template regardless of where they're mounted. `updateComponent` targets a **specific grid slot by name**, which makes it the right choice when the element lives in the grid and you want precise, typed control over what state it receives.
+
+---
+
+## API
+
+```ts
+app.grid.updateComponent[componentName](updatedState)
+```
+
+- **`componentName`** — the element name as declared in the `App` type (e.g. `"qtosSection"`)
+- **`updatedState`** — partial state; only the provided fields are merged
+
+The call is fully typed: the accepted state shape is inferred from the `{ComponentName}GridElement` type in `app.ts`.
+
+---
+
+## Where to call it
+
+In a setup file (`setups/{custom}.ts`), in response to a BIM component event:
+
+```ts
+// setups/qto-manager.ts
+export const qtoManager = (components: OBC.Components) => {
+  const app = getAppManager(components)
+  const qtoManager = components.get(QtoManager)
+
+  qtoManager.onResultsChanged.add((results) => {
+    app.grid.updateComponent["qtosSection"]({ results })
+  })
+}
+```
+
+Never call `updateComponent` from inside a template function — templates receive state passively and should not trigger updates themselves.
+
+---
+
+## Type safety
+
+Because `app.grid` is typed via the `App` type in `app.ts`, TypeScript knows which names are valid and what state shape each one accepts. Passing an unknown name or a mismatched state shape produces a type error at the call site.

package/docs/using-colors.md

@@ -1,32 +1,32 @@
-# Using Colors
-
-## `globals.ts` shape
-
-```ts
-export const colors = {
-  GREEN: "#00FF00",
-  SOFT_BLUE: "#5B8CFF",
-}
-```
-
-**Colors are always stored as full hex codes, including the `#`.** This is required because some systems (like the highlighter) use the string itself as a style identifier in addition to a color value.
-
-## Rules
-
-- No hardcoded inline colors — not in the highlighter, not in palettes, not in any component. Always imported from `globals.ts`.
-- Before adding a new color, check whether an existing one already works.
-
-## Example: highlighter
-
-```ts
-const highlighter = components.get(OBF.Highlighter)
-if (!highlighter.styles.has(colors.GREEN)) {
-  highlighter.styles.set(colors.GREEN, {
-    color: new THREE.Color(colors.GREEN),
-    renderedFaces: 1,
-    opacity: 1,
-    transparent: false,
-  })
-}
-highlighter.highlightByID(colors.GREEN, modelIdMap)
-```
+# Using Colors
+
+## `globals.ts` shape
+
+```ts
+export const colors = {
+  GREEN: "#00FF00",
+  SOFT_BLUE: "#5B8CFF",
+}
+```
+
+**Colors are always stored as full hex codes, including the `#`.** This is required because some systems (like the highlighter) use the string itself as a style identifier in addition to a color value.
+
+## Rules
+
+- No hardcoded inline colors — not in the highlighter, not in palettes, not in any component. Always imported from `globals.ts`.
+- Before adding a new color, check whether an existing one already works.
+
+## Example: highlighter
+
+```ts
+const highlighter = components.get(OBF.Highlighter)
+if (!highlighter.styles.has(colors.GREEN)) {
+  highlighter.styles.set(colors.GREEN, {
+    color: new THREE.Color(colors.GREEN),
+    renderedFaces: 1,
+    opacity: 1,
+    transparent: false,
+  })
+}
+highlighter.highlightByID(colors.GREEN, modelIdMap)
+```

package/docs/using-icons.md

@@ -1,37 +1,37 @@
-# Using Icons
-
-## Icon registry rules
-
-**All icons in a platform app must be declared in `globals.ts` and accessed through `AppManager`.** This is not optional.
-
-The flow is always:
-1. Declare the icon in `globals.ts` with a `UPPER_SNAKE_CASE` key
-2. `app.ts` — the `App` type's `icons` field is typed as `(keyof typeof icons)[]`, which means any new key added to the registry is automatically reflected in the type — no manual update needed per icon, but this field must be present in the `App` type
-3. Pass the registry to `app.init()` as `icons: appIcons`
-4. Access icons elsewhere via `app.icons.KEY_NAME` (always through `getAppManager(components)`)
-
-```ts
-// ✗ Forbidden — inline icon string anywhere in the app
-<bim-button icon="ic:round-warning"></bim-button>
-grid.layouts = { Viewer: { icon: "ic:round-warning", template: `...` } }
-
-// ✓ Correct — always via the registry
-const app = getAppManager(components)
-<bim-button icon=${app.icons.WARNING}></bim-button>
-grid.layouts = { Viewer: { icon: app.icons.WARNING, template: `...` } }
-```
-
-## Before adding a new icon
-
-Before declaring a new icon in `globals.ts`, check if an existing one in the registry already serves the purpose. Reuse an existing icon when it communicates the same intent — avoid registry bloat.
-
-If no existing icon fits, add it to `globals.ts` first — then use it through `app.icons`.
-
-## `globals.ts` shape
-
-```ts
-export const icons = {
-  WARNING: "ic:round-warning",
-  COLLISION: "fa7-solid:explosion",
-}
-```
+# Using Icons
+
+## Icon registry rules
+
+**All icons in a platform app must be declared in `globals.ts` and accessed through `AppManager`.** This is not optional.
+
+The flow is always:
+1. Declare the icon in `globals.ts` with a `UPPER_SNAKE_CASE` key
+2. `app.ts` — the `App` type's `icons` field is typed as `(keyof typeof icons)[]`, which means any new key added to the registry is automatically reflected in the type — no manual update needed per icon, but this field must be present in the `App` type
+3. Pass the registry to `app.init()` as `icons: appIcons`
+4. Access icons elsewhere via `app.icons.KEY_NAME` (always through `getAppManager(components)`)
+
+```ts
+// ✗ Forbidden — inline icon string anywhere in the app
+<bim-button icon="ic:round-warning"></bim-button>
+grid.layouts = { Viewer: { icon: "ic:round-warning", template: `...` } }
+
+// ✓ Correct — always via the registry
+const app = getAppManager(components)
+<bim-button icon=${app.icons.WARNING}></bim-button>
+grid.layouts = { Viewer: { icon: app.icons.WARNING, template: `...` } }
+```
+
+## Before adding a new icon
+
+Before declaring a new icon in `globals.ts`, check if an existing one in the registry already serves the purpose. Reuse an existing icon when it communicates the same intent — avoid registry bloat.
+
+If no existing icon fits, add it to `globals.ts` first — then use it through `app.icons`.
+
+## `globals.ts` shape
+
+```ts
+export const icons = {
+  WARNING: "ic:round-warning",
+  COLLISION: "fa7-solid:explosion",
+}
+```

package/package.json

@@ -15,7 +15,7 @@
     "access": "public"
   },
   "private": false,
-  "version": "0.0.2",
+  "version": "0.0.3",
   "main": "dist/index.cjs.js",
   "module": "dist/index.es.js",
   "types": "dist/index.d.ts",
@@ -37,7 +37,7 @@
     "build:lib": "tsc && vite build",
     "test": "vitest run",
     "test:watch": "vitest",
-    "build:cli": "vite build --config vite.config.cli.mts && node scripts/copy-templates.mjs",
+    "build:cli": "vite build --config vite.config.cli.mts",
     "preview": "vite preview",
     "test:ui": "vite --config test/vite.config.mts",
     "test:cli-build-app": "npm run build:cli && node test/setup-test-app.mjs",

package/src/cli/templates/bim/CONTEXT.md

@@ -44,7 +44,6 @@ Always use `npm run dev` which runs `thatopen serve` under the hood.
 | `@thatopen/components-front` | `OBF` | Front-end BIM components (Highlighter, measurements, etc.) |
 | `@thatopen/fragments` | `FRAGS` | Fragment geometry format |
 | `@thatopen/ui` | `BUI` | UI web components (`<bim-panel>`, `<bim-grid>`, etc.) |
-| `@thatopen/ui-obc` | `CUI` | Pre-built OBC UI tables (used by ModelsPanel) |
 | `three` | `THREE` | 3D rendering engine |
 | `@thatopen/services` | `EngineServicesClient` | Platform API client + built-in components |
 
@@ -99,7 +98,7 @@ const client = PlatformClient.fromPlatformContext();
 
 // Creates OBC.Components, inits BUI, loads built-ins, calls components.init()
 const { components } = await client.setup(
-  { OBC, OBF, BUI, CUI, THREE, FRAGS },
+  { OBC, OBF, BUI, THREE, FRAGS },
   AppManager, ViewportsManager,
 );
 
@@ -125,7 +124,6 @@ await client.initBuiltInComponent(AppManager, components);
 | ViewportsManager | `{ OBC, BUI, THREE, FRAGS }` | — |
 | LoadModelButton | `{ OBC, BUI }` | — |
 | ModelsDropdown | `{ OBC, BUI }` | — |
-| ModelsPanel | `{ OBC, BUI, CUI }` | `@thatopen/ui-obc` |
 | ViewerToolbar | `{ OBC, OBF, BUI, THREE }` | `@thatopen/components-front` |
 | ColorsPalette | `{ OBC, OBF, BUI }` | `@thatopen/components-front` |
 | ClashesList | `{ OBC, OBF, BUI, THREE }` | `@thatopen/components-front` |
@@ -145,7 +143,6 @@ await client.initBuiltInComponent(AppManager, components);
 import * as OBC from "@thatopen/components";
 import * as OBF from "@thatopen/components-front";   // needed for Toolbar, Highlighters, Clashes, etc.
 import * as BUI from "@thatopen/ui";
-import * as CUI from "@thatopen/ui-obc";              // needed for ModelsPanel
 import * as THREE from "three";
 import * as FRAGS from "@thatopen/fragments";
 import * as MARKERJS from "@markerjs/markerjs3";      // needed for ScreenshotAnnotator

package/src/cli/templates/bim/package.json

@@ -14,7 +14,6 @@
     "@thatopen/components-front": "~3.4.0",
     "@thatopen/fragments": "~3.4.0",
     "@thatopen/ui": "~3.4.0",
-    "@thatopen/ui-obc": "~3.4.0",
     "@thatopen/services": "file:../../../..",
     "three": "^0.182.0"
   },

package/src/cli/templates/bim/src/main.ts

@@ -3,7 +3,6 @@ import * as OBC from "@thatopen/components";
 import * as OBF from "@thatopen/components-front";
 import * as FRAGS from "@thatopen/fragments";
 import * as BUI from "@thatopen/ui";
-import * as CUI from "@thatopen/ui-obc";
 import * as MARKERJS from "@markerjs/markerjs3"
 import {
   PlatformClient,
@@ -26,7 +25,7 @@ async function main() {
   // First argument: library globals used by the engine.
   // Subsequent arguments: platform built-in components to initialise.
   const { components } = await client.setup<OBC.Components>(
-    { OBC, OBF, BUI, CUI, THREE, FRAGS, MARKERJS },
+    { OBC, OBF, BUI, THREE, FRAGS, MARKERJS },
     { uuid: ViewportsManager.uuid },
     { uuid: AppManager.uuid },
     { uuid: UIManager.uuid },