Update registry implementation and prepare UI #2340
Conversation
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
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughChanges refactor the DotrainRegistry's order details retrieval to return a structured result containing both valid and invalid entries, introduce validation capability without full registry fetch, and add a Svelte provider pattern for context management across UI components. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Areas requiring extra attention:
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
Comment |
Collaborator
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (9)
crates/js_api/ARCHITECTURE.md(1 hunks)crates/js_api/src/registry.rs(8 hunks)packages/orderbook/README.md(1 hunks)packages/orderbook/test/js_api/dotrainRegistry.test.ts(2 hunks)packages/ui-components/src/__tests__/DotrainRegistryProvider.test.ts(1 hunks)packages/ui-components/src/lib/index.ts(3 hunks)packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.svelte(1 hunks)packages/ui-components/src/lib/providers/dotrainRegistry/context.ts(1 hunks)packages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (11)
**/crates/**
📄 CodeRabbit inference engine (AGENTS.md)
Rust workspace organized as
crates/*with subdirectories: cli, common, bindings, js_api, quote, subgraph, settings, math, integration_tests
Files:
crates/js_api/ARCHITECTURE.mdcrates/js_api/src/registry.rs
packages/ui-components/**/*.{svelte,ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
For UI components (
packages/ui-components), run lints and format checks usingnix develop -c npm run svelte-lint-format-check -w @rainlanguage/ui-components
Files:
packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.sveltepackages/ui-components/src/lib/index.tspackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
packages/{webapp,ui-components}/**/*.{svelte,ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
If you modify frontend code or functionality affecting the frontend, you MUST provide a screenshot of the built webapp reflecting your change.
Files:
packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.sveltepackages/ui-components/src/lib/index.tspackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
packages/**/*.{js,ts,svelte}
📄 CodeRabbit inference engine (AGENTS.md)
JavaScript/Svelte organized as
packages/*including webapp, ui-components, and orderbook (wasm wrapper published to npm)
Files:
packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.sveltepackages/ui-components/src/lib/index.tspackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.tspackages/orderbook/test/js_api/dotrainRegistry.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
**/*.{ts,tsx,svelte}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{ts,tsx,svelte}: TypeScript/Svelte: format withnix develop -c npm run format
TypeScript/Svelte: lint withnix develop -c npm run lint
TypeScript/Svelte: type-check withnix develop -c npm run check
Files:
packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.sveltepackages/ui-components/src/lib/index.tspackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.tspackages/orderbook/test/js_api/dotrainRegistry.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
**/*.svelte
📄 CodeRabbit inference engine (AGENTS.md)
Svelte components should use
PascalCase.sveltenaming convention; other files use kebab or snake case as appropriate
Files:
packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.svelte
packages/ui-components/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
For UI components (
packages/ui-components), run tests usingnix develop -c npm run test -w @rainlanguage/ui-components
Files:
packages/ui-components/src/lib/index.tspackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
**/*.{test,spec}.ts
📄 CodeRabbit inference engine (AGENTS.md)
TypeScript/Svelte: run tests with
nix develop -c npm run test(Vitest). Name test files*.test.tsor*.spec.ts
Files:
packages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/orderbook/test/js_api/dotrainRegistry.test.ts
packages/orderbook/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
packages/orderbook/**/*.{ts,tsx,js,jsx}: For Orderbook TypeScript (packages/orderbook), run lints usingnix develop -c npm run check -w @rainlanguage/orderbook
For Orderbook TypeScript (packages/orderbook), run tests usingnix develop -c npm run test -w @rainlanguage/orderbook
Files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
crates/**/*.rs
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
crates/**/*.rs: For Rust crates incrates/*, run lints usingnix develop -c cargo clippy --workspace --all-targets --all-features -D warnings
For Rust crates incrates/*, run tests usingnix develop -c cargo test --workspaceor--package <crate>
Files:
crates/js_api/src/registry.rs
**/*.rs
📄 CodeRabbit inference engine (AGENTS.md)
**/*.rs: Rust: format code withnix develop -c cargo fmt --all
Rust: lint withnix develop -c rainix-rs-static(preconfigured flags included)
Rust: crates and modules usesnake_case; types usePascalCase
Files:
crates/js_api/src/registry.rs
🧠 Learnings (34)
📓 Common learnings
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T21:24:53.708Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, provide a separate comment after each review with PR size statistics in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding lock files like package-lock.json and cargo.lock.
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T22:14:22.646Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, I must consistently report the PR size after EVERY new commit in the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number" without any additional text or formatting blocks. The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock) and can be included either as part of the review or as a separate comment.
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T21:26:31.566Z
Learning: For PR #1884 and future PRs in rainlanguage/rain.orderbook repository, provide PR size reports in a separate comment with ONLY the exact format "TOTAL=number\nADDITIONS=number\nDELETIONS=number", without any additional text or explanation. Reports should exclude irrelevant files such as lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1565
File: packages/webapp/src/__tests__/registryManager.test.ts:227-238
Timestamp: 2025-04-09T13:00:24.640Z
Learning: In the rain.orderbook project, error handling was added to the RegistryManager to handle localStorage exceptions, addressing part of the verification agent's suggestions. The team should also consider testing extremely long URLs that might approach browser limits.
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T21:25:47.873Z
Learning: After each new commit review for rainlanguage/rain.orderbook repository, generate a PR size report in a separate comment with the format: "TOTAL=number ADDITIONS=number DELETIONS=number". This report should exclude irrelevant files such as lock files (e.g., package-lock.json, cargo.lock).
Learnt from: rouzwelt
Repo: rainlanguage/rain.orderbook PR: 0
File: :0-0
Timestamp: 2025-05-21T21:25:47.873Z
Learning: After each new commit review for rainlanguage/rain.orderbook repository, generate a PR size report in a separate comment with the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". This report should exclude irrelevant files such as lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:0-0
Timestamp: 2025-04-09T09:28:05.097Z
Learning: The OrderDetail component has been refactored to use an `onRemove` callback approach instead of the previous `handleOrderRemoveModal` pattern for order removal functionality, as part of PR #1512.
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1565
File: packages/webapp/src/lib/services/loadRegistryUrl.ts:21-95
Timestamp: 2025-04-09T12:57:52.799Z
Learning: In the loadRegistryUrl function, invalid URL format validation is handled by the fetchRegistryDotrains function rather than explicit URL format validation within loadRegistryUrl itself. The error handling in the catch block will handle any failures from the fetch operation.
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1907
File: packages/orderbook/test/common/test.test.ts:75-77
Timestamp: 2025-06-04T10:21:01.388Z
Learning: The DotrainOrder.create API in packages/orderbook/test/common/test.test.ts is internal and not used directly in consumer applications, so API changes here don't require external breaking change documentation.
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1515
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/layout.test.ts:0-0
Timestamp: 2025-03-26T16:22:50.224Z
Learning: In the Rain Orderbook project, the DotrainOrderGui.getDeploymentDetail method resolves promises with objects that may contain either a value property or an error property, rather than rejecting promises on errors.
📚 Learning: 2025-07-30T07:41:39.271Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2012
File: crates/js_api/src/registry.rs:485-512
Timestamp: 2025-07-30T07:41:39.271Z
Learning: In crates/js_api/src/registry.rs, findolor considers the current concurrent fetching of order files using futures::future::join_all without concurrency limits to be acceptable, preferring the simple approach over adding concurrency limiting mechanisms for the DotrainRegistry implementation.
Applied to files:
crates/js_api/ARCHITECTURE.mdpackages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.sveltepackages/orderbook/test/js_api/dotrainRegistry.test.tscrates/js_api/src/registry.rs
📚 Learning: 2025-03-26T16:22:50.224Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1515
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/layout.test.ts:0-0
Timestamp: 2025-03-26T16:22:50.224Z
Learning: In the Rain Orderbook project, the DotrainOrderGui.getDeploymentDetail method resolves promises with objects that may contain either a value property or an error property, rather than rejecting promises on errors.
Applied to files:
crates/js_api/ARCHITECTURE.mdpackages/orderbook/README.md
📚 Learning: 2025-06-11T11:39:15.239Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1917
File: tauri-app/src/routes/orders/add/+page.svelte:45-47
Timestamp: 2025-06-11T11:39:15.239Z
Learning: In the rain.orderbook codebase, every instance of `Config` (returned by helpers such as `parseDotrainAndYaml`) is guaranteed to include the `dotrainOrder` property; it is never `undefined`.
Applied to files:
packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.svelte
📚 Learning: 2025-06-04T10:21:01.388Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1907
File: packages/orderbook/test/common/test.test.ts:75-77
Timestamp: 2025-06-04T10:21:01.388Z
Learning: The DotrainOrder.create API in packages/orderbook/test/common/test.test.ts is internal and not used directly in consumer applications, so API changes here don't require external breaking change documentation.
Applied to files:
packages/ui-components/src/lib/index.tspackages/orderbook/README.mdpackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.tspackages/orderbook/test/js_api/dotrainRegistry.test.tscrates/js_api/src/registry.rs
📚 Learning: 2025-09-02T08:04:44.814Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2117
File: packages/ui-components/src/__tests__/VaultIdInformation.test.ts:9-13
Timestamp: 2025-09-02T08:04:44.814Z
Learning: In packages/ui-components/src/__tests__/VaultIdInformation.test.ts and similar test files in the rain.orderbook project, the passthrough vi.mock('rainlanguage/orderbook', async (importOriginal) => { return { ...(await importOriginal()) }; }); block is required for tests to run properly, even when not overriding any exports. This is needed due to the specific Vitest configuration or test environment setup in the project.
Applied to files:
packages/ui-components/src/lib/index.tspackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.tspackages/orderbook/test/js_api/dotrainRegistry.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
📚 Learning: 2025-08-14T18:29:32.933Z
Learnt from: brusherru
Repo: rainlanguage/rain.orderbook PR: 2083
File: packages/ui-components/src/__tests__/VaultsListTable.test.ts:16-19
Timestamp: 2025-08-14T18:29:32.933Z
Learning: In the rain.orderbook project's UI components tests, mocking hooks like useToasts is often required as infrastructure even when not directly asserting on their calls, because components internally depend on these hooks. Removing such mocks would break component rendering in tests and require more complex test setup with providers.
Applied to files:
packages/ui-components/src/lib/index.tspackages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.ts
📚 Learning: 2025-08-01T09:07:20.383Z
Learnt from: brusherru
Repo: rainlanguage/rain.orderbook PR: 2044
File: packages/orderbook/README.md:186-189
Timestamp: 2025-08-01T09:07:20.383Z
Learning: In the rainlanguage/rain.orderbook project, Rust methods on structs like RaindexVaultsList are exported as JavaScript getters in WASM bindings using #[wasm_bindgen(getter)]. This means while the Rust code uses method calls like items(), the JavaScript/WASM API exposes them as property access like .items. The README.md correctly documents the JavaScript API surface, not the Rust implementation details.
Applied to files:
packages/orderbook/README.mdcrates/js_api/src/registry.rs
📚 Learning: 2025-08-15T20:56:15.592Z
Learnt from: brusherru
Repo: rainlanguage/rain.orderbook PR: 1978
File: packages/webapp/src/routes/deploy/[orderName]/[deploymentKey]/fullDeployment.test.ts:22-29
Timestamp: 2025-08-15T20:56:15.592Z
Learning: In packages/webapp/src/routes/deploy/[orderName]/[deploymentKey]/fullDeployment.test.ts, brusherru prefers fail-fast testing approaches where type mismatches cause immediate test failures to alert developers about interface changes, rather than using defensive programming with type guards that might mask API evolution.
Applied to files:
packages/orderbook/README.mdpackages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-07-04T10:23:41.820Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1956
File: packages/orderbook/test/js_api/raindexClient.test.ts:91-99
Timestamp: 2025-07-04T10:23:41.820Z
Learning: In the rain.orderbook project, maintainer findolor is fine with test code patterns that might seem like inverted logic in production contexts, such as the extractWasmEncodedData function in test files that returns undefined values when result.value is undefined.
Applied to files:
packages/orderbook/README.mdpackages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-05-14T05:51:50.277Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1715
File: crates/js_api/src/common/mod.rs:55-59
Timestamp: 2025-05-14T05:51:50.277Z
Learning: In the Rain Orderbook project, the error handling for WASM exported functions uses WasmEncodedError which includes both the original error message and a human-readable version, making direct modification of the JsValue conversion unnecessary.
Applied to files:
packages/orderbook/README.mdcrates/js_api/src/registry.rs
📚 Learning: 2025-05-19T18:24:17.608Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1860
File: packages/ui-components/src/lib/stores/transactionStore.ts:130-136
Timestamp: 2025-05-19T18:24:17.608Z
Learning: In the `rain.orderbook` project, the `getTransaction` function (and related entity fetch functions) use `wasmEncodedResult` to validate the returned data, ensuring that only valid data is returned. This makes a simple truthiness check (`!!data`) sufficient for the `isSuccess` predicate in `awaitSubgraphIndexing`.
Applied to files:
packages/orderbook/README.mdpackages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-07-09T12:35:45.699Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1974
File: packages/ui-components/src/__tests__/DeploymentSteps.test.ts:123-126
Timestamp: 2025-07-09T12:35:45.699Z
Learning: In packages/ui-components/src/__tests__/DeploymentSteps.test.ts, findolor prefers to keep mock initializations (like setSelectToken) in individual test cases rather than consolidating them into shared beforeEach blocks, even when it results in duplication.
Applied to files:
packages/ui-components/src/__tests__/DotrainRegistryProvider.test.ts
📚 Learning: 2025-07-17T10:36:02.846Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1996
File: packages/ui-components/src/__tests__/VaultIdInformation.test.ts:6-6
Timestamp: 2025-07-17T10:36:02.846Z
Learning: In packages/ui-components/src/__tests__/VaultIdInformation.test.ts, findolor prefers to keep exported type aliases like `VaultIdInformationComponentProps` in test files, even when static analysis tools flag this as discouraged practice.
Applied to files:
packages/ui-components/src/__tests__/DotrainRegistryProvider.test.ts
📚 Learning: 2025-03-24T12:27:07.862Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1494
File: packages/ui-components/src/__tests__/WalletProvider.test.ts:18-28
Timestamp: 2025-03-24T12:27:07.862Z
Learning: In the WalletProvider tests, verifying that setAccountContext is called with the correct store is sufficient. Additional testing of Svelte's store implementation (like subscribing to verify the store value) is unnecessary as it would just be testing the framework itself.
Applied to files:
packages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
📚 Learning: 2025-06-30T14:17:16.626Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1926
File: packages/ui-components/src/lib/__mocks__/stores.ts:13-17
Timestamp: 2025-06-30T14:17:16.626Z
Learning: User findolor reports that vi.mock(import('rainlanguage/orderbook'), async (importOriginal) => { ... }) syntax works in their testing environment, despite official Vitest documentation indicating the first argument should be a string. This suggests there may be specific Vitest versions or configurations that support dynamic import() as the first argument to vi.mock().
Applied to files:
packages/ui-components/src/__tests__/DotrainRegistryProvider.test.ts
📚 Learning: 2025-06-17T14:55:22.914Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1936
File: packages/ui-components/vite.config.ts:21-23
Timestamp: 2025-06-17T14:55:22.914Z
Learning: In the rain.orderbook project, the Vite configuration uses `'import.meta.vitest': 'undefined'` (as a string) combined with conditional `if (import.meta.vitest)` checks for in-source testing. The mock files are excluded from test execution using `exclude: ['src/lib/__mocks__/**/*.ts']`. This configuration successfully allows dev builds to work without `vi` undefined errors, despite the theoretical expectation that the string "undefined" would be truthy and cause issues.
Applied to files:
packages/ui-components/src/__tests__/DotrainRegistryProvider.test.tspackages/ui-components/src/lib/providers/dotrainRegistry/context.ts
📚 Learning: 2025-04-09T13:00:24.640Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1565
File: packages/webapp/src/__tests__/registryManager.test.ts:227-238
Timestamp: 2025-04-09T13:00:24.640Z
Learning: In the rain.orderbook project, error handling was added to the RegistryManager to handle localStorage exceptions, addressing part of the verification agent's suggestions. The team should also consider testing extremely long URLs that might approach browser limits.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-04-09T12:57:52.799Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1565
File: packages/webapp/src/lib/services/loadRegistryUrl.ts:21-95
Timestamp: 2025-04-09T12:57:52.799Z
Learning: In the loadRegistryUrl function, invalid URL format validation is handled by the fetchRegistryDotrains function rather than explicit URL format validation within loadRegistryUrl itself. The error handling in the catch block will handle any failures from the fetch operation.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-07-23T10:51:18.597Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2012
File: packages/orderbook/test/js_api/dotrainRegistry.test.ts:10-10
Timestamp: 2025-07-23T10:51:18.597Z
Learning: In the rain.orderbook project, maintainer findolor is fine with using `typeof void 0 === typeof result.value` for undefined checks in test files like packages/orderbook/test/js_api/dotrainRegistry.test.ts, preferring to keep this pattern rather than changing it to `result.value === undefined` for readability.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-08-02T02:34:32.237Z
Learnt from: brusherru
Repo: rainlanguage/rain.orderbook PR: 2036
File: crates/js_api/src/filters/raindex_filter_store.rs:446-533
Timestamp: 2025-08-02T02:34:32.237Z
Learning: In the rainlanguage/rain.orderbook project's RaindexFilterStore WASM tests (crates/js_api/src/filters/raindex_filter_store.rs), brusherru decided to focus on testing only methods without side effects (that don't use web_sys) due to difficulties with mocking localStorage and window APIs in the WASM test environment. This pragmatic approach tests pure logic separately from browser integration.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.tscrates/js_api/src/registry.rs
📚 Learning: 2025-07-31T19:34:11.716Z
Learnt from: brusherru
Repo: rainlanguage/rain.orderbook PR: 2044
File: crates/common/src/raindex_client/vaults_list.rs:363-423
Timestamp: 2025-07-31T19:34:11.716Z
Learning: In the rainlanguage/rain.orderbook project, for WASM-exposed functionality like VaultsList, the team prefers to keep comprehensive tests in the non-WASM environment due to the complexity of recreating objects like RaindexVaults in WASM. WASM tests focus on basic functionality and error cases since the WASM code reuses the already-tested non-WASM implementation.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.tscrates/js_api/src/registry.rs
📚 Learning: 2025-11-25T16:50:11.197Z
Learnt from: CR
Repo: rainlanguage/rain.orderbook PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-25T16:50:11.197Z
Learning: Applies to packages/orderbook/**/*.{ts,tsx,js,jsx} : For Orderbook TypeScript (`packages/orderbook`), run tests using `nix develop -c npm run test -w rainlanguage/orderbook`
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-04-09T12:58:03.399Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1565
File: packages/webapp/src/lib/services/loadRegistryUrl.ts:5-19
Timestamp: 2025-04-09T12:58:03.399Z
Learning: In the rain.orderbook application, URL validation for registry URLs is handled at the frontend/component level before the `loadRegistryUrl` function is called, so additional validation within this function is not necessary.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-06-08T18:43:51.842Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1891
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/page.test.ts:66-80
Timestamp: 2025-06-08T18:43:51.842Z
Learning: In the rain.orderbook webapp test files, when mocking objects like the transaction manager, it's acceptable to use simple empty objects with ts-expect-error comments rather than providing complete mock implementations with all properties and methods.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-05-19T18:24:17.608Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1860
File: packages/ui-components/src/lib/stores/transactionStore.ts:130-136
Timestamp: 2025-05-19T18:24:17.608Z
Learning: In the `rain.orderbook` project, the `awaitSubgraphIndexing` function has a two-step validation process: it first checks that `data.value` from `WasmEncodedResult` exists, and only then applies the `isSuccess` predicate. This makes a simple truthiness check (`!!data`) sufficient in the `isSuccess` predicate since the value has already been pre-validated.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-04-08T12:56:03.272Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:125-143
Timestamp: 2025-04-08T12:56:03.272Z
Learning: The OrderDetail component in the Rain orderbook UI doesn't currently have error handling tests, but issue #1605 has been created to address this in the future.
Applied to files:
packages/orderbook/test/js_api/dotrainRegistry.test.ts
📚 Learning: 2025-03-31T10:16:53.544Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1469
File: packages/ui-components/src/__tests__/CodeMirrorDotrain.test.ts:75-98
Timestamp: 2025-03-31T10:16:53.544Z
Learning: In the rainlanguage/rain.orderbook project, direct manipulation of Svelte's internal state (component.$$.ctx) in tests is an acceptable approach for testing component behavior, as demonstrated in the CodeMirrorDotrain tests.
Applied to files:
packages/ui-components/src/lib/providers/dotrainRegistry/context.ts
📚 Learning: 2025-05-14T05:52:04.270Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1715
File: crates/js_api/src/common/mod.rs:15-22
Timestamp: 2025-05-14T05:52:04.270Z
Learning: The project doesn't require `#[repr(transparent)]` for newtype wrappers in WASM contexts such as `AddOrderCalldata` and `RemoveOrderCalldata` as the current implementation is working as expected without it.
Applied to files:
crates/js_api/src/registry.rs
📚 Learning: 2025-08-01T07:35:13.418Z
Learnt from: brusherru
Repo: rainlanguage/rain.orderbook PR: 2036
File: crates/js_api/src/filters/errors.rs:39-46
Timestamp: 2025-08-01T07:35:13.418Z
Learning: In the Rain Orderbook project's PersistentFilterStoreError (crates/js_api/src/filters/errors.rs), the Display implementation already provides user-friendly error messages, so using err.to_string() for both msg and readable_msg in the WasmEncodedError conversion is appropriate and doesn't require separate readable message handling.
Applied to files:
crates/js_api/src/registry.rs
📚 Learning: 2025-05-19T13:40:56.080Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1858
File: crates/subgraph/src/orderbook_client/mod.rs:54-58
Timestamp: 2025-05-19T13:40:56.080Z
Learning: The `wasm_bindgen_utils` crate in the Rain Orderbook project handles conditional compilation for `JsValue` and `JsError` internally, allowing `impl From<Error> for JsValue` to work on non-WASM targets without explicit cfg guards.
Applied to files:
crates/js_api/src/registry.rs
📚 Learning: 2025-06-06T16:38:04.182Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1913
File: Cargo.toml:55-55
Timestamp: 2025-06-06T16:38:04.182Z
Learning: In rain.orderbook repository, during PR chains involving dependency updates, wasm-bindgen-utils may temporarily point to git commits that don't contain the full required functionality, with the understanding that subsequent PRs in the chain will update it to the correct commit.
Applied to files:
crates/js_api/src/registry.rs
📚 Learning: 2025-04-30T09:28:36.960Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1715
File: crates/js_api/src/common/mod.rs:111-118
Timestamp: 2025-04-30T09:28:36.960Z
Learning: In the rain.orderbook repository, the WASM tests are already properly configured with conditional compilation using `#[cfg(target_family = "wasm")]` and `#[cfg(not(target_family = "wasm"))]`, and don't require additional `wasm_bindgen_test_configure!(run_in_browser)` directives.
Applied to files:
crates/js_api/src/registry.rs
📚 Learning: 2025-06-17T16:21:24.384Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1903
File: crates/settings/src/yaml/orderbook.rs:371-377
Timestamp: 2025-06-17T16:21:24.384Z
Learning: In crates/settings/src/yaml/orderbook.rs tests, the user findolor considers RPC ordering in Vec<Url> assertions to be intentional and not a test brittleness issue. The ordering of RPCs in tests should be preserved as specified.
Applied to files:
crates/js_api/src/registry.rs
🧬 Code graph analysis (5)
packages/ui-components/src/__tests__/DotrainRegistryProvider.test.ts (1)
packages/ui-components/src/lib/providers/dotrainRegistry/context.ts (1)
setDotrainRegistryContext(13-15)
packages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.ts (2)
packages/ui-components/src/lib/index.ts (1)
useDotrainRegistry(150-150)packages/ui-components/src/lib/providers/dotrainRegistry/context.ts (1)
getDotrainRegistryContext(17-25)
packages/orderbook/test/js_api/dotrainRegistry.test.ts (1)
crates/settings/src/orderbook.rs (1)
value(48-49)
packages/ui-components/src/lib/providers/dotrainRegistry/context.ts (1)
packages/ui-components/src/lib/index.ts (2)
DotrainRegistryContext(89-89)RegistryManager(153-153)
crates/js_api/src/registry.rs (1)
crates/js_api/src/gui/mod.rs (1)
get_order_details(432-441)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (12)
crates/js_api/src/registry.rs (5)
116-125: Well-designed structs for WASM interop.The
OrderDetailsResultandOrderUrlstypes cleanly separate valid/invalid orders and provide a consistent WASM-friendly interface. The use ofimpl_wasm_traits!macro aligns with the project's patterns for serialization.
268-288: Useful lightweight validation method.The
validate()function addresses the PR objective of checking registry URLs before committing to a full fetch. It correctly reusesfetch_and_parse_registry()to verify format without downloading settings or order content.
316-339: Improved error handling for order details.The refactored
get_all_order_details()now gracefully handles individual order failures by collecting them in theinvalidmap rather than failing the entire operation. This matches the PR objective of returning both valid and invalid orders for better order management.
883-915: Good test coverage for invalid order handling.The new test
test_get_all_order_details_with_invalid_orderproperly validates that:
- Valid orders are placed in the
validmap- Invalid orders are placed in the
invalidmap with error details- The overall operation succeeds despite individual failures
208-220:OrderUrlsis the initial implementation, not a change fromjs_sys::Map.This is a new implementation introduced in the recent revert commit. There is no previous version returning
js_sys::Mapto migrate from. TheOrderUrlsstruct withTsifyserialization generates JavaScript Map types automatically, which is compatible with how the test file uses it (with.size,.get(),.has()methods). No downstream updates are required as this is not a breaking change to existing consumers.crates/js_api/ARCHITECTURE.md (1)
130-130: Documentation accurately reflects API change.The architecture doc correctly describes the updated
getAllOrderDetails()behavior, noting that it now returns both valid and invalid entries keyed by order.packages/orderbook/README.md (1)
397-398: README correctly documents the new API shape.The example clearly shows the updated access pattern for
getAllOrderDetails():
orderMenuResult.value.validfor successfully parsed ordersorderMenuResult.value.invalidfor orders with errorsThis aligns with the Rust implementation and helps consumers migrate to the new interface.
packages/orderbook/test/js_api/dotrainRegistry.test.ts (2)
215-231: Good test coverage for the new validate() method.The tests properly verify:
- Successful validation returns
undefined(void)- Invalid registry format triggers an error
259-272: Tests correctly verify the new getAllOrderDetails() structure.The assertions properly check:
orderDetails.valid.sizefor valid order countorderDetails.invalid.sizefor invalid order count- Access via
orderDetails.valid.get('fixed-limit')for individual detailspackages/ui-components/src/lib/index.ts (1)
89-89: Expose Dotrain registry context/provider/hook via public APIThe new exports are correctly named, live in the right sections (types/providers/hooks), and point to valid module paths; this cleanly wires the Dotrain registry feature into the public UI-components surface.
Also applies to: 140-140, 150-150
packages/ui-components/src/lib/providers/dotrainRegistry/DotrainRegistryProvider.svelte (1)
1-13: DotrainRegistryProvider correctly wires props into Svelte contextThe provider cleanly exposes
registry,error, andmanagervia a reactivesetDotrainRegistryContextcall and renders only its slot, which fits the existing provider conventions in this package. Just ensure the usual UI-components commands (nix develop -c npm run format,lint,check,npm run svelte-lint-format-check -w @rainlanguage/ui-components, and tests) have been run, and attach an updated UI screenshot if this provider affects visible flows.packages/ui-components/src/lib/providers/dotrainRegistry/context.ts (1)
1-63: Context helper and tests are well-structuredThe
DotrainRegistryContextshape,setDotrainRegistryContext, andgetDotrainRegistryContexthelpers are consistent with Svelte context patterns, and the error message for missing context is explicit and helpful. The in-source tests that mockgetContextto cover both existing and missing contexts give solid coverage without over-testing Svelte internals.
Comment on lines
+262
to
+263
| assert.strictEqual(orderDetails.valid.size, 2); | ||
| assert.strictEqual(orderDetails.invalid.size, 0); |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider adding a test for mixed valid/invalid orders.
The current tests verify all-valid scenarios. Consider adding a test case where some orders are valid and others invalid to ensure the JS API correctly handles the mixed result structure (similar to test_get_all_order_details_with_invalid_order in the Rust tests).
it('should separate valid and invalid orders in getAllOrderDetails', async () => {
const registryContent = `http://localhost:8231/settings.yaml
valid-order http://localhost:8231/valid.rain
invalid-order http://localhost:8231/invalid.rain`;
await mockServer.forGet('/registry.txt').thenReply(200, registryContent);
await mockServer.forGet('/settings.yaml').thenReply(200, MOCK_SETTINGS_CONTENT);
await mockServer.forGet('/valid.rain').thenReply(200, FIRST_DOTRAIN_CONTENT);
await mockServer.forGet('/invalid.rain').thenReply(200, 'not-valid-dotrain');
const registry = extractWasmEncodedData(
await DotrainRegistry.new('http://localhost:8231/registry.txt')
);
const orderDetails = extractWasmEncodedData(registry.getAllOrderDetails());
assert.strictEqual(orderDetails.valid.size, 1);
assert.strictEqual(orderDetails.invalid.size, 1);
assert(orderDetails.valid.has('valid-order'));
assert(orderDetails.invalid.has('invalid-order'));
});🤖 Prompt for AI Agents
In packages/orderbook/test/js_api/dotrainRegistry.test.ts around lines 262 to
263, add a new test that covers a mixed valid/invalid orders scenario: register
one valid and one invalid order in the mocked registry content, mock the GET
responses for /registry.txt, /settings.yaml, /valid.rain and /invalid.rain
(using existing MOCK_SETTINGS_CONTENT and FIRST_DOTRAIN_CONTENT for the valid
one and a non-dotrain string for the invalid one), instantiate the
DotrainRegistry via DotrainRegistry.new and extractWasmEncodedData for the
registry and the returned getAllOrderDetails result, then assert that
orderDetails.valid.size === 1, orderDetails.invalid.size === 1 and that the
valid/invalid maps contain 'valid-order' and 'invalid-order' respectively so the
JS API behavior matches the Rust mixed-result test.
Comment on lines
1
to
28
| import { render } from '@testing-library/svelte'; | ||
| import { describe, it, expect, vi, beforeEach } from 'vitest'; | ||
| import DotrainRegistryProvider from '../lib/providers/dotrainRegistry/DotrainRegistryProvider.svelte'; | ||
| import { setDotrainRegistryContext } from '../lib/providers/dotrainRegistry/context'; | ||
|
|
||
| vi.mock('../lib/providers/dotrainRegistry/context', () => ({ | ||
| setDotrainRegistryContext: vi.fn() | ||
| })); | ||
|
|
||
| describe('DotrainRegistryProvider', () => { | ||
| const mockSetContext = vi.mocked(setDotrainRegistryContext); | ||
|
|
||
| beforeEach(() => { | ||
| mockSetContext.mockReset(); | ||
| }); | ||
|
|
||
| it('sets the registry context with provided props', () => { | ||
| const registry = {} as never; | ||
| const manager = {} as never; | ||
| render(DotrainRegistryProvider, { props: { registry, manager, error: undefined } }); | ||
|
|
||
| expect(mockSetContext).toHaveBeenCalledWith({ | ||
| registry, | ||
| manager, | ||
| error: undefined | ||
| }); | ||
| }); | ||
| }); |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Provider test covers main behavior; prefer concrete types over never
The test correctly verifies that DotrainRegistryProvider forwards its props into setDotrainRegistryContext. To keep the test coupled to the real API surface, consider using concrete types instead of never for the mocked props.
-import { render } from '@testing-library/svelte';
-import { describe, it, expect, vi, beforeEach } from 'vitest';
-import DotrainRegistryProvider from '../lib/providers/dotrainRegistry/DotrainRegistryProvider.svelte';
-import { setDotrainRegistryContext } from '../lib/providers/dotrainRegistry/context';
+import { render } from '@testing-library/svelte';
+import { describe, it, expect, vi, beforeEach } from 'vitest';
+import type { DotrainRegistry } from '@rainlanguage/orderbook';
+import type { RegistryManager } from '../lib/providers/registry/RegistryManager';
+import DotrainRegistryProvider from '../lib/providers/dotrainRegistry/DotrainRegistryProvider.svelte';
+import { setDotrainRegistryContext } from '../lib/providers/dotrainRegistry/context';
@@
- it('sets the registry context with provided props', () => {
- const registry = {} as never;
- const manager = {} as never;
+ it('sets the registry context with provided props', () => {
+ const registry = {} as DotrainRegistry;
+ const manager = {} as RegistryManager;Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/ui-components/src/__tests__/DotrainRegistryProvider.test.ts around
lines 1 to 28, the test uses {} as never for registry and manager which hides
the real API surface; replace those with concrete, minimal realistic values
typed to the actual context/provider types (import the types from the
dotrainRegistry context or provider module) or create small objects matching the
expected shape (e.g., { register: vi.fn() } for registry, { start: vi.fn() } for
manager) and type them accordingly so the test stays coupled to the real API and
fails if the shape changes.
Comment on lines
1
to
33
| import { getDotrainRegistryContext } from './context'; | ||
|
|
||
| /** | ||
| * Hook to access the current Dotrain registry context. | ||
| */ | ||
| export function useDotrainRegistry() { | ||
| return getDotrainRegistryContext(); | ||
| } | ||
|
|
||
| if (import.meta.vitest) { | ||
| const { describe, it, expect, vi, beforeEach } = import.meta.vitest; | ||
|
|
||
| vi.mock('./context', () => ({ | ||
| getDotrainRegistryContext: vi.fn() | ||
| })); | ||
|
|
||
| describe('useDotrainRegistry', () => { | ||
| const mockGetContext = vi.mocked(getDotrainRegistryContext); | ||
|
|
||
| beforeEach(() => { | ||
| mockGetContext.mockReset(); | ||
| }); | ||
|
|
||
| it('should return the registry context', () => { | ||
| const mockContext = { registry: null }; | ||
| mockGetContext.mockReturnValue(mockContext as never); | ||
|
|
||
| const result = useDotrainRegistry(); | ||
|
|
||
| expect(mockGetContext).toHaveBeenCalled(); | ||
| expect(result).toEqual(mockContext); | ||
| }); | ||
| }); |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Hook implementation is straightforward; tighten test typing
useDotrainRegistry correctly delegates to getDotrainRegistryContext and keeps the hook thin, which is appropriate here. In the test, casting mockContext to never hides the expected shape; using the actual context type would keep the test aligned with future changes.
-import { getDotrainRegistryContext } from './context';
+import { getDotrainRegistryContext } from './context';
+import type { DotrainRegistryContext } from './context';
@@
- it('should return the registry context', () => {
- const mockContext = { registry: null };
- mockGetContext.mockReturnValue(mockContext as never);
+ it('should return the registry context', () => {
+ const mockContext: DotrainRegistryContext = {
+ registry: null,
+ // manager is not exercised in this test but must exist for type safety
+ manager: {} as RegistryManager
+ };
+ mockGetContext.mockReturnValue(mockContext);Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In
packages/ui-components/src/lib/providers/dotrainRegistry/useDotrainRegistry.ts
lines 1-33, the test casts mockContext to never which hides the real context
shape; import the actual context type from './context' (e.g. import type {
DotrainRegistryContext } from './context'), declare mockContext with that type
(const mockContext: DotrainRegistryContext = { registry: null }), and use
mockGetContext.mockReturnValue(mockContext) (or mockReturnValueOnce) so the test
uses the real type instead of casting to never.
4 tasks
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.
Chained PR
Motivation
See issues:
For implementing registry on the webapp, we need to do a couple of things
Solution
Checks
By submitting this for review, I'm confirming I've done the following:
Summary by CodeRabbit
New Features
Changes
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.