Repository navigation
[WIP] Fix style import issues in aggrid documentation demo - #238
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>
Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>
hotlong
approved these changes
Jan 27, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a CSS loading issue with AG Grid styles in the documentation site's demos. The problem occurs because Next.js doesn't properly process CSS imports from dynamically loaded modules when using client-side dynamic imports.
Changes:
- Added AG Grid CSS imports to the root layout to ensure styles load before the plugin is dynamically loaded
- Added ag-grid-community and ag-grid-react as direct dependencies to the site package
- Added Next.js setup documentation to the plugin-aggrid README to help users avoid this issue
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| apps/site/app/layout.tsx | Added imports for AG Grid base styles and 4 theme CSS files to root layout |
| apps/site/package.json | Added ag-grid-community and ag-grid-react v32.3.9 as direct dependencies; minor reordering of plugin dependencies |
| packages/plugin-aggrid/README.md | Added "Next.js App Router Setup" section with CSS import instructions and explanation |
| pnpm-lock.yaml | Updated lockfile with new dependency resolutions |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
Comment on lines
23
to
+24
| "@object-ui/plugin-gantt": "workspace:*", | ||
| "@object-ui/plugin-grid": "workspace:*", |
There was a problem hiding this comment.
The alphabetical ordering of dependencies has been disrupted. The workspace dependencies should maintain alphabetical order. Currently, @object-ui/plugin-form and @object-ui/plugin-grid appear after @object-ui/plugin-editor but should come before @object-ui/plugin-gantt to maintain alphabetical ordering. Please restore the original alphabetical order of these dependencies.
Suggested change
| "@object-ui/plugin-gantt": "workspace:*", | |
| "@object-ui/plugin-grid": "workspace:*", | |
| "@object-ui/plugin-grid": "workspace:*", | |
| "@object-ui/plugin-gantt": "workspace:*", |
This was referenced Sep 28, 2026
Closed
akarma-synetal
pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Oct 7, 2026
…efuses an undeclared map key (objectui#5157) (objectstack-ai#10997) Fixes objectstack-ai#5157 Clause-②: yes — a published schema's accept set narrows: an undeclared key inside an `object-map` node's `map` block stops validating. Ruling-ref: 5328158731 (B, the `map` block only) and 5871202958 (batch objectstack-ai#238 item 2, letter A, maintainer 「同意」 2026-09-28T13:48Z) **Fix round 1** (`bf4797f85f` and `d5c28d4da2`, following contract review `5873208537`): - the `markdown-test-inputs` ledger entry for the new pin (CI's `Test (shard 1/8)`); - the runtime wording in the plugin-map README and docs page (a `latitudeFieId` typo draws the "Map configuration required" refusal, not a map); - the two docblocks that were stale since objectui#8169; - the changeset's "no diagnostic anywhere", corrected because a TypeScript author's compiler did name the key. No code line moved. Implemented by the `domain:ui` seat 2 dispatch, session `https://claude.ai/code/session_014mXUNuFomfj24w7s1pZzhN`, claim comment 5872032029. ## What changed - `ObjectMapConfigSchema` (`packages/types`, `zod/objectql.zod.ts`) closes with `.strict()`. `ObjectMapSchema.map` is this object, so the declared face, the runtime check `ObjectMap` runs and the validate face now share one accept set. `.shape` is unchanged: the same eight keys, so `ObjectMap`'s `FLAT_MAP_CONFIG_KEYS` (derived from `.shape` minus `style`, seven keys) and the view flatten whitelists (hand-listed, pinned against `.shape`) see the same keys as before. - `packages/plugin-map/src/ObjectMap.tsx` is **not** changed. Its existing `safeParse` of the block now fails on an undeclared key, and the existing `console.warn` names the key. - Docs: the plugin-map README, the plugin-map docs page and the types README now say the `map` block is closed. No sentence anywhere said the block tolerated unknown keys, or that validate accepted them. The types README said the whole rendering face, every named mirror included, is tolerant, so it now names the `map` block as a closed sub-block on that face. - Changeset: `'@object-ui/types': minor`. It states the narrowing and the measured breakage, which is none. - ⛔ No other component sub-block is touched (the ruling's standing condition). ## Pins: red on base, green on head "Base" here means the head tree with `.strict()` ablated. The ablation used `ablation-replace.mjs` (objectstack `origin/main` copy): anchor `}).strict();` went x1 to x0, and the blob went `7ef2545fa19c` to `4d0b11cad207`. The restore was proven by blob == HEAD (`7ef2545fa19c`) and an empty `git diff HEAD`. The pins resolve `@object-ui/types/zod` through the root vitest alias to `packages/types/src/zod/index.zod.ts`, so no `dist/` is involved. | Pin | File | Base | Head | | --- | --- | --- | --- | | (ii) `safeValidateSchema` refuses the typo block: exactly one issue, `unrecognized_keys` at `map`, keys `latitudeFieId` | `object-map-config-strict-5157.test.ts` | ❌ | ✅ | | (ii) `ObjectMapSchema` refuses it at the same path | same | ❌ | ✅ | | (ii) `ObjectMapConfigSchema` refuses it, naming the key at the block root | same | ❌ | ✅ | | (ii) the same node one level down, inside a `div`'s `children`, is refused | same | ❌ | ✅ | | (ii) control: the clean block validates, alone and nested | same | ✅ | ✅ | | `.shape` still declares the same eight keys; every declared key together parses | same | ✅ | ✅ | | (iii) the sweep: 20 blocks, each parsed as a `map` block and validated inside an `object-map` node (40 rows) | same | ✅ | ✅ | | (i) runtime: the typo block (which also binds `locationField`) renders the map and places the marker the declared keys bind | `ObjectMap.strictConfigWarn-5157.test.tsx` | ✅ | ✅ | | (i) runtime: `[ObjectMap] Invalid map configuration` is warned, and its arguments name `latitudeFieId` | same | ❌ | ✅ | | (i) control: a clean block warns nothing about its configuration | same | ✅ | ✅ | Run totals: base `Tests 5 failed / 46 passed (51)`, head `Tests 51 passed (51)`. Exactly the four (ii) refusal rows went red, plus the runtime warn row. That fifth red is expected. At base the typo parses clean, so the warning never fires, and that silence is the card's own symptom. The runtime row that is green on both sides is the render half. The pin's map still draws, with no throw, because its fixture also binds `locationField`. The card's own `latitudeFieId` typo alone leaves no coordinate binding, so it draws the "Map configuration required" refusal (objectui#8169) rather than a map. ## The sweep (iii) I re-derived the population with `git ls-tree` plus a `git grep` for a `map` key. It covers objectui `examples` / `apps` / `content` at `40c076fc2d` and objectstack `examples` / `apps` at `3cf6449389`. I reconciled every hit by hand, and I did not reuse the old report's list. - objectui: 18 blocks. `content/docs/plugins/plugin-map.mdx` has 13 brace-literal blocks plus the `mapConfig` variable in its TypeScript Support section. `content/docs/fields/location.mdx` has 1. The schema-catalog `plugin-map` JSON has 3 (`event-venue-finder`, `real-time-delivery-tracking`, `store-locator-map`). The one other grep hit is a catalog entry keyed `map` (`id` / `meta` / `schema`), which is not a config block. - objectstack: 2 blocks, both `titleField` + `locationField`: the app-showcase `task.view.ts` map list view, and `task-map-marker-title.test.ts`. The other hits are a translations label, the view keyed `map`, and a comment, none of them a config block. - Result: 20 of 20 use declared keys only, so no block is newly refused. The population is held as the `SWEEP` fixture, with each row naming its source by path and a quoted anchor, never a line address. The fixture header says the population is a snapshot. The three catalog entries are also re-read live and validated whole by `ObjectMap.catalogRecordSource-6939.test.tsx`, which is green on head. ## The nested-document measurement Measured with the built CLI (`packages/cli/dist/cli.js`) against built `@object-ui/types`, on fixtures from the seat's scratchpad. For base, I rebuilt `@object-ui/types` with `.strict()` ablated. A dist preflight read the `ObjectMapConfigSchema` closer in `dist/zod/index.zod.js` as `});`, and afterwards I restored and rebuilt, and the closer read `}).strict();` again. `objectui validate`, root typo node: **head** exits 1: ```text 1. Unrecognized key: "latitudeFieId" Path: map Code: unrecognized_keys ``` **base** exits 0 with `✓ Schema is valid!`. `objectui validate`, the same node inside a `div`'s `children`: **head** exits 1. The top-level issue is generic, but the arm detail printed under it names the key: ```text 1. Invalid input Path: children Code: invalid_union ... 1.6 [arm 1/6] Unrecognized key: "latitudeFieId" Path: children → 0 → map Code: unrecognized_keys ``` That is 1 of 10 arm sub-lines. The other nine are the non-matching arms (`expected object / string / number / boolean / null`). **base** exits 0 with `✓ Schema is valid!` and `Children: 1`. `objectui check` (advisory) over a directory holding the root typo, the nested typo, a root typo that also carries `className`, and the clean node exits 0 on both sides: - **head** lists only the root typo file, under `⚠️ 1 file carries a registered ObjectUI component type but did not validate as an ObjectUI schema`, then prints `✓ All checks passed`. - **base** lists nothing and prints `✓ All checks passed`. - `check` validates only to recognise a file. A root that carries a structural key (`children`, `className`, …) is admitted without being validated, so the nested typo and the `className` typo stay invisible to `check`. The command's own description sends the verdict to `objectui validate`. ⇒ The rendered refusal names the key at both depths, so under the ruling's condition this needs no follow-up card. The noise around the nested line is recorded in the Acceptance notes. ## Gates Everything below is at head `d68b1086ed`. Test runs went through `os-verify-lock.sh`, and every verdict line is quoted from that run. - Tests: `pnpm exec vitest run --maxWorkers=2 packages/types/ packages/cli/` plus the 31 test files outside those packages that read `ObjectMapConfigSchema` / `ObjectMapSchema` / `FLAT_MAP_CONFIG_KEYS` or author an `object-map` (found with `git grep`), plus `examples/schema-catalog/test/`. Result: `Test Files 358 passed (358)`, `Tests 9311 passed (9311)`. - `pnpm exec vitest run --maxWorkers=2 packages/plugin-map/` plus the new types pin: `Test Files 34 passed (34)`, `Tests 243 passed (243)`. - `pnpm --filter @object-ui/types type-check`, `@object-ui/plugin-map type-check` and `@object-ui/cli type-check`: `VERDICT command-exit 0`. Both new test files are in their package's `tsconfig.test.json` (`--listFilesOnly`, 1 hit each). The `plugin-map^...` dependency closure was built first. - The strict-twin and mirror-parity pins (`strict-authoring-face-8345.test.ts`, `zod-mirror-parity.test.ts`) are inside the types run above, and green. - `check-changeset-presence`: `✅ 3 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)`. - `check-changeset-no-major`: `✅ No changeset declares a major bump`. - `check-changeset-overwrite`: `✅ No pre-existing changeset was modified or deleted`. - `check:changeset-claims` (report-only) exits 0. It lists 22 pending changesets that name a file this change touches. I re-read the seven that mention `map`, strip or tolerance, and none describes `ObjectMapConfigSchema`'s accept set. - `check:pending-changeset-literals`: `✅`. - `check:new-line-citations`: `VERDICT new-cross-file-line-citations: 0 new citation(s)`. - `check:control-bytes`: `✅ OK`. A self-scan of the changed files for control bytes found none. - `check:spec-symbols`: `✅`. - `check-doc-links`: `Links are valid across 17 scan roots`. - `check:doc-fences`, `check:doc-types`, `check-prompt-component-keys`, `check:test-path-roots`, `check:vi-mock-specifiers`: all `✅`. - Governed-surface test on the changed paths: `✅ NOT GOVERNED`. - ESLint on the three changed TS files with `--no-inline-config --format json`: 0 errors, 0 warnings on the two new pins. The one warning in `objectql.zod.ts` predates this change. This is a narrowed run: the config enables no type-aware linting, so this diff cannot move another file's verdict. The repo-wide lint is CI's. - Eager closure: `@object-ui/types/zod` is **not** in the console's eager closure. The console build's own guard printed `[plugin assert-types-zod-stays-lazy] ... 1 chunk(s) holding the validators, none in the eager closure`, and `pnpm check:eager-closure` reads `✅ Console eager closure is 3103.9 KB gzipped ... (budget: 3104.5 KB, headroom: 0.6 KB)`. That is the same reading the dispatch quoted, so the delta is 0.0 KB at the gate's precision. - `git merge-tree --write-tree origin/main HEAD` against a fresh `origin/main` `f667c1df97` exits 0 (clean). None of the four commits that landed since the base touch these files. - NOT MEASURED: `check:doc-snippets` / `check:doc-examples`. Reason: they compile against every built package. This diff adds no code fence and changes no TypeScript declaration, so CI's run is the reading. ## Acceptance notes - The dispatch expected the runtime pin (i) to be green on base. Measured, only its render half is. Its warn half is red on base, because the tolerant schema never fails the `safeParse`, so nothing is warned. The ablation above shows it. - The dispatch said `FLAT_MAP_CONFIG_KEYS` stays at 8 keys. `.shape` has 8 keys. `FLAT_MAP_CONFIG_KEYS` filters out `style` and has 7, before and after. - Nested diagnostics: the key is named, but as sub-line 1.6 of 10 under a generic `invalid_union`, and nine of those lines describe arms that were never candidates. That is a readability note on the CLI's arm printer, not a missing diagnostic. I filed no card. - `objectui check` admits a file whose root carries a structural key without validating it, so no depth of `map` typo in such a file reaches `check`. It is advisory by its own description. Recorded, not filed. - The docblock of `warnOnTopLevelStyleUrl` in `ObjectMap.tsx` still says `@objectstack/spec` list-view schemas "declare no `map` block at all". On spec 17.4.0, `ListViewSchema` declares `map`, and it refuses `latitudeFieId` with `unrecognized_keys` at `map`. That is a stale comment in a file this change does not touch. Noted, not fixed here, and no carrier. - Siblings with the same shape (a declared config sub-block that does not close) exist, for example the `object-calendar` node's `calendar` block (spec-derived, kept `.passthrough()`) and plain `z.object` config schemas such as `SortConfigSchema`, `DrillDownConfigSchema` and `ReportExportConfigSchema`. Not measured and not touched: the standing condition keeps generalisation out of this card. --- _Generated by [Claude Code](https://claude.ai/code/session_014mXUNuFomfj24w7s1pZzhN)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
This branch had an error being deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix plugin-aggrid documentation demo missing styles ✅
Summary
Fixed the issue where AG Grid styles were not loading in the documentation demos. The problem occurred because CSS imports in dynamically loaded modules aren't properly processed by Next.js.
Changes Made:
Technical Details:
The issue occurred because AG Grid CSS was only imported in the dynamically loaded plugin module (
@object-ui/plugin-aggrid). When using dynamic imports in Next.js client components, CSS imports from the dynamically loaded module may not be properly processed.Solution:
apps/site/app/layout.tsx(root layout) - all 4 themes used in demosag-grid-community@^32.3.9andag-grid-react@^32.3.9as direct dependencies inapps/site/package.jsonFiles Changed:
apps/site/app/layout.tsx- Added AG Grid CSS imports (5 files: base + 4 themes)apps/site/package.json- Added ag-grid dependenciespackages/plugin-aggrid/README.md- Added Next.js setup documentationpnpm-lock.yaml- Updated with new dependenciesTesting:
Security Summary:
No security vulnerabilities found in the changes.
Original prompt
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.