Update ui to display a token dropdown#1925
Conversation
## Walkthrough
This set of changes implements a robust token list integration for token input selectors across the Rust backend and Svelte frontend. It introduces support for loading, deduplicating, and presenting tokens from remote lists, adds dual-mode token selection (dropdown and custom input), and provides comprehensive tests for these features. The UI is enhanced with new modal components, error handling, and improved asynchronous state management.
## Changes
| File(s) | Change Summary |
|---------|---------------|
| `crates/js_api/src/gui/select_tokens.rs`, `crates/js_api/src/gui/mod.rs` | Refactored token sorting/deduplication logic and YAML parsing; introduced helper for extracting YAML docs. |
| `crates/settings/src/remote/tokens.rs`, `crates/settings/src/remote_tokens.rs` | Changed token struct serialization, improved deduplication by address/chain, updated key format, and error handling for missing networks. |
| `packages/orderbook/test/js_api/gui.test.ts`, `packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/fullDeployment.test.ts` | Updated tests for new token ordering, dropdown-driven token selection, and corrected property names in mocks. |
| `packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte`, `packages/ui-components/src/lib/components/deployment/SelectToken.svelte` | Added async token loading, dual-mode token selection (dropdown/custom), new props, and improved state management. |
| `packages/ui-components/src/lib/components/deployment/TokenSelectionModal.svelte` | Introduced a new modal component for token selection with search/filter and keyboard support. |
| `packages/ui-components/src/__tests__/DeploymentSteps.test.ts`, `packages/ui-components/src/__tests__/SelectToken.test.ts`, `packages/ui-components/src/__tests__/TokenSelectionModal.test.ts` | Added and expanded tests for token loading, selection modes, error handling, and modal behavior. |
| `packages/ui-components/src/lib/errors/DeploymentStepsError.ts` | Added new error code for token loading failures. |
| `packages/webapp/src/lib/constants.ts` | Updated `REGISTRY_URL` to point to a new commit hash. |
| `crates/common/src/raindex_client/add_orders.rs` | Cleaned up unused imports in test code. |
| `packages/ui-components/test-setup.ts` | Added mock method `unsetSelectToken` to `DotrainOrderGui` mock for tests. |
## Sequence Diagram(s)
```mermaid
sequenceDiagram
participant User
participant UI (DeploymentSteps/SelectToken)
participant GUI (DotrainOrderGui)
participant Backend (Rust)
User->>UI: Open deployment form
UI->>GUI: getAllTokens()
GUI->>Backend: Fetch token list(s)
Backend-->>GUI: Return deduped, sorted tokens
GUI-->>UI: Return availableTokens
UI->>User: Show dropdown & custom input modes
alt User selects from dropdown
User->>UI: Clicks token in dropdown
UI->>GUI: Save selected token address
GUI-->>UI: Return token info
UI->>User: Show selected token
else User enters custom address
User->>UI: Switches to custom mode, enters address
UI->>GUI: Save custom token address
GUI-->>UI: Return token info or error
UI->>User: Show selected token or error
endAssessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes identified. Possibly related PRs
Suggested reviewers
Learnt from: rouzwelt Learnt from: rouzwelt Learnt from: brusherru Learnt from: rouzwelt Learnt from: rouzwelt Learnt from: findolor Learnt from: findolor Learnt from: rouzwelt Learnt from: rouzwelt Learnt from: rouzwelt Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam Learnt from: findolor Learnt from: hardingjam Learnt from: hardingjam Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam Learnt from: findolor Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam Learnt from: findolor Learnt from: findolor Learnt from: findolor Learnt from: hardingjam Learnt from: hardingjam Learnt from: hardingjam |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
🔭 Outside diff range comments (1)
packages/ui-components/src/__tests__/SelectToken.test.ts (1)
25-27: Mock path mismatch may silently break the stubThe component imports
useGuivia the alias'$lib/hooks/useGui', but the test mocks'../lib/hooks/useGui'.
Vitest treats these as different modules, so the mock might not apply, causing brittle tests.-vi.mock('../lib/hooks/useGui', () => ({ +vi.mock('$lib/hooks/useGui', () => ({ useGui: vi.fn() }));Unify the path with the import to ensure the mock is actually injected.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (17)
crates/js_api/src/gui/select_tokens.rs(2 hunks)crates/settings/src/remote/tokens.rs(1 hunks)crates/settings/src/remote_tokens.rs(1 hunks)packages/orderbook/test/js_api/gui.test.ts(6 hunks)packages/ui-components/src/__tests__/DeploymentSteps.test.ts(6 hunks)packages/ui-components/src/__tests__/OrdersListTable.test.ts(0 hunks)packages/ui-components/src/__tests__/SelectToken.test.ts(9 hunks)packages/ui-components/src/__tests__/TokenSelectionModal.test.ts(1 hunks)packages/ui-components/src/__tests__/VaultsListTable.test.ts(1 hunks)packages/ui-components/src/lib/__mocks__/stores.ts(1 hunks)packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte(3 hunks)packages/ui-components/src/lib/components/deployment/SelectToken.svelte(3 hunks)packages/ui-components/src/lib/components/deployment/TokenSelectionModal.svelte(1 hunks)packages/ui-components/src/lib/errors/DeploymentStepsError.ts(1 hunks)packages/ui-components/vite.config.ts(1 hunks)packages/webapp/src/lib/constants.ts(1 hunks)packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/fullDeployment.test.ts(3 hunks)
💤 Files with no reviewable changes (1)
- packages/ui-components/src/tests/OrdersListTable.test.ts
🧰 Additional context used
🧠 Learnings (2)
packages/ui-components/vite.config.ts (1)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1936
File: packages/ui-components/vite.config.ts:21-23
Timestamp: 2025-06-17T14:55:22.889Z
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.
packages/ui-components/src/lib/__mocks__/stores.ts (1)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1936
File: packages/ui-components/vite.config.ts:21-23
Timestamp: 2025-06-17T14:55:22.889Z
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.
⏰ Context from checks skipped due to timeout of 90000ms (16)
- GitHub Check: test
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: test
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-static)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-artifacts, true)
- GitHub Check: test
- GitHub Check: git-clean
- GitHub Check: Deploy-Preview
🔇 Additional comments (8)
packages/ui-components/vite.config.ts (1)
22-22: Exclude glob looks good but is slightly broader than necessaryBroad-matching
src/**/__mocks__/**/*will indeed keep every file below any__mocks__folder out of Vitest, but it also hides non-TS assets that Vitest would never include anyway. Nothing wrong with it, just keep in mind it may mask accidentally-placed spec files (e.g. a.test.tscopied for documentation) that you actually meant to run.packages/ui-components/src/lib/errors/DeploymentStepsError.ts (1)
16-16: Enum entry added consistently – good to go
NO_AVAILABLE_TOKENSfollows the existing naming/message pattern and remains unique in the enum.packages/ui-components/src/__tests__/VaultsListTable.test.ts (1)
67-79: NewactiveAccountsprop added – double-check component API
defaultPropsnow contains bothactiveOrderbookandactiveOrderbookRefplus the newactiveAccounts. Make sureVaultsListTableactually expects all three; mismatches become silent because excess props are simply ignored.packages/webapp/src/lib/constants.ts (1)
1-3: Registry URL bumped – verify the commit exists & is immutableThe hard-pinned commit hash ensures reproducibility. Just confirm that
20040aa009adc922091c198f3cb6cde5aa457e56is pushed torain.strategiesmain and won’t be force-changed.crates/settings/src/remote_tokens.rs (1)
223-224:logoURIfixture update aligns with serde rename – LGTMThe test JSON stub now uses the same casing (
logoURI) as the struct’s#[serde(rename = "logoURI")]attribute, so deserialization will round-trip correctly.No further issues spotted in this delta.
crates/js_api/src/gui/select_tokens.rs (1)
619-629: Assertions now align with new sort order – looks goodThe updated expectations (
decimals,name,symbol) match the deterministic address-based ordering introduced above.
No issues spotted.crates/settings/src/remote/tokens.rs (1)
38-40: Correct JSON key casing forlogoURIExplicitly overriding the camel-case rule with
#[serde(rename = "logoURI")]matches the upstream token-list specification and prevents silent deserialisation failures.
Change is precise and backwards-compatible – good catch.packages/ui-components/src/__tests__/DeploymentSteps.test.ts (1)
485-490: Nice touch emulating a slow network responseThe unresolved promise pattern accurately simulates a pending fetch and verifies the loading guard.
| if (import.meta.vitest) { | ||
| vi.mock(import('@rainlanguage/orderbook'), async (importOriginal) => { | ||
| const actual = await importOriginal(); | ||
| return { | ||
| ...actual | ||
| }; | ||
| }); | ||
| } |
There was a problem hiding this comment.
vi.mock call uses a Promise as the module identifier – this will break
Vitest expects the first argument of vi.mock to be a string module specifier, not a Promise. Passing import('@rainlanguage/orderbook') results in the mock never being registered and, in ESM, throws at runtime.
-if (import.meta.vitest) {
- vi.mock(import('@rainlanguage/orderbook'), async (importOriginal) => {
- const actual = await importOriginal();
- return {
- ...actual
- };
- });
-}
+if (import.meta.vitest) {
+ vi.mock('@rainlanguage/orderbook', async () => {
+ const actual = await vi.importActual<typeof import('@rainlanguage/orderbook')>(
+ '@rainlanguage/orderbook'
+ );
+ return { ...actual };
+ });
+}This keeps the mock strictly in the test environment and aligns with Vitest’s API.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (import.meta.vitest) { | |
| vi.mock(import('@rainlanguage/orderbook'), async (importOriginal) => { | |
| const actual = await importOriginal(); | |
| return { | |
| ...actual | |
| }; | |
| }); | |
| } | |
| if (import.meta.vitest) { | |
| vi.mock('@rainlanguage/orderbook', async () => { | |
| const actual = await vi.importActual<typeof import('@rainlanguage/orderbook')>( | |
| '@rainlanguage/orderbook' | |
| ); | |
| return { ...actual }; | |
| }); | |
| } |
🤖 Prompt for AI Agents
In packages/ui-components/src/lib/__mocks__/stores.ts around lines 9 to 16, the
vi.mock call incorrectly uses a Promise (import('@rainlanguage/orderbook')) as
the module identifier, which should be a string. Replace the Promise argument
with the string '@rainlanguage/orderbook' to correctly register the mock and
avoid runtime errors in ESM environments.
There was a problem hiding this comment.
this is not an issue
There was a problem hiding this comment.
@findolor Thank you for the clarification! I acknowledge that this pattern works correctly in your setup. I appreciate you letting me know - it helps me understand the specific configuration and requirements of your project better.
🧠 Learnings used
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
| it('renders modal button with default text when no token is selected', () => { | ||
| render(TokenSelectionModal, { | ||
| ...defaultProps, | ||
| onSelect: mockOnSelect, | ||
| onSearch: mockOnSearch | ||
| }); | ||
|
|
||
| expect(screen.getByText('Select a token...')).toBeInTheDocument(); | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Minor: duplicate render boilerplate
Several tests duplicate the render(...defaultProps) setup. Creating a small renderModal(overrides) helper would DRY this out and make future prop additions simpler.
🤖 Prompt for AI Agents
In packages/ui-components/src/__tests__/TokenSelectionModal.test.ts around lines
49 to 57, multiple tests duplicate the render setup with defaultProps. Create a
helper function named renderModal that accepts prop overrides and calls render
with defaultProps merged with those overrides. Replace all direct render calls
with this helper to reduce boilerplate and simplify future prop additions.
There was a problem hiding this comment.
@findolor Got it! No problem keeping the current test structure as-is.
|
|
||
| if (tokenInfo && tokenInfo.address.toLowerCase() !== inputValue.toLowerCase()) { | ||
| tokenInfo = null; | ||
| selectedToken = null; | ||
| } | ||
|
|
||
| if (!inputValue) { | ||
| error = ''; | ||
| tokenInfo = null; | ||
| selectedToken = null; | ||
| return; | ||
| } | ||
| checking = true; | ||
| try { | ||
| await gui.saveSelectToken(token.key, currentTarget.value); | ||
| await getInfoForSelectedToken(); | ||
| } catch (e) { | ||
| const errorMessage = (e as Error).message ? (e as Error).message : 'Invalid token address.'; | ||
| error = errorMessage; | ||
| } | ||
| } | ||
|
|
||
| checking = false; | ||
| onSelectTokenSelect(); | ||
| saveTokenSelection(inputValue); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Debounce expensive validation on every keystroke
handleInput fires saveTokenSelection(inputValue) after each character, resulting in N RPC calls for an address of length N.
Add a lightweight debounce (≈ 300 ms) or trigger only on blur/Enter to avoid hammering the backend and speeding up UX.
🤖 Prompt for AI Agents
In packages/ui-components/src/lib/components/deployment/SelectToken.svelte
around lines 137 to 151, the handleInput function calls saveTokenSelection on
every keystroke, causing excessive RPC calls. To fix this, implement a debounce
mechanism with a delay of about 300 ms before calling saveTokenSelection, or
alternatively, modify the code to trigger saveTokenSelection only on input blur
or when the Enter key is pressed, reducing unnecessary backend calls and
improving user experience.
There was a problem hiding this comment.
we do not call rpc unless the address is validated in the sdk. so until we have a full address there are no network calls
There was a problem hiding this comment.
@findolor Thank you for the clarification! That's good to know that the SDK has built-in address validation that prevents RPC calls for incomplete addresses. This makes the current implementation much more reasonable from a performance perspective.
✏️ Learnings added
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.923Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
crates/common/src/raindex_client/add_orders.rs (1)
48-50: MissingFromStrtrait import causes compile-time error
Address::from_strandBytes::from_strare trait methods provided bystd::str::FromStr.
Because the trait isn’t in scope in this module, the calls will not compile outside of the test
module (where the trait is imported).use alloy::primitives::Bytes; +use std::str::FromStr; use rain_orderbook_subgraph_client::types::Id;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (10)
crates/common/src/raindex_client/add_orders.rs(1 hunks)crates/js_api/src/gui/mod.rs(5 hunks)crates/js_api/src/gui/select_tokens.rs(2 hunks)crates/settings/src/remote/tokens.rs(2 hunks)crates/settings/src/remote_tokens.rs(7 hunks)packages/orderbook/test/js_api/gui.test.ts(4 hunks)packages/ui-components/src/__tests__/DeploymentSteps.test.ts(6 hunks)packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte(3 hunks)packages/ui-components/src/lib/errors/DeploymentStepsError.ts(1 hunks)packages/webapp/src/lib/constants.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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: rouzwelt
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#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: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T23:34:42.328Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must use the format:
TOTAL:number
ADDITIONS:number
DELETIONS:number
with no extra text, formatting blocks, or explanations, and must still exclude lock files and reassess after each new commit.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
crates/common/src/raindex_client/add_orders.rs (14)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like `#[cfg(target_family = "wasm")]` should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1710
File: crates/quote/Cargo.toml:30-30
Timestamp: 2025-05-14T04:49:14.621Z
Learning: In the rain.orderbook repository, wasm-bindgen-utils is intentionally used as an unconditional dependency because non-wasm targets (like tests) sometimes need to use it.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1859
File: crates/quote/src/quote_debug.rs:472-492
Timestamp: 2025-05-20T10:20:08.206Z
Learning: In the Rain Orderbook codebase, the `#[tokio::test(flavor = "multi_thread")]` annotation is specifically needed for tests that use `LocalEvm`, not just for consistency across all async tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: crates/js_api/src/subgraph/vault.rs:19-37
Timestamp: 2025-05-09T05:21:40.234Z
Learning: In the rain.orderbook project, the developer prefers to use tuple structs for WASM wrappers (like VaultCalldataResult, GetVaultsResult) rather than structs with named fields.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
packages/ui-components/src/lib/errors/DeploymentStepsError.ts (3)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/utils/handleDeployment.ts:10-43
Timestamp: 2025-04-04T09:56:04.949Z
Learning: In the rain.orderbook project, errors from the handleDeployment utility function are thrown to DeploymentSteps.svelte, which handles displaying the errors to the user through the DeploymentStepsError utility.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1594
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-04-05T13:16:58.971Z
Learning: In the DeploymentSteps component, the `checkingDeployment` state variable should be reset to false both after successful operations and error cases to ensure the deploy button returns to its normal state.
crates/settings/src/remote_tokens.rs (10)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/remote_tokens.rs:32-57
Timestamp: 2025-04-07T09:51:52.614Z
Learning: The implementation for remote token fetching in `crates/settings/src/remote_tokens.rs` does not include explicit timeouts/retries, as the team considers the current implementation sufficient for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/remote_networks.rs:40-75
Timestamp: 2025-04-03T09:45:04.200Z
Learning: The RemoteNetworksCfg implementation in crates/settings/src/remote_networks.rs intentionally fetches remote networks sequentially rather than in parallel.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:92-99
Timestamp: 2025-06-18T18:18:44.330Z
Learning: In crates/js_api/src/raindex/mod.rs, the get_subgraph_url_for_chain method and get_multi_subgraph_args method intentionally duplicate lookup logic because they serve different purposes: get_subgraph_url_for_chain returns only the URL string, while get_multi_subgraph_args returns MultiSubgraphArgs structures containing both URL and network information (name/label). This duplication is acceptable and by design.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1463
File: crates/settings/src/yaml/context.rs:298-304
Timestamp: 2025-03-28T10:09:10.696Z
Learning: In the `resolve_token_path` method of the Context implementation in `crates/settings/src/yaml/context.rs`, when an unknown property is accessed on a token, it returns a `ContextError::InvalidPath` error, not a `ContextError::PropertyNotFound` error.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/mod.rs:116-135
Timestamp: 2025-07-04T10:26:24.289Z
Learning: In crates/common/src/raindex_client/mod.rs, the get_multi_subgraph_args method intentionally treats Some(empty vector) the same as None for chain_ids parameter. Both cases should return all networks to support UI behavior where no selection or empty selection means "show all networks". Only when specific chain IDs are provided should the results be filtered.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:23-25
Timestamp: 2025-04-07T09:50:54.715Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs returns cloned HashMaps in getter methods (like get_remote_networks) rather than references. This design choice was explicitly accepted by the maintainer.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1859
File: crates/quote/src/quote_debug.rs:472-492
Timestamp: 2025-05-20T10:20:08.206Z
Learning: In the Rain Orderbook codebase, the `#[tokio::test(flavor = "multi_thread")]` annotation is specifically needed for tests that use `LocalEvm`, not just for consistency across all async tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:20-22
Timestamp: 2025-04-07T09:55:44.798Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs is designed to overwrite existing entries without warning when using update methods like update_remote_network. This behavior is an intentional design choice.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
crates/js_api/src/gui/mod.rs (22)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/mod.rs:258-259
Timestamp: 2025-04-22T12:50:39.581Z
Learning: In `DotrainOrderGui::generate_dotrain_text()`, the call to `.to_string()` on `self.dotrain_order.dotrain()` is necessary because there are two different implementations of the `dotrain()` method - one for WASM targets returning a String and one for non-WASM targets returning a &str. The `.to_string()` ensures type compatibility across different compilation targets.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-03-31T18:53:12.208Z
Learning: In the DotrainYaml struct, the cache field is kept public (`pub cache: Cache`) without additional getter methods, which is consistent with the existing design pattern in the codebase where other fields like `documents` are also public.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:37-44
Timestamp: 2025-03-31T14:36:11.049Z
Learning: The OrderbookYaml implementation in crates/js_api/src/yaml/mod.rs intentionally parses YAML on demand without caching results. This is a deliberate design choice by the author to process YAML only when needed rather than optimizing for repeated calls.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:31-34
Timestamp: 2025-03-31T13:57:59.660Z
Learning: The OrderbookYaml constructor in crates/js_api/src/yaml/mod.rs does not need early YAML validation. The author prefers to validate YAML only when it's actually used rather than during initialization.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-04-07T09:52:30.960Z
Learning: In the DotrainYaml struct, the newly added `cache` field is kept public without documentation, which the maintainer confirmed is acceptable for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/add_orders.rs:132-132
Timestamp: 2025-07-04T10:24:29.750Z
Learning: In the rain.orderbook codebase, findolor prefers to use `unwrap_or("")` for optional frontmatter in dotrain parsing, allowing empty strings to be handled by downstream validation in `NewConfig::try_from_yaml()` rather than adding explicit early validation checks at the extraction point.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/state_management.rs:32-35
Timestamp: 2025-04-29T11:19:41.267Z
Learning: The team prefers the `get_dotrain_hash` function to accept owned String parameters instead of string references, even though it may result in additional allocations during serialization/deserialization.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like `#[cfg(target_family = "wasm")]` should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1874
File: tauri-app/src-tauri/src/transaction_status.rs:69-127
Timestamp: 2025-05-27T06:16:35.738Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, directly accessing internal RwLock state in tests using `notice.0.read().unwrap()` is acceptable and does not require encapsulation through public getter methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:23-25
Timestamp: 2025-04-07T09:50:54.715Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs returns cloned HashMaps in getter methods (like get_remote_networks) rather than references. This design choice was explicitly accepted by the maintainer.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check `if (dotrain && deployment)` inside `onMount` is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1838
File: crates/cli/src/output.rs:29-41
Timestamp: 2025-05-19T07:14:24.219Z
Learning: For the rainlanguage/rain.orderbook repository, findolor prefers minimal documentation for straightforward functions like `output` in crates/cli/src/output.rs where the implementation is self-explanatory.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1599
File: crates/common/src/fuzz/impls.rs:91-113
Timestamp: 2025-04-11T05:55:22.504Z
Learning: Empty frontmatter validation is already handled in DotrainYaml::new through the YamlError::EmptyFile error when the yaml parser produces empty documents.
packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte (26)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1594
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-04-05T13:16:58.971Z
Learning: In the DeploymentSteps component, the `checkingDeployment` state variable should be reset to false both after successful operations and error cases to ensure the deploy button returns to its normal state.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/__tests__/DeployButton.test.ts:36-40
Timestamp: 2025-03-28T10:22:11.771Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte doesn't have an explicit disabled prop. Instead, its disabled state is internally controlled by the checkingDeployment variable, which is set to true during deployment checks.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/utils/handleDeployment.ts:10-43
Timestamp: 2025-04-04T09:56:04.949Z
Learning: In the rain.orderbook project, errors from the handleDeployment utility function are thrown to DeploymentSteps.svelte, which handles displaying the errors to the user through the DeploymentStepsError utility.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:33-49
Timestamp: 2025-03-28T10:35:36.699Z
Learning: The DeployButton component in the Rain Orderbook UI handles error validation before dispatching events, ensuring that event handlers like handleClickDeploy only receive valid event details with result, subgraphUrl, and networkKey properties.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check `if (dotrain && deployment)` inside `onMount` is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: packages/ui-components/src/lib/components/detail/TanstackOrderQuote.svelte:24-31
Timestamp: 2025-06-17T17:48:58.544Z
Learning: The project maintainer prefers not to use readonly modifiers on component props like rpcUrls: string[] even when they're not mutated, indicating a preference for simpler typing over stricter immutability enforcement in Svelte components.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1651
File: packages/ui-components/src/lib/components/TanstackAppTable.svelte:13-13
Timestamp: 2025-04-10T16:32:51.198Z
Learning: In the TanstackAppTable.svelte component, the queryKey prop should be required (type: string) rather than optional (string | undefined) to ensure proper query invalidation.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1882
File: packages/webapp/src/lib/components/DepositModal.svelte:35-35
Timestamp: 2025-06-07T09:14:33.054Z
Learning: When reviewing shared types in TypeScript, it's normal for individual components to only destructure and use a subset of the available properties from the type. Shared types like VaultActionArgs are designed to accommodate the union of all use cases across multiple components, not just a single component's requirements.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the `queryKey` property is intentionally declared in both `InternalTransactionArgs` and `TransactionArgs` types. This duplication should be kept as per the project's design preferences.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1750
File: packages/ui-components/src/lib/types/toast.ts:0-0
Timestamp: 2025-05-15T09:33:54.104Z
Learning: The ToastProps interface in packages/ui-components/src/lib/types/toast.ts intentionally keeps both `type` ('success', 'error', 'warning', 'info') and `color` ('green', 'red', 'yellow', 'blue') properties separate to maintain flexibility, even though they have a default one-to-one mapping.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: packages/ui-components/src/__tests__/VaultDetail.test.ts:177-181
Timestamp: 2025-07-04T09:14:35.748Z
Learning: In the rain.orderbook project, maintainer findolor is fine with mutating mock data directly in test files using @ts-expect-error comments, preferring this pragmatic approach over immutable patterns like spread operators for test data updates.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1705
File: packages/ui-components/src/lib/providers/registry/RegistryManager.ts:46-48
Timestamp: 2025-04-28T15:37:59.927Z
Learning: String concatenation is an acceptable style choice for error messages in this codebase, rather than template literals.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1831
File: packages/ui-components/src/lib/components/transactions/getStatusEmoji.ts:13-22
Timestamp: 2025-06-05T12:20:20.455Z
Learning: The user findolor prefers not to add test coverage for fallback cases in the getStatusEmoji function when using ts-pattern's .otherwise() method.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/ui-components/src/lib/providers/registry/RegistryManager.ts:43-49
Timestamp: 2025-04-14T07:57:31.996Z
Learning: For this repository, concatenated strings are preferred over template literals and are considered acceptable style, even when linters suggest otherwise.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/routes/deploy/+layout.svelte:12-16
Timestamp: 2025-04-09T09:59:04.121Z
Learning: In the Rain Orderbook application, a full page reload (window.location.reload()) is needed when changing the registry URL to ensure proper state reinitialization, rather than using SvelteKit's soft navigation methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:35-37
Timestamp: 2025-06-17T16:25:44.685Z
Learning: In the tauri-app Svelte application, users must navigate to a settings page to modify settings and then return to other pages. This navigation pattern causes page components to be recreated, which naturally refreshes component state derived from settings without requiring reactive statements ($:). Therefore, reactive statements for settings-derived values are unnecessary when the UX flow involves page navigation.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:33-37
Timestamp: 2025-04-08T16:35:15.127Z
Learning: In the Rain OrderBook project, the onDeposit and onWithdraw functions in page components are kept simple (just calling modal handlers and revalidating queries) because error handling for deposit and withdraw actions (including user cancellations and failed transactions) is handled within the modal components themselves.
packages/orderbook/test/js_api/gui.test.ts (37)
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: thedavidmeister
PR: #1926
File: test/concrete/ob/OrderBook.clear.zeroAmount.t.sol:24-32
Timestamp: 2025-06-16T10:49:47.770Z
Learning: LibTestAddOrder.conformConfig() in test/util/lib/LibTestAddOrder.sol automatically constrains OrderConfigV3 to prevent common test failures by ensuring validInputs[0].token != validOutputs[0].token, setting them to address(0) and address(1) respectively if they're equal. This prevents TokenSelfTrade errors in fuzz tests.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1916
File: packages/ui-components/src/lib/fixtures/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like string | null.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
</retrieved_learning>
<retrieved_learning>
Learnt from: brusherru
PR: #1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use enabled: true rather than Object.keys($activeSubgraphs).length > 0 because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1724
File: packages/ui-components/src/tests/ButtonDarkMode.test.ts:1-54
Timestamp: 2025-05-03T10:29:04.009Z
Learning: JSDoc comments are not considered necessary for test files in the rainlanguage/rain.orderbook repository. Test descriptions and assertions are sufficient documentation.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/tests/VaultDetail.test.ts:177-181
Timestamp: 2025-07-04T09:14:35.748Z
Learning: In the rain.orderbook project, maintainer findolor is fine with mutating mock data directly in test files using @ts-expect-error comments, preferring this pragmatic approach over immutable patterns like spread operators for test data updates.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1565
File: packages/webapp/src/routes/deploy/layout.test.ts:12-29
Timestamp: 2025-04-07T08:18:36.473Z
Learning: In test files for this project, hardingjam prefers to use custom mocks (such as for localStorage) rather than relying on environment-provided implementations, as this allows for spying on individual methods and having precise control over implementation details for more robust testing.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1700
File: tauri-app/src/lib/mocks/mockConfigSource.ts:17-20
Timestamp: 2025-04-28T10:58:15.675Z
Learning: In mock configuration files for testing purposes, such as mockConfigSource.ts, inconsistencies between referenced subgraphs and defined subgraphs may be intentional and acceptable for specific test scenarios.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the queryKey property is intentionally declared in both InternalTransactionArgs and TransactionArgs types. This duplication should be kept as per the project's design preferences.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1700
File: tauri-app/src/lib/mocks/mockConfigSource.ts:6-6
Timestamp: 2025-04-28T10:58:11.124Z
Learning: In mock data for testing in this codebase, it's acceptable to use URL placeholders like 'https://mainnet.infura.io/v3/YOUR-PROJECT-ID' as they clearly indicate the expected format for actual implementation.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/page.test.ts:68-69
Timestamp: 2025-06-17T16:28:19.664Z
Learning: In the tauri-app test files, the team is comfortable using single URLs in rpcs arrays for test mocks rather than multiple URLs, even when testing multi-RPC functionality. They don't consider this a coverage gap that needs to be addressed.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1597
File: packages/ui-components/src/tests/OrderDetail.test.ts:120-120
Timestamp: 2025-04-08T09:18:46.653Z
Learning: In test files for the Rain Orderbook project, it's acceptable to bypass TypeScript's strict typing using constructs like as unknown as [Type] to create simplified mock objects that don't need to implement the entire interface.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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 assertions to be intentional and not a test brittleness issue. The ordering of RPCs in tests should be preserved as specified.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1515
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/layout.test.ts:37-37
Timestamp: 2025-03-26T16:16:51.943Z
Learning: For Rain Orderbook projects, in test files, the preference is to use "as any" type assertions with per-line ESLint disable comments rather than creating dedicated types for test parameters.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1975
File: packages/orderbook/test/js_api/gui.test.ts:958-960
Timestamp: 2025-07-09T14:00:09.618Z
Learning: In test files for the rain.orderbook project, maintainer findolor prefers to keep hard-coded serialized state strings (like gzip/base64 blobs) rather than replacing them with semantic assertions or round-trip testing, even when the hard-coded approach may be more brittle to changes.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/tests/TransactionManager.test.ts:160-161
Timestamp: 2025-07-04T10:25:10.315Z
Learning: In the rain.orderbook project, maintainer findolor prefers to keep non-null assertions (!) in test files rather than replacing them with optional chaining (?.) as they are not needed for tests where the structure is controlled and known to exist.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1917
File: packages/webapp/src/tests/resetActiveOrderbookRef.test.ts:32-40
Timestamp: 2025-06-11T12:39:28.613Z
Learning: In this repository, the maintainer (findolor) is fine with using as any casts inside test files; such casts should not be flagged as issues.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1705
File: packages/webapp/src/routes/deploy/page.test.ts:80-81
Timestamp: 2025-04-28T15:38:30.561Z
Learning: For this codebase, explicit any type assertions are considered acceptable in test files, as confirmed by the repository owner.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1719
File: crates/common/src/dotrain_add_order_lsp.rs:129-207
Timestamp: 2025-05-08T09:39:37.167Z
Learning: In the dotrain add order lsp file tests, large test constants are acceptable and don't need to be broken down into smaller constants.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/components/transactions/getStatusEmoji.ts:13-22
Timestamp: 2025-06-05T12:20:20.455Z
Learning: The user findolor prefers not to add test coverage for fallback cases in the getStatusEmoji function when using ts-pattern's .otherwise() method.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1876
File: packages/webapp/src/lib/services/resetActiveOrderbookRef.ts:19-20
Timestamp: 2025-05-20T15:15:01.333Z
Learning: In the Rain orderbook project, there is no preferred orderbook when resetting the active orderbook reference, so selecting the first available one (even with non-deterministic object key ordering) is acceptable.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check if (dotrain && deployment) inside onMount is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1687
File: crates/js_api/src/gui/order_operations.rs:470-489
Timestamp: 2025-04-29T11:17:46.178Z
Learning: In the get_deployment_transaction_args method of DotrainOrderGui, approvals are intentionally only checked against output tokens as per the design requirements.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1493
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:33-49
Timestamp: 2025-03-28T10:35:36.699Z
Learning: The DeployButton component in the Rain Orderbook UI handles error validation before dispatching events, ensuring that event handlers like handleClickDeploy only receive valid event details with result, subgraphUrl, and networkKey properties.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
crates/js_api/src/gui/select_tokens.rs (15)
Learnt from: thedavidmeister
PR: rainlanguage/rain.orderbook#1926
File: test/concrete/ob/OrderBook.clear.zeroAmount.t.sol:24-32
Timestamp: 2025-06-16T10:49:47.770Z
Learning: LibTestAddOrder.conformConfig() in test/util/lib/LibTestAddOrder.sol automatically constrains OrderConfigV3 to prevent common test failures by ensuring validInputs[0].token != validOutputs[0].token, setting them to address(0) and address(1) respectively if they're equal. This prevents TokenSelfTrade errors in fuzz tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/mod.rs:116-135
Timestamp: 2025-07-04T10:26:24.289Z
Learning: In crates/common/src/raindex_client/mod.rs, the get_multi_subgraph_args method intentionally treats Some(empty vector) the same as None for chain_ids parameter. Both cases should return all networks to support UI behavior where no selection or empty selection means "show all networks". Only when specific chain IDs are provided should the results be filtered.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1706
File: crates/quote/src/js_api/mod.rs:57-61
Timestamp: 2025-04-29T06:19:15.446Z
Learning: In the rain.orderbook codebase, the `get_id` function is designed to use `U256::from_str()` rather than `U256::from_hex()` for parsing order hashes, despite the potential for hex string inputs.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/gui/state_management.rs:412-412
Timestamp: 2025-07-09T14:00:12.206Z
Learning: In crates/js_api/src/gui/state_management.rs tests, findolor prefers to keep hard-coded serialized state constants (like SERIALIZED_STATE) rather than dynamically generating them, even when it may make tests more brittle to maintain.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/state_management.rs:32-35
Timestamp: 2025-04-29T11:19:41.267Z
Learning: The team prefers the `get_dotrain_hash` function to accept owned String parameters instead of string references, even though it may result in additional allocations during serialization/deserialization.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1713
File: crates/settings/src/remote/chains/mod.rs:43-226
Timestamp: 2025-05-13T20:06:22.602Z
Learning: When writing tests for collections of complex objects in Rust, prefer item-by-item comparison over direct vector comparison to get more specific error messages that pinpoint exactly which item and field has a mismatch.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/cli/src/transaction.rs:105-105
Timestamp: 2025-06-17T17:38:21.943Z
Learning: In Rust, Vec<String> can be compared with Vec<&str> using assert_eq! because Vec<T> implements PartialEq<Vec<U>> when T: PartialEq<U>, and String implements PartialEq<&str>. This means comparisons like assert_eq!(vec_of_strings, vec!["string_literal"]) work correctly without needing to convert string literals to String.
crates/settings/src/remote/tokens.rs (4)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/remote_tokens.rs:32-57
Timestamp: 2025-04-07T09:51:52.614Z
Learning: The implementation for remote token fetching in `crates/settings/src/remote_tokens.rs` does not include explicit timeouts/retries, as the team considers the current implementation sufficient for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1463
File: crates/settings/src/yaml/context.rs:298-304
Timestamp: 2025-03-28T10:09:10.696Z
Learning: In the `resolve_token_path` method of the Context implementation in `crates/settings/src/yaml/context.rs`, when an unknown property is accessed on a token, it returns a `ContextError::InvalidPath` error, not a `ContextError::PropertyNotFound` error.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/remote_networks.rs:40-75
Timestamp: 2025-04-03T09:45:04.200Z
Learning: The RemoteNetworksCfg implementation in crates/settings/src/remote_networks.rs intentionally fetches remote networks sequentially rather than in parallel.
packages/webapp/src/lib/constants.ts (5)
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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: hardingjam
PR: rainlanguage/rain.orderbook#1705
File: packages/ui-components/src/lib/providers/registry/RegistryManager.ts:123-137
Timestamp: 2025-05-09T12:28:36.931Z
Learning: Handling relative URLs in the `updateUrlWithRegistry` method of the RegistryManager class is not a requirement for the registry URL management system.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/routes/deploy/+layout.svelte:12-16
Timestamp: 2025-04-09T09:59:04.121Z
Learning: In the Rain Orderbook application, a full page reload (window.location.reload()) is needed when changing the registry URL to ensure proper state reinitialization, rather than using SvelteKit's soft navigation methods.
packages/ui-components/src/__tests__/DeploymentSteps.test.ts (19)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#1594
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-04-05T13:16:58.971Z
Learning: In the DeploymentSteps component, the `checkingDeployment` state variable should be reset to false both after successful operations and error cases to ensure the deploy button returns to its normal state.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/order_operations.rs:470-489
Timestamp: 2025-04-29T11:17:46.178Z
Learning: In the `get_deployment_transaction_args` method of `DotrainOrderGui`, approvals are intentionally only checked against output tokens as per the design requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1559
File: packages/ui-components/src/__tests__/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., `as unknown as SgVault`) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/routes/deploy/layout.test.ts:12-29
Timestamp: 2025-04-07T08:18:36.473Z
Learning: In test files for this project, hardingjam prefers to use custom mocks (such as for localStorage) rather than relying on environment-provided implementations, as this allows for spying on individual methods and having precise control over implementation details for more robust testing.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like `packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json`, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like `string | null`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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().
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1597
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:120-120
Timestamp: 2025-04-08T09:18:46.653Z
Learning: In test files for the Rain Orderbook project, it's acceptable to bypass TypeScript's strict typing using constructs like `as unknown as [Type]` to create simplified mock objects that don't need to implement the entire interface.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1516
File: packages/webapp/src/routes/deploy/[strategyName]/layout.test.ts:0-0
Timestamp: 2025-03-26T15:00:17.997Z
Learning: For Rain Orderbook projects, there's a preference not to include tests for SvelteKit methods (like parent function rejections) in test files, as these are considered framework responsibilities rather than application code that needs testing.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/page.test.ts:68-69
Timestamp: 2025-06-17T16:28:19.664Z
Learning: In the tauri-app test files, the team is comfortable using single URLs in rpcs arrays for test mocks rather than multiple URLs, even when testing multi-RPC functionality. They don't consider this a coverage gap that needs to be addressed.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check `if (dotrain && deployment)` inside `onMount` is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
🧬 Code Graph Analysis (1)
crates/js_api/src/gui/select_tokens.rs (1)
crates/common/src/erc20.rs (3)
decimals(50-66)name(68-84)symbol(86-102)
🔇 Additional comments (19)
crates/common/src/raindex_client/add_orders.rs (1)
90-94: Imports in test module look correct
U256andFromStrare required later in the assertions; keeping them avoids
warning-as-error builds. No action needed.packages/webapp/src/lib/constants.ts (1)
1-3: Verify new registry commit hashThe hard-coded
REGISTRY_URLnow pins commitdb69cfa....
Please confirm the commit exists and the file layout hasn’t changed to prevent 404s at runtime.packages/orderbook/test/js_api/gui.test.ts (2)
1989-1996: LGTM! Test assertions correctly updated for new token ordering.The test assertions have been properly updated to reflect the new token sorting logic by lowercase address. The expected order now correctly places
0x6666...6666before0x8888...8888, which aligns with the backend changes.
2034-2034: LGTM! Property name corrected to match backend schema.The
logoUriproperty has been correctly updated tologoURI(capitalized "URI") to align with the backend serialization annotations. This ensures consistency between the test mocks and the actual API schema.Also applies to: 2134-2134, 2190-2190
crates/js_api/src/gui/select_tokens.rs (2)
311-319: LGTM! Improved token ordering and deduplication logic.The change from name-based to address-based sorting provides more consistent token ordering, and the addition of deduplication by address prevents duplicate tokens in the results. The case-insensitive comparison handles address checksum variations correctly.
562-571: Test assertions correctly updated for new token ordering.The test assertions have been properly updated to reflect the address-based sorting, ensuring the tests verify the correct token properties at each position.
crates/js_api/src/gui/mod.rs (3)
22-26: Appropriate imports for the new helper function.The new imports for
Arc,RwLock, andStrictYamlare correctly added to support theget_yaml_documentshelper function.
105-106: Excellent refactoring to eliminate code duplication.The refactoring of three static methods to use the shared
get_yaml_documentshelper eliminates duplicate YAML parsing logic and improves maintainability. This is more efficient than creating fullDotrainOrderinstances just to access YAML documents.Also applies to: 407-408, 446-447
594-600: Well-implemented helper function with proper error handling.The
get_yaml_documentshelper function correctly extracts YAML frontmatter and creates aDotrainYamlinstance. The use ofunwrap_or("")for missing frontmatter allows downstream validation to handle empty content appropriately, which aligns with the codebase's error handling patterns.packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte (3)
58-59: LGTM: Clean state management for token loadingThe new reactive state variables are well-named and properly initialized. The separation of concerns between
availableTokensfor the data andloadingTokensfor the UI state is appropriate.
81-97: Excellent async function implementation with proper safeguardsThe
loadAvailableTokensfunction demonstrates solid patterns:
- Concurrent execution prevention with the loading guard
- Proper error handling with specific error codes
- Guaranteed state cleanup in the finally block
- Appropriate fallback to empty array on error
The implementation aligns well with the existing error handling patterns in the codebase.
221-221: Props integration looks goodThe SelectToken component correctly receives both the available tokens data and loading state, enabling proper UI feedback during token fetching.
crates/settings/src/remote_tokens.rs (2)
44-63: Solid deduplication strategy with proper conflict detectionThe HashMap-based deduplication by
(chain_id, lowercase_address)effectively prevents duplicate tokens while maintaining the most recent version from the token lists. The conflict detection for duplicate token keys provides good error handling for edge cases.The integration with the updated
try_into_token_cfgmethod that returnsOption<TokenCfg>allows graceful handling of tokens without matching networks.
289-291: Updated token key format aligns with new schemaThe new token key format
{network-key}-{token-name}-{lowercase-address}provides better uniqueness guarantees and more descriptive identifiers. The test updates correctly reflect this change.Also applies to: 299-301, 466-468, 476-478
crates/settings/src/remote/tokens.rs (2)
38-39: Correct serde field mapping for JSON compatibilityThe
#[serde(rename = "logoURI")]annotation properly maps the Rust field name to the expected JSON field name, maintaining consistency with the token list API standards.
47-72: Well-designed method signature change for flexible token processingThe updated
try_into_token_cfgmethod signature returningResult<Option<TokenCfg>, RemoteTokensError>elegantly handles the case where tokens don't have matching networks by returningOk(None)instead of erroring. This allows the caller to filter out such tokens gracefully.The new token key format
{network-key}-{token-name}-{lowercase-address}provides better uniqueness and traceability.packages/ui-components/src/__tests__/DeploymentSteps.test.ts (3)
115-130: Comprehensive mock updates support new functionalityThe enhanced mock implementation properly covers:
getAllTokenswith realistic token data structuregetTokenInforeturning resolved promisesremoveSelectTokenfor token removal scenariosThe mock data structure matches the expected API responses.
Also applies to: 137-144, 147-147
436-598: Excellent test coverage for token loading functionalityThe test suite comprehensively covers all critical scenarios:
- Basic token loading on component mount
- Error handling for both API errors and network failures
- Loading state management and UI feedback
- Concurrent execution prevention
- Integration with SelectToken components
The tests use realistic scenarios and proper async handling patterns, ensuring the component behaves correctly under various conditions.
344-383: Test interactions updated for new UI elementsThe test correctly adapts to the new SelectToken component structure, using appropriate test IDs and element selectors for the dual-mode (dropdown/custom input) token selection interface.
| NO_GUI_DETAILS = 'Error getting GUI details', | ||
| NO_CHAIN = 'Unsupported chain ID', | ||
| NO_NETWORK_KEY = 'No network key found', | ||
| NO_AVAILABLE_TOKENS = 'Error loading available tokens', |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Potentially confusing duplicate error codes
NO_AVAILABLE_TOKENS and the pre-existing NO_SELECT_TOKENS both map to token-loading failures.
Consider merging them or clarifying the distinction to avoid ambiguous error handling downstream.
🤖 Prompt for AI Agents
In packages/ui-components/src/lib/errors/DeploymentStepsError.ts at line 16, the
error codes NO_AVAILABLE_TOKENS and NO_SELECT_TOKENS both represent
token-loading failures, which can cause confusion. Review the usage contexts of
both error codes and either merge them into a single, clearly named error code
or update their messages to distinctly reflect different failure scenarios.
Ensure that downstream error handling can unambiguously differentiate between
these cases.
There was a problem hiding this comment.
those are two different things
There was a problem hiding this comment.
@findolor Got it! I understand that NO_SELECT_TOKENS and NO_AVAILABLE_TOKENS serve different purposes in the token loading workflow. Thank you for the clarification - I'll keep them as separate error codes.
✏️ Learnings added
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.429Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/utils/handleDeployment.ts:10-43
Timestamp: 2025-04-04T09:56:04.949Z
Learning: In the rain.orderbook project, errors from the handleDeployment utility function are thrown to DeploymentSteps.svelte, which handles displaying the errors to the user through the DeploymentStepsError utility.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:33-49
Timestamp: 2025-03-28T10:35:36.699Z
Learning: The DeployButton component in the Rain Orderbook UI handles error validation before dispatching events, ensuring that event handlers like handleClickDeploy only receive valid event details with result, subgraphUrl, and networkKey properties.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1594
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-04-05T13:16:58.971Z
Learning: In the DeploymentSteps component, the `checkingDeployment` state variable should be reset to false both after successful operations and error cases to ensure the deploy button returns to its normal state.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the `queryKey` property is intentionally declared in both `InternalTransactionArgs` and `TransactionArgs` types. This duplication should be kept as per the project's design preferences.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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: rouzwelt
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T23:34:42.328Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must use the format:
TOTAL:number
ADDITIONS:number
DELETIONS:number
with no extra text, formatting blocks, or explanations, and must still exclude lock files and reassess after each new commit.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
crates/js_api/src/gui/select_tokens.rs (1)
311-319: Address-based sorting and deduplication implementation looks correct.The sorting logic change from name-based to address-based sorting is implemented correctly, and the deduplication logic properly removes duplicate addresses using case-insensitive comparison.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (9)
crates/js_api/src/gui/mod.rs(5 hunks)crates/js_api/src/gui/select_tokens.rs(2 hunks)crates/settings/src/remote_tokens.rs(7 hunks)packages/orderbook/test/js_api/gui.test.ts(4 hunks)packages/ui-components/src/__tests__/DeploymentSteps.test.ts(6 hunks)packages/ui-components/src/__tests__/SelectToken.test.ts(9 hunks)packages/ui-components/src/lib/components/deployment/SelectToken.svelte(3 hunks)packages/webapp/src/lib/constants.ts(1 hunks)packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/fullDeployment.test.ts(3 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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: rouzwelt
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#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: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T23:34:42.328Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must use the format:
TOTAL:number
ADDITIONS:number
DELETIONS:number
with no extra text, formatting blocks, or explanations, and must still exclude lock files and reassess after each new commit.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
crates/js_api/src/gui/select_tokens.rs (16)
Learnt from: thedavidmeister
PR: rainlanguage/rain.orderbook#1926
File: test/concrete/ob/OrderBook.clear.zeroAmount.t.sol:24-32
Timestamp: 2025-06-16T10:49:47.770Z
Learning: LibTestAddOrder.conformConfig() in test/util/lib/LibTestAddOrder.sol automatically constrains OrderConfigV3 to prevent common test failures by ensuring validInputs[0].token != validOutputs[0].token, setting them to address(0) and address(1) respectively if they're equal. This prevents TokenSelfTrade errors in fuzz tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.491Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/mod.rs:116-135
Timestamp: 2025-07-04T10:26:24.289Z
Learning: In crates/common/src/raindex_client/mod.rs, the get_multi_subgraph_args method intentionally treats Some(empty vector) the same as None for chain_ids parameter. Both cases should return all networks to support UI behavior where no selection or empty selection means "show all networks". Only when specific chain IDs are provided should the results be filtered.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1706
File: crates/quote/src/js_api/mod.rs:57-61
Timestamp: 2025-04-29T06:19:15.446Z
Learning: In the rain.orderbook codebase, the `get_id` function is designed to use `U256::from_str()` rather than `U256::from_hex()` for parsing order hashes, despite the potential for hex string inputs.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/gui/state_management.rs:412-412
Timestamp: 2025-07-09T14:00:12.206Z
Learning: In crates/js_api/src/gui/state_management.rs tests, findolor prefers to keep hard-coded serialized state constants (like SERIALIZED_STATE) rather than dynamically generating them, even when it may make tests more brittle to maintain.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1790
File: tauri-app/src-tauri/src/commands/vault.rs:67-67
Timestamp: 2025-05-17T15:32:28.733Z
Learning: For the PR focused on testing Tauri commands::order module, the generic type parameter R: Runtime was selectively added where needed for the PR scope, applying the changes primarily to order.rs and related files while leaving other modules like vault.rs for potential future refactoring.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/state_management.rs:32-35
Timestamp: 2025-04-29T11:19:41.267Z
Learning: The team prefers the `get_dotrain_hash` function to accept owned String parameters instead of string references, even though it may result in additional allocations during serialization/deserialization.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1713
File: crates/settings/src/remote/chains/mod.rs:43-226
Timestamp: 2025-05-13T20:06:22.602Z
Learning: When writing tests for collections of complex objects in Rust, prefer item-by-item comparison over direct vector comparison to get more specific error messages that pinpoint exactly which item and field has a mismatch.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/cli/src/transaction.rs:105-105
Timestamp: 2025-06-17T17:38:21.943Z
Learning: In Rust, Vec<String> can be compared with Vec<&str> using assert_eq! because Vec<T> implements PartialEq<Vec<U>> when T: PartialEq<U>, and String implements PartialEq<&str>. This means comparisons like assert_eq!(vec_of_strings, vec!["string_literal"]) work correctly without needing to convert string literals to String.
packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/fullDeployment.test.ts (20)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like `packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json`, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/order_operations.rs:470-489
Timestamp: 2025-04-29T11:17:46.178Z
Learning: In the `get_deployment_transaction_args` method of `DotrainOrderGui`, approvals are intentionally only checked against output tokens as per the design requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1594
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-04-05T13:16:58.971Z
Learning: In the DeploymentSteps component, the `checkingDeployment` state variable should be reset to false both after successful operations and error cases to ensure the deploy button returns to its normal state.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1688
File: packages/webapp/src/routes/layout.test.ts:1-139
Timestamp: 2025-04-23T12:10:03.847Z
Learning: When writing unit tests for UI components, focus on testing functional behavior rather than styling or CSS class names. Testing that UI frameworks like Tailwind work correctly is unnecessary and outside the scope of component unit tests.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like `string | null`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1913
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/fullDeployment.test.ts:170-171
Timestamp: 2025-06-06T16:39:13.240Z
Learning: In test files for packages/webapp, the user prefers not to add explicit error checking for factory method calls like DotrainOrderGui.chooseDeployment() when there's already higher-level error handling with try-catch blocks, as errors would be visible anyway and detailed error handling within test helper functions is not of interest.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1705
File: packages/webapp/src/routes/deploy/page.test.ts:80-81
Timestamp: 2025-04-28T15:38:30.561Z
Learning: For this codebase, explicit `any` type assertions are considered acceptable in test files, as confirmed by the repository owner.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1705
File: packages/ui-components/src/__tests__/InputRegistryUrl.test.ts:70-95
Timestamp: 2025-04-29T11:10:15.504Z
Learning: When testing time-dependent states like loading indicators in UI components, `userEvent.click()` is preferred over `fireEvent.click()` as it provides a more realistic simulation of user behavior, especially when used with fake timers.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1917
File: packages/webapp/src/__tests__/resetActiveOrderbookRef.test.ts:32-40
Timestamp: 2025-06-11T12:39:28.613Z
Learning: In this repository, the maintainer (findolor) is fine with using `as any` casts inside test files; such casts should not be flagged as issues.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
packages/orderbook/test/js_api/gui.test.ts (37)
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: thedavidmeister
PR: #1926
File: test/concrete/ob/OrderBook.clear.zeroAmount.t.sol:24-32
Timestamp: 2025-06-16T10:49:47.770Z
Learning: LibTestAddOrder.conformConfig() in test/util/lib/LibTestAddOrder.sol automatically constrains OrderConfigV3 to prevent common test failures by ensuring validInputs[0].token != validOutputs[0].token, setting them to address(0) and address(1) respectively if they're equal. This prevents TokenSelfTrade errors in fuzz tests.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1916
File: packages/ui-components/src/lib/fixtures/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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 assertions to be intentional and not a test brittleness issue. The ordering of RPCs in tests should be preserved as specified.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1559
File: packages/ui-components/src/tests/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., as unknown as SgVault) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like string | null.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/tests/VaultDetail.test.ts:177-181
Timestamp: 2025-07-04T09:14:35.748Z
Learning: In the rain.orderbook project, maintainer findolor is fine with mutating mock data directly in test files using @ts-expect-error comments, preferring this pragmatic approach over immutable patterns like spread operators for test data updates.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1724
File: packages/ui-components/src/tests/ButtonDarkMode.test.ts:1-54
Timestamp: 2025-05-03T10:29:04.009Z
Learning: JSDoc comments are not considered necessary for test files in the rainlanguage/rain.orderbook repository. Test descriptions and assertions are sufficient documentation.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1565
File: packages/webapp/src/routes/deploy/layout.test.ts:12-29
Timestamp: 2025-04-07T08:18:36.473Z
Learning: In test files for this project, hardingjam prefers to use custom mocks (such as for localStorage) rather than relying on environment-provided implementations, as this allows for spying on individual methods and having precise control over implementation details for more robust testing.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1700
File: tauri-app/src/lib/mocks/mockConfigSource.ts:17-20
Timestamp: 2025-04-28T10:58:15.675Z
Learning: In mock configuration files for testing purposes, such as mockConfigSource.ts, inconsistencies between referenced subgraphs and defined subgraphs may be intentional and acceptable for specific test scenarios.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/types/transaction.ts:76-84
Timestamp: 2025-06-05T12:21:33.969Z
Learning: In packages/ui-components/src/lib/types/transaction.ts, the queryKey property is intentionally declared in both InternalTransactionArgs and TransactionArgs types. This duplication should be kept as per the project's design preferences.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1700
File: tauri-app/src/lib/mocks/mockConfigSource.ts:6-6
Timestamp: 2025-04-28T10:58:11.124Z
Learning: In mock data for testing in this codebase, it's acceptable to use URL placeholders like 'https://mainnet.infura.io/v3/YOUR-PROJECT-ID' as they clearly indicate the expected format for actual implementation.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/page.test.ts:68-69
Timestamp: 2025-06-17T16:28:19.664Z
Learning: In the tauri-app test files, the team is comfortable using single URLs in rpcs arrays for test mocks rather than multiple URLs, even when testing multi-RPC functionality. They don't consider this a coverage gap that needs to be addressed.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1597
File: packages/ui-components/src/tests/OrderDetail.test.ts:120-120
Timestamp: 2025-04-08T09:18:46.653Z
Learning: In test files for the Rain Orderbook project, it's acceptable to bypass TypeScript's strict typing using constructs like as unknown as [Type] to create simplified mock objects that don't need to implement the entire interface.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1515
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/layout.test.ts:37-37
Timestamp: 2025-03-26T16:16:51.943Z
Learning: For Rain Orderbook projects, in test files, the preference is to use "as any" type assertions with per-line ESLint disable comments rather than creating dedicated types for test parameters.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1975
File: packages/orderbook/test/js_api/gui.test.ts:958-960
Timestamp: 2025-07-09T14:00:09.618Z
Learning: In test files for the rain.orderbook project, maintainer findolor prefers to keep hard-coded serialized state strings (like gzip/base64 blobs) rather than replacing them with semantic assertions or round-trip testing, even when the hard-coded approach may be more brittle to changes.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1956
File: packages/ui-components/src/tests/TransactionManager.test.ts:160-161
Timestamp: 2025-07-04T10:25:10.315Z
Learning: In the rain.orderbook project, maintainer findolor prefers to keep non-null assertions (!) in test files rather than replacing them with optional chaining (?.) as they are not needed for tests where the structure is controlled and known to exist.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1917
File: packages/webapp/src/tests/resetActiveOrderbookRef.test.ts:32-40
Timestamp: 2025-06-11T12:39:28.613Z
Learning: In this repository, the maintainer (findolor) is fine with using as any casts inside test files; such casts should not be flagged as issues.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1705
File: packages/webapp/src/routes/deploy/page.test.ts:80-81
Timestamp: 2025-04-28T15:38:30.561Z
Learning: For this codebase, explicit any type assertions are considered acceptable in test files, as confirmed by the repository owner.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1719
File: crates/common/src/dotrain_add_order_lsp.rs:129-207
Timestamp: 2025-05-08T09:39:37.167Z
Learning: In the dotrain add order lsp file tests, large test constants are acceptable and don't need to be broken down into smaller constants.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1831
File: packages/ui-components/src/lib/components/transactions/getStatusEmoji.ts:13-22
Timestamp: 2025-06-05T12:20:20.455Z
Learning: The user findolor prefers not to add test coverage for fallback cases in the getStatusEmoji function when using ts-pattern's .otherwise() method.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1876
File: packages/webapp/src/lib/services/resetActiveOrderbookRef.ts:19-20
Timestamp: 2025-05-20T15:15:01.333Z
Learning: In the Rain orderbook project, there is no preferred orderbook when resetting the active orderbook reference, so selecting the first available one (even with non-deterministic object key ordering) is acceptable.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check if (dotrain && deployment) inside onMount is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
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.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1687
File: crates/js_api/src/gui/order_operations.rs:470-489
Timestamp: 2025-04-29T11:17:46.178Z
Learning: In the get_deployment_transaction_args method of DotrainOrderGui, approvals are intentionally only checked against output tokens as per the design requirements.
</retrieved_learning>
<retrieved_learning>
Learnt from: hardingjam
PR: #1493
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:33-49
Timestamp: 2025-03-28T10:35:36.699Z
Learning: The DeployButton component in the Rain Orderbook UI handles error validation before dispatching events, ensuring that event handlers like handleClickDeploy only receive valid event details with result, subgraphUrl, and networkKey properties.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
PR: #1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
</retrieved_learning>
<retrieved_learning>
Learnt from: findolor
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.
</retrieved_learning>
crates/js_api/src/gui/mod.rs (21)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.491Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/mod.rs:258-259
Timestamp: 2025-04-22T12:50:39.581Z
Learning: In `DotrainOrderGui::generate_dotrain_text()`, the call to `.to_string()` on `self.dotrain_order.dotrain()` is necessary because there are two different implementations of the `dotrain()` method - one for WASM targets returning a String and one for non-WASM targets returning a &str. The `.to_string()` ensures type compatibility across different compilation targets.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-03-31T18:53:12.208Z
Learning: In the DotrainYaml struct, the cache field is kept public (`pub cache: Cache`) without additional getter methods, which is consistent with the existing design pattern in the codebase where other fields like `documents` are also public.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:37-44
Timestamp: 2025-03-31T14:36:11.049Z
Learning: The OrderbookYaml implementation in crates/js_api/src/yaml/mod.rs intentionally parses YAML on demand without caching results. This is a deliberate design choice by the author to process YAML only when needed rather than optimizing for repeated calls.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:31-34
Timestamp: 2025-03-31T13:57:59.660Z
Learning: The OrderbookYaml constructor in crates/js_api/src/yaml/mod.rs does not need early YAML validation. The author prefers to validate YAML only when it's actually used rather than during initialization.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-04-07T09:52:30.960Z
Learning: In the DotrainYaml struct, the newly added `cache` field is kept public without documentation, which the maintainer confirmed is acceptable for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/add_orders.rs:132-132
Timestamp: 2025-07-04T10:24:29.750Z
Learning: In the rain.orderbook codebase, findolor prefers to use `unwrap_or("")` for optional frontmatter in dotrain parsing, allowing empty strings to be handled by downstream validation in `NewConfig::try_from_yaml()` rather than adding explicit early validation checks at the extraction point.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:185-199
Timestamp: 2025-06-18T19:24:40.518Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers not to refactor get_orderbook_by_network_key to handle multiple orderbooks per network key since their current architecture maintains a one-to-one mapping between orderbooks and networks. They would consider the refactoring if the system evolves to support multiple orderbooks per network in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1950
File: crates/common/src/raindex_client/transactions.rs:34-38
Timestamp: 2025-06-24T13:30:02.968Z
Learning: When using #[wasm_bindgen] on an impl block, all methods within that block must have wasm_bindgen attributes, even if they are conditionally compiled for non-WASM targets using #[cfg(not(target_family = "wasm"))]. Removing these attributes causes compiler errors because the wasm_bindgen macro expansion processes the entire impl block and expects consistent attribute usage across all methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1744
File: crates/subgraph/src/orderbook_client.rs:44-46
Timestamp: 2025-05-14T05:13:59.713Z
Learning: In the rain.orderbook project, WASM dependencies are intentionally made available in non-WASM targets to facilitate testing of WASM-related functionality, so conditional compilation guards like `#[cfg(target_family = "wasm")]` should not be added to imports or implementations that may be needed for tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1874
File: tauri-app/src-tauri/src/transaction_status.rs:69-127
Timestamp: 2025-05-27T06:16:35.738Z
Learning: In tauri-app/src-tauri/src/transaction_status.rs, directly accessing internal RwLock state in tests using `notice.0.read().unwrap()` is acceptable and does not require encapsulation through public getter methods.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:23-25
Timestamp: 2025-04-07T09:50:54.715Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs returns cloned HashMaps in getter methods (like get_remote_networks) rather than references. This design choice was explicitly accepted by the maintainer.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1838
File: crates/cli/src/output.rs:29-41
Timestamp: 2025-05-19T07:14:24.219Z
Learning: For the rainlanguage/rain.orderbook repository, findolor prefers minimal documentation for straightforward functions like `output` in crates/cli/src/output.rs where the implementation is self-explanatory.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1599
File: crates/common/src/fuzz/impls.rs:91-113
Timestamp: 2025-04-11T05:55:22.504Z
Learning: Empty frontmatter validation is already handled in DotrainYaml::new through the YamlError::EmptyFile error when the yaml parser produces empty documents.
packages/ui-components/src/__tests__/DeploymentSteps.test.ts (19)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/order_operations.rs:470-489
Timestamp: 2025-04-29T11:17:46.178Z
Learning: In the `get_deployment_transaction_args` method of `DotrainOrderGui`, approvals are intentionally only checked against output tokens as per the design requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1594
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-04-05T13:16:58.971Z
Learning: In the DeploymentSteps component, the `checkingDeployment` state variable should be reset to false both after successful operations and error cases to ensure the deploy button returns to its normal state.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1559
File: packages/ui-components/src/__tests__/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., `as unknown as SgVault`) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like `string | null`.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/routes/deploy/layout.test.ts:12-29
Timestamp: 2025-04-07T08:18:36.473Z
Learning: In test files for this project, hardingjam prefers to use custom mocks (such as for localStorage) rather than relying on environment-provided implementations, as this allows for spying on individual methods and having precise control over implementation details for more robust testing.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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().
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like `packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json`, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1700
File: tauri-app/src/lib/mocks/mockConfigSource.ts:6-6
Timestamp: 2025-04-28T10:58:11.124Z
Learning: In mock data for testing in this codebase, it's acceptable to use URL placeholders like 'https://mainnet.infura.io/v3/YOUR-PROJECT-ID' as they clearly indicate the expected format for actual implementation.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1516
File: packages/webapp/src/routes/deploy/[strategyName]/layout.test.ts:0-0
Timestamp: 2025-03-26T15:00:17.997Z
Learning: For Rain Orderbook projects, there's a preference not to include tests for SvelteKit methods (like parent function rejections) in test files, as these are considered framework responsibilities rather than application code that needs testing.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: tauri-app/src/routes/orders/[network]-[orderHash]/page.test.ts:68-69
Timestamp: 2025-06-17T16:28:19.664Z
Learning: In the tauri-app test files, the team is comfortable using single URLs in rpcs arrays for test mocks rather than multiple URLs, even when testing multi-RPC functionality. They don't consider this a coverage gap that needs to be addressed.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check `if (dotrain && deployment)` inside `onMount` is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
packages/webapp/src/lib/constants.ts (5)
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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: hardingjam
PR: rainlanguage/rain.orderbook#1705
File: packages/ui-components/src/lib/providers/registry/RegistryManager.ts:123-137
Timestamp: 2025-05-09T12:28:36.931Z
Learning: Handling relative URLs in the `updateUrlWithRegistry` method of the RegistryManager class is not a requirement for the registry URL management system.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/routes/deploy/+layout.svelte:12-16
Timestamp: 2025-04-09T09:59:04.121Z
Learning: In the Rain Orderbook application, a full page reload (window.location.reload()) is needed when changing the registry URL to ensure proper state reinitialization, rather than using SvelteKit's soft navigation methods.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
packages/ui-components/src/lib/components/deployment/SelectToken.svelte (28)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/lib/components/deployment/DeployButton.svelte:0-0
Timestamp: 2025-03-31T14:01:19.067Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte is designed to be generic, dispatching clickDeploy events to be handled at the page level, where validation of event details (result, networkKey, subgraphUrl) occurs.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1493
File: packages/ui-components/src/__tests__/DeployButton.test.ts:36-40
Timestamp: 2025-03-28T10:22:11.771Z
Learning: The DeployButton component in packages/ui-components/src/lib/components/deployment/DeployButton.svelte doesn't have an explicit disabled prop. Instead, its disabled state is internally controlled by the checkingDeployment variable, which is set to true during deployment checks.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: packages/ui-components/src/lib/components/detail/TanstackOrderQuote.svelte:24-31
Timestamp: 2025-06-17T17:48:58.544Z
Learning: The project maintainer prefers not to use readonly modifiers on component props like rpcUrls: string[] even when they're not mutated, indicating a preference for simpler typing over stricter immutability enforcement in Svelte components.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1651
File: packages/ui-components/src/lib/components/TanstackAppTable.svelte:13-13
Timestamp: 2025-04-10T16:32:51.198Z
Learning: In the TanstackAppTable.svelte component, the queryKey prop should be required (type: string) rather than optional (string | undefined) to ensure proper query invalidation.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: packages/webapp/src/routes/orders/[network]-[orderHash]/+page.svelte:27-31
Timestamp: 2025-04-03T11:29:00.465Z
Learning: In Svelte applications with timer-based UI updates (like toast notifications), always store timer references and clear them when triggering new timers to prevent overlapping timers and unexpected UI behavior.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1566
File: packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/+page.svelte:26-31
Timestamp: 2025-04-02T08:11:19.742Z
Learning: In the Rain Orderbook deployment page component, the conditional check `if (dotrain && deployment)` inside `onMount` is necessary to prevent GUI initialization with null values, even though there's already a redirect logic outside the function and conditional rendering for the UI message. These serve different purposes in the component's error handling strategy.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1496
File: packages/webapp/src/lib/components/DepositOrWithdrawModal.svelte:164-164
Timestamp: 2025-03-22T21:11:34.405Z
Learning: The refactoring to replace signerAddress with account from useAccount hook is being done in stages - shared UI components first (PR #1496), with webapp-specific components to be handled in a separate future PR.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1891
File: packages/webapp/src/lib/services/handleAddOrder.ts:94-94
Timestamp: 2025-06-09T11:14:12.358Z
Learning: In the handleAddOrder function in packages/webapp/src/lib/services/handleAddOrder.ts, using an empty string fallback for undefined subgraphUrl is acceptable. When subgraphUrl is missing/empty, transaction indexing cannot be shown to the user, but the deployment functionality still works and users can manually navigate to the order page to view their deployed orders. This graceful degradation approach is preferred over making subgraphUrl required.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1883
File: packages/ui-components/src/lib/components/deployment/ButtonSelectOption.svelte:14-14
Timestamp: 2025-05-27T09:46:58.699Z
Learning: In Svelte components, there is no need to conditionally render data-testid attributes to handle empty values. Empty data-testid attributes are acceptable and don't require special handling.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1721
File: crates/js_api/src/bindings/mod.rs:1-131
Timestamp: 2025-05-01T14:39:53.795Z
Learning: Empty input validation for functions like `keccak256` and `get_order_hash` in the WebAssembly bindings is not required as empty inputs are considered valid in this context.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1615
File: packages/webapp/src/routes/deploy/+layout.ts:108-127
Timestamp: 2025-04-09T13:14:37.389Z
Learning: When testing functions with nullable return types in TypeScript (like `error: string | null`), explicit type assertions and null checks are sometimes necessary to satisfy TypeScript's type system, even if they appear redundant from a testing logic perspective.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1599
File: tauri-app/src/lib/components/modal/ModalScenarioDebug.svelte:10-16
Timestamp: 2025-04-11T06:07:10.456Z
Learning: Empty divs with CSS classes are used intentionally for styling and layout purposes in Svelte components in this codebase, even when they don't contain content.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like `string | null`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/settings/src/config.rs:287-288
Timestamp: 2025-06-17T16:57:25.456Z
Learning: In the rain.orderbook repository, validation for empty `rpcs` vectors in `NetworkConfigSource` is not required, as indicated by the maintainer findolor.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: tauri-app/src/lib/stores/walletconnect.ts:77-87
Timestamp: 2025-06-17T18:20:22.936Z
Learning: The project uses publicly known RPC providers, so security concerns about malicious or misconfigured RPC endpoints returning incorrect chain IDs are considered low priority.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/fuzz/mod.rs:64-64
Timestamp: 2025-07-04T09:02:57.301Z
Learning: In rainlanguage/rain.orderbook, user findolor prefers to limit type consistency changes to only the parts directly related to the current work scope. For example, when updating chain_id fields from u64 to u32 in fuzz-related code, unrelated files like tauri-app wallet commands can remain as u64 if they serve different purposes and aren't part of the current changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1983
File: crates/settings/src/gui.rs:965-973
Timestamp: 2025-07-11T08:37:24.400Z
Learning: In the rainlanguage/rain.orderbook project, user findolor prefers to keep user-facing error messages generic and user-friendly rather than technically specific. For example, using "a valid number" instead of "a valid u8 (0-255)" in GUI validation error messages to maintain simplicity for end users.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/common/src/deposit.rs:63-64
Timestamp: 2025-06-17T16:54:43.176Z
Learning: In the rain.orderbook codebase, the maintainer findolor prefers to keep the current implementation that clones the rpcs vector when calling ReadableClient::new_from_urls rather than optimizing it to avoid the clone or adding early validation for empty rpcs. Performance micro-optimizations like avoiding vector clones in this context are not a priority.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1983
File: crates/js_api/src/gui/deposits.rs:147-156
Timestamp: 2025-07-11T06:41:11.903Z
Learning: In the Rain OrderBook project, token info is already cached in the YAML file which serves as the source of truth, so the `get_token_info()` async method in the GUI SDK retrieves from pre-loaded/parsed data rather than making expensive network calls.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1504
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:39-43
Timestamp: 2025-04-08T16:35:41.663Z
Learning: In the Rain OrderBook application, the user has confirmed that error handling for withdrawal cancellations is handled in the modal tests, not in the page-level code, consistent with the architectural pattern where transaction-related error handling is centralized in modal components.
crates/settings/src/remote_tokens.rs (9)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/remote_tokens.rs:32-57
Timestamp: 2025-04-07T09:51:52.614Z
Learning: The implementation for remote token fetching in `crates/settings/src/remote_tokens.rs` does not include explicit timeouts/retries, as the team considers the current implementation sufficient for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/remote_networks.rs:40-75
Timestamp: 2025-04-03T09:45:04.200Z
Learning: The RemoteNetworksCfg implementation in crates/settings/src/remote_networks.rs intentionally fetches remote networks sequentially rather than in parallel.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1463
File: crates/settings/src/yaml/context.rs:298-304
Timestamp: 2025-03-28T10:09:10.696Z
Learning: In the `resolve_token_path` method of the Context implementation in `crates/settings/src/yaml/context.rs`, when an unknown property is accessed on a token, it returns a `ContextError::InvalidPath` error, not a `ContextError::PropertyNotFound` error.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:92-99
Timestamp: 2025-06-18T18:18:44.330Z
Learning: In crates/js_api/src/raindex/mod.rs, the get_subgraph_url_for_chain method and get_multi_subgraph_args method intentionally duplicate lookup logic because they serve different purposes: get_subgraph_url_for_chain returns only the URL string, while get_multi_subgraph_args returns MultiSubgraphArgs structures containing both URL and network information (name/label). This duplication is acceptable and by design.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/mod.rs:116-135
Timestamp: 2025-07-04T10:26:24.289Z
Learning: In crates/common/src/raindex_client/mod.rs, the get_multi_subgraph_args method intentionally treats Some(empty vector) the same as None for chain_ids parameter. Both cases should return all networks to support UI behavior where no selection or empty selection means "show all networks". Only when specific chain IDs are provided should the results be filtered.
Learnt from: 0xgleb
PR: rainlanguage/rain.orderbook#1859
File: crates/quote/src/quote_debug.rs:472-492
Timestamp: 2025-05-20T10:20:08.206Z
Learning: In the Rain Orderbook codebase, the `#[tokio::test(flavor = "multi_thread")]` annotation is specifically needed for tests that use `LocalEvm`, not just for consistency across all async tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:23-25
Timestamp: 2025-04-07T09:50:54.715Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs returns cloned HashMaps in getter methods (like get_remote_networks) rather than references. This design choice was explicitly accepted by the maintainer.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.491Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
packages/ui-components/src/__tests__/SelectToken.test.ts (25)
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/SelectToken.svelte:137-151
Timestamp: 2025-06-18T16:44:14.948Z
Learning: In the SelectToken.svelte component, the SDK validates addresses before making RPC calls, so calling saveTokenSelection on every keystroke in handleInput doesn't result in network calls until there's a full valid address.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1575
File: packages/webapp/src/routes/deploy/layout.test.ts:96-99
Timestamp: 2025-04-08T11:46:05.879Z
Learning: In TypeScript tests, seemingly redundant assertions like explicitly checking a property after a full object assertion may be necessary for proper type narrowing, especially when dealing with union types like `string | null`.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1688
File: packages/webapp/src/routes/layout.test.ts:1-139
Timestamp: 2025-04-23T12:10:03.847Z
Learning: When writing unit tests for UI components, focus on testing functional behavior rather than styling or CSS class names. Testing that UI frameworks like Tailwind work correctly is unnecessary and outside the scope of component unit tests.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1669
File: packages/webapp/src/routes/+layout.ts:82-261
Timestamp: 2025-04-15T12:35:56.008Z
Learning: When testing Svelte applications, focus on application logic rather than testing Svelte's built-in reactive store system. Testing framework functionality (like Svelte's store reactivity) is generally unnecessary in application tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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().
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1516
File: packages/webapp/src/routes/deploy/[strategyName]/layout.test.ts:0-0
Timestamp: 2025-03-26T15:00:17.997Z
Learning: For Rain Orderbook projects, there's a preference not to include tests for SvelteKit methods (like parent function rejections) in test files, as these are considered framework responsibilities rather than application code that needs testing.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/routes/deploy/layout.test.ts:12-29
Timestamp: 2025-04-07T08:18:36.473Z
Learning: In test files for this project, hardingjam prefers to use custom mocks (such as for localStorage) rather than relying on environment-provided implementations, as this allows for spying on individual methods and having precise control over implementation details for more robust testing.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1705
File: packages/ui-components/src/__tests__/InputRegistryUrl.test.ts:70-95
Timestamp: 2025-04-29T11:10:15.504Z
Learning: When testing time-dependent states like loading indicators in UI components, `userEvent.click()` is preferred over `fireEvent.click()` as it provides a more realistic simulation of user behavior, especially when used with fake timers.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1597
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:120-120
Timestamp: 2025-04-08T09:18:46.653Z
Learning: In test files for the Rain Orderbook project, it's acceptable to bypass TypeScript's strict typing using constructs like `as unknown as [Type]` to create simplified mock objects that don't need to implement the entire interface.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1559
File: packages/ui-components/src/__tests__/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., `as unknown as SgVault`) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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: thedavidmeister
PR: rainlanguage/rain.orderbook#1926
File: test/concrete/ob/OrderBook.clear.zeroAmount.t.sol:24-32
Timestamp: 2025-06-16T10:49:47.770Z
Learning: LibTestAddOrder.conformConfig() in test/util/lib/LibTestAddOrder.sol automatically constrains OrderConfigV3 to prevent common test failures by ensuring validInputs[0].token != validOutputs[0].token, setting them to address(0) and address(1) respectively if they're equal. This prevents TokenSelfTrade errors in fuzz tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: packages/ui-components/src/__tests__/VaultDetail.test.ts:177-181
Timestamp: 2025-07-04T09:14:35.748Z
Learning: In the rain.orderbook project, maintainer findolor is fine with mutating mock data directly in test files using @ts-expect-error comments, preferring this pragmatic approach over immutable patterns like spread operators for test data updates.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1700
File: tauri-app/src/lib/mocks/mockConfigSource.ts:17-20
Timestamp: 2025-04-28T10:58:15.675Z
Learning: In mock configuration files for testing purposes, such as mockConfigSource.ts, inconsistencies between referenced subgraphs and defined subgraphs may be intentional and acceptable for specific test scenarios.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/__tests__/registryManager.test.ts:20-21
Timestamp: 2025-04-09T09:40:03.131Z
Learning: When mocking browser APIs like localStorage for tests, it's not always necessary to fully implement all interface properties/methods with dynamic behavior. A hardcoded value (like setting length: 0) can be sufficient when the tests don't rely on that specific property.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1874
File: tauri-app/src-tauri/src/transaction_status.rs:116-127
Timestamp: 2025-05-27T06:17:47.701Z
Learning: Tauri's mock application (tauri::test::mock_app()) in tauri-app/src-tauri does not support testing emitted events, making it impossible to verify that emit_all calls work correctly in unit tests.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
🔇 Additional comments (22)
packages/webapp/src/lib/constants.ts (1)
1-2: Registry URL update looks good.The commit hash update to point to the latest registry data is appropriate and maintains the correct URL format.
crates/js_api/src/gui/select_tokens.rs (1)
562-571: Test updates correctly reflect the new sorting behavior.The test assertions have been properly updated to match the new address-based sorting order, verifying that tokens are now ordered by their addresses rather than names.
packages/orderbook/test/js_api/gui.test.ts (2)
2001-2008: Possible typo:"Teken 2"
Token 2appears everywhere else in the mocks and assertions, but these lines expect"Teken 2".
Unless the miss-spelling is deliberate (e.g. to distinguish a remote-token variant), this will silently mask genuine regressions.-assert.equal(allTokens[1].name, 'Teken 2'); +assert.equal(allTokens[1].name, 'Token 2');Double-check the upstream YAML / RPC responses and adjust the assertion or fixture accordingly.
2046-2046:logoURIcasing fixed – looks goodThe field name now matches the Serde rename (
logoURI) used in Rust; this will keep the JSON mocks in sync with runtime parsing.Also applies to: 2146-2146, 2202-2202
crates/settings/src/remote_tokens.rs (3)
1-1: Good addition of Token importThe import is correctly updated to include the
Tokentype needed for the new deduplication logic.
245-245: Correct JSON field name standardizationThe change from
"logoUri"to"logoURI"aligns with the updated field annotation in theTokensstruct, ensuring consistent JSON serialization/deserialization.Also applies to: 355-355, 385-385
289-291: Test assertions updated correctlyThe test assertions now use the full composite key format (e.g.,
"remote-network-Token1-0x0000000000000000000000000000000000000001"), which correctly reflects the new token key generation logic.Also applies to: 299-301, 464-466, 474-476
crates/js_api/src/gui/mod.rs (2)
22-26: Appropriate imports for the new helper functionThe imports for
Arc,RwLock, andStrictYamlare correctly added to support the newget_yaml_documentshelper function.
105-106: Excellent refactoring to avoid unnecessary DotrainOrder creationThe refactoring of these three methods to use the new
get_yaml_documentshelper is well-designed. This avoids the overhead of creatingDotrainOrderinstances when only YAML parsing is needed, improving performance for these static utility methods.Also applies to: 407-408, 446-447
packages/webapp/src/routes/deploy/[strategyName]/[deploymentKey]/fullDeployment.test.ts (2)
149-162: Token selection test updates align with new dropdown UI.The test correctly simulates the new user flow: waiting for GUI load, clicking dropdown buttons, and selecting tokens from the list. This properly validates the enhanced token selection experience.
265-286: Consistent test pattern maintained across all strategies.Good job maintaining consistency in how token selection is tested across the Fixed limit, Auction, and Dynamic spread strategies. The uniform approach makes the tests easier to understand and maintain.
packages/ui-components/src/__tests__/DeploymentSteps.test.ts (2)
115-130: Well-structured mock data for token testing.The mock tokens provide good variety with different addresses and decimals, which helps ensure the component handles various token configurations correctly.
434-597: Comprehensive test coverage for token loading functionality.Excellent coverage of all token loading scenarios including:
- Success cases with proper token display
- Error handling (both resolved errors and rejected promises)
- Loading state management
- Race condition prevention
- Edge cases with empty token lists
The tests properly validate the component's robustness.
packages/ui-components/src/lib/components/deployment/SelectToken.svelte (5)
13-14: Clean prop interface for token availability.Good design choice to pass
availableTokensandloadingas props, allowing parent components to manage the token fetching logic while this component focuses on the selection UI.
41-56: Excellent reactive state management.The reactive statement properly syncs the selected token with available tokens and automatically switches to custom mode when the current token isn't in the list. This provides a seamless user experience.
57-87: Well-structured mode switching logic.The
setModefunction cleanly handles all state transitions between dropdown and custom modes, properly clearing or preserving state as appropriate. The edge case handling for tokens not in the available list is particularly well done.
99-112: Robust error handling in token selection.Good implementation with proper try-catch-finally pattern ensuring the loading state is cleared and the callback is triggered regardless of success or failure.
190-210: Clean conditional rendering based on mode and availability.The UI properly adapts based on token availability and loading state, providing appropriate fallbacks when tokens aren't available. The integration with TokenSelectionModal is seamless.
packages/ui-components/src/__tests__/SelectToken.test.ts (4)
32-45: Well-designed mock token data.The mock tokens provide good test coverage with realistic addresses and varying decimal places, ensuring the component handles different token configurations correctly.
192-208: Excellent edge case coverage.Great test for automatic mode switching when the selected token isn't in the available tokens list. This ensures the component gracefully handles tokens that may have been removed or aren't available in the current context.
210-385: Comprehensive dropdown mode test suite.Excellent organization with a dedicated describe block for dropdown functionality. The tests thoroughly cover:
- UI element visibility based on token availability
- Mode switching and active state indication
- State clearing on mode transitions
- Token selection from dropdown
- Loading state display
- Fallback to custom mode when no tokens available
This provides confidence in the dropdown implementation's robustness.
259-293: Thorough state management verification.Excellent tests for verifying that state is properly cleared when switching between modes. The tests ensure
unsetSelectTokenis called appropriately, preventing stale token selections from persisting across mode changes.
| let mut unique_tokens: HashMap<(u32, String), Token> = HashMap::new(); | ||
| for token in &tokens_res.tokens { | ||
| let token_cfg = token | ||
| .clone() | ||
| .try_into_token_cfg(networks, remote_tokens.document.clone())?; | ||
| let token_id = (token.chain_id, token.address.to_lowercase()); | ||
| unique_tokens.insert(token_id, token.clone()); | ||
| } | ||
|
|
||
| if tokens.contains_key(&token_cfg.key) { | ||
| return Err(ParseRemoteTokensError::ConflictingTokens( | ||
| token_cfg.key.clone(), | ||
| )); | ||
| for token in unique_tokens.values() { | ||
| if let Some(token_cfg) = token | ||
| .clone() | ||
| .try_into_token_cfg(networks, remote_tokens.document.clone())? | ||
| { | ||
| if tokens.contains_key(&token_cfg.key) { | ||
| return Err(ParseRemoteTokensError::ConflictingTokens( | ||
| token_cfg.key.clone(), | ||
| )); | ||
| } | ||
| tokens.insert(token_cfg.key.clone(), token_cfg); | ||
| } | ||
| tokens.insert(token_cfg.key.clone(), token_cfg); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Excellent token deduplication implementation
The deduplication logic correctly identifies unique tokens by (chain_id, lowercase_address) and handles conflicts appropriately. The approach of collecting unique tokens first, then processing them, ensures no duplicate tokens are processed.
Consider a minor performance optimization to avoid cloning tokens:
- for token in unique_tokens.values() {
- if let Some(token_cfg) = token
- .clone()
- .try_into_token_cfg(networks, remote_tokens.document.clone())?
+ for token in unique_tokens.into_values() {
+ if let Some(token_cfg) = token
+ .try_into_token_cfg(networks, remote_tokens.document.clone())?This avoids cloning tokens during iteration by consuming the HashMap.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let mut unique_tokens: HashMap<(u32, String), Token> = HashMap::new(); | |
| for token in &tokens_res.tokens { | |
| let token_cfg = token | |
| .clone() | |
| .try_into_token_cfg(networks, remote_tokens.document.clone())?; | |
| let token_id = (token.chain_id, token.address.to_lowercase()); | |
| unique_tokens.insert(token_id, token.clone()); | |
| } | |
| if tokens.contains_key(&token_cfg.key) { | |
| return Err(ParseRemoteTokensError::ConflictingTokens( | |
| token_cfg.key.clone(), | |
| )); | |
| for token in unique_tokens.values() { | |
| if let Some(token_cfg) = token | |
| .clone() | |
| .try_into_token_cfg(networks, remote_tokens.document.clone())? | |
| { | |
| if tokens.contains_key(&token_cfg.key) { | |
| return Err(ParseRemoteTokensError::ConflictingTokens( | |
| token_cfg.key.clone(), | |
| )); | |
| } | |
| tokens.insert(token_cfg.key.clone(), token_cfg); | |
| } | |
| tokens.insert(token_cfg.key.clone(), token_cfg); | |
| } | |
| let mut unique_tokens: HashMap<(u32, String), Token> = HashMap::new(); | |
| for token in &tokens_res.tokens { | |
| let token_id = (token.chain_id, token.address.to_lowercase()); | |
| unique_tokens.insert(token_id, token.clone()); | |
| } | |
| for token in unique_tokens.into_values() { | |
| if let Some(token_cfg) = token | |
| .try_into_token_cfg(networks, remote_tokens.document.clone())? | |
| { | |
| if tokens.contains_key(&token_cfg.key) { | |
| return Err(ParseRemoteTokensError::ConflictingTokens( | |
| token_cfg.key.clone(), | |
| )); | |
| } | |
| tokens.insert(token_cfg.key.clone(), token_cfg); | |
| } | |
| } |
🤖 Prompt for AI Agents
In crates/settings/src/remote_tokens.rs around lines 44 to 62, the current code
clones tokens when iterating over unique_tokens.values(), which is unnecessary
and impacts performance. To fix this, change the iteration to consume the
HashMap by iterating over unique_tokens.into_values() instead of
unique_tokens.values(), so tokens are moved rather than cloned. This avoids
cloning tokens during processing and improves efficiency.
There was a problem hiding this comment.
we don't need to implement this
There was a problem hiding this comment.
@findolor You're absolutely right - that optimization is outside the scope of this PR. Thanks for keeping the focus on the token dropdown implementation!
The deduplication logic you've implemented here works well for supporting the new token selection UI.
🧠 Learnings used
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/remote_tokens.rs:32-57
Timestamp: 2025-04-07T09:51:52.614Z
Learning: The implementation for remote token fetching in `crates/settings/src/remote_tokens.rs` does not include explicit timeouts/retries, as the team considers the current implementation sufficient for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/remote_networks.rs:40-75
Timestamp: 2025-04-03T09:45:04.200Z
Learning: The RemoteNetworksCfg implementation in crates/settings/src/remote_networks.rs intentionally fetches remote networks sequentially rather than in parallel.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:23-25
Timestamp: 2025-04-07T09:50:54.715Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs returns cloned HashMaps in getter methods (like get_remote_networks) rather than references. This design choice was explicitly accepted by the maintainer.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:20-22
Timestamp: 2025-04-07T09:55:44.798Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs is designed to overwrite existing entries without warning when using update methods like update_remote_network. This behavior is an intentional design choice.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:185-199
Timestamp: 2025-06-18T19:24:40.518Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers not to refactor get_orderbook_by_network_key to handle multiple orderbooks per network key since their current architecture maintains a one-to-one mapping between orderbooks and networks. They would consider the refactoring if the system evolves to support multiple orderbooks per network in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/mod.rs:116-135
Timestamp: 2025-07-04T10:26:24.289Z
Learning: In crates/common/src/raindex_client/mod.rs, the get_multi_subgraph_args method intentionally treats Some(empty vector) the same as None for chain_ids parameter. Both cases should return all networks to support UI behavior where no selection or empty selection means "show all networks". Only when specific chain IDs are provided should the results be filtered.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T23:34:42.328Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must use the format:
TOTAL:number
ADDITIONS:number
DELETIONS:number
with no extra text, formatting blocks, or explanations, and must still exclude lock files and reassess after each new commit.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1738
File: packages/ui-components/src/lib/providers/toasts/useToasts.ts:46-52
Timestamp: 2025-05-07T16:51:13.418Z
Learning: UX enhancements for toast notifications, such as pausing timeout on hover, were considered out of scope for the toast refactoring PR.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T21:24:42.275Z
Learning: For PR #1884, after each commit review, I should provide a new comment with a PR size report in the format: `TOTAL=number ADDITIONS=number DELETIONS=number`, excluding irrelevant files such as lock files (package-lock.json, cargo.lock, etc.).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
There was a problem hiding this comment.
@findolor, understood! I'll note your preference for future reviews.
✏️ Learnings added
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: crates/settings/src/remote_tokens.rs:44-62
Timestamp: 2025-07-11T08:45:43.939Z
Learning: findolor prefers to avoid performance micro-optimizations like changing `.values()` to `.into_values()` in HashMap iterations in the rainlanguage/rain.orderbook codebase, even when they would eliminate unnecessary cloning.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/remote_tokens.rs:32-57
Timestamp: 2025-04-07T09:51:52.614Z
Learning: The implementation for remote token fetching in `crates/settings/src/remote_tokens.rs` does not include explicit timeouts/retries, as the team considers the current implementation sufficient for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/remote_networks.rs:40-75
Timestamp: 2025-04-03T09:45:04.200Z
Learning: The RemoteNetworksCfg implementation in crates/settings/src/remote_networks.rs intentionally fetches remote networks sequentially rather than in parallel.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:23-25
Timestamp: 2025-04-07T09:50:54.715Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs returns cloned HashMaps in getter methods (like get_remote_networks) rather than references. This design choice was explicitly accepted by the maintainer.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/cache.rs:20-22
Timestamp: 2025-04-07T09:55:44.798Z
Learning: The Cache implementation in crates/settings/src/yaml/cache.rs is designed to overwrite existing entries without warning when using update methods like update_remote_network. This behavior is an intentional design choice.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:185-199
Timestamp: 2025-06-18T19:24:40.518Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers not to refactor get_orderbook_by_network_key to handle multiple orderbooks per network key since their current architecture maintains a one-to-one mapping between orderbooks and networks. They would consider the refactoring if the system evolves to support multiple orderbooks per network in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/orderbook.rs:180-199
Timestamp: 2025-06-18T18:24:32.049Z
Learning: In crates/settings/src/yaml/orderbook.rs, the user prefers to avoid refactoring duplicate search logic between get_orderbook_by_address and get_orderbook_by_network_key when there are only 2 functions, indicating they would consider it if more similar functions are added in the future.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:98-125
Timestamp: 2025-06-24T08:46:03.368Z
Learning: In the vault merging logic in crates/common/src/raindex_client/orders.rs, optimization isn't necessary because the maximum list items are usually around 5 items. For such small datasets, the simple three-loop approach is preferred over HashMap-based optimization due to clarity and minimal performance impact.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/mod.rs:116-135
Timestamp: 2025-07-04T10:26:24.289Z
Learning: In crates/common/src/raindex_client/mod.rs, the get_multi_subgraph_args method intentionally treats Some(empty vector) the same as None for chain_ids parameter. Both cases should return all networks to support UI behavior where no selection or empty selection means "show all networks". Only when specific chain IDs are provided should the results be filtered.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:92-99
Timestamp: 2025-06-18T18:18:44.330Z
Learning: In crates/js_api/src/raindex/mod.rs, the get_subgraph_url_for_chain method and get_multi_subgraph_args method intentionally duplicate lookup logic because they serve different purposes: get_subgraph_url_for_chain returns only the URL string, while get_multi_subgraph_args returns MultiSubgraphArgs structures containing both URL and network information (name/label). This duplication is acceptable and by design.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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: rouzwelt
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#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: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T23:34:42.328Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must use the format:
TOTAL:number
ADDITIONS:number
DELETIONS:number
with no extra text, formatting blocks, or explanations, and must still exclude lock files and reassess after each new commit.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
| pub fn get_yaml_documents(dotrain: &str) -> Result<Vec<Arc<RwLock<StrictYaml>>>, GuiError> { | ||
| let frontmatter = RainDocument::get_front_matter(&dotrain) | ||
| .unwrap_or("") | ||
| .to_string(); | ||
| let dotrain_yaml = DotrainYaml::new(vec![frontmatter.clone()], false)?; | ||
| Ok(dotrain_yaml.documents) | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Well-implemented YAML parsing helper function
The get_yaml_documents helper function correctly extracts frontmatter and creates a DotrainYaml instance. The error handling is appropriate, and the use of unwrap_or("") for missing frontmatter is consistent with the codebase patterns.
Consider eliminating the unnecessary clone:
pub fn get_yaml_documents(dotrain: &str) -> Result<Vec<Arc<RwLock<StrictYaml>>>, GuiError> {
- let frontmatter = RainDocument::get_front_matter(&dotrain)
+ let frontmatter = RainDocument::get_front_matter(dotrain)
.unwrap_or("")
.to_string();
- let dotrain_yaml = DotrainYaml::new(vec![frontmatter.clone()], false)?;
+ let dotrain_yaml = DotrainYaml::new(vec![frontmatter], false)?;
Ok(dotrain_yaml.documents)
}This avoids the unnecessary clone since frontmatter is moved into the vector anyway.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| pub fn get_yaml_documents(dotrain: &str) -> Result<Vec<Arc<RwLock<StrictYaml>>>, GuiError> { | |
| let frontmatter = RainDocument::get_front_matter(&dotrain) | |
| .unwrap_or("") | |
| .to_string(); | |
| let dotrain_yaml = DotrainYaml::new(vec![frontmatter.clone()], false)?; | |
| Ok(dotrain_yaml.documents) | |
| } | |
| pub fn get_yaml_documents(dotrain: &str) -> Result<Vec<Arc<RwLock<StrictYaml>>>, GuiError> { | |
| let frontmatter = RainDocument::get_front_matter(dotrain) | |
| .unwrap_or("") | |
| .to_string(); | |
| let dotrain_yaml = DotrainYaml::new(vec![frontmatter], false)?; | |
| Ok(dotrain_yaml.documents) | |
| } |
🤖 Prompt for AI Agents
In crates/js_api/src/gui/mod.rs around lines 594 to 600, the variable
`frontmatter` is cloned unnecessarily when creating the vector for
`DotrainYaml::new`. Remove the `.clone()` call and move `frontmatter` directly
into the vector to avoid the redundant clone operation.
There was a problem hiding this comment.
we don't need to do this
There was a problem hiding this comment.
@findolor Understood, we'll keep the current implementation as is. The suggestion was a minor optimization but not necessary for the current PR's objectives.
🧠 Learnings used
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1983
File: crates/js_api/src/gui/mod.rs:964-1199
Timestamp: 2025-07-11T06:40:49.491Z
Learning: In crates/js_api/src/gui/mod.rs tests, findolor prefers to keep large hardcoded YAML strings (like the validation test YAML) inline in the test file rather than extracting them to separate external files for maintainability purposes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: crates/common/src/raindex_client/add_orders.rs:132-132
Timestamp: 2025-07-04T10:24:29.750Z
Learning: In the rain.orderbook codebase, findolor prefers to use `unwrap_or("")` for optional frontmatter in dotrain parsing, allowing empty strings to be handled by downstream validation in `NewConfig::try_from_yaml()` rather than adding explicit early validation checks at the extraction point.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/mod.rs:258-259
Timestamp: 2025-04-22T12:50:39.581Z
Learning: In `DotrainOrderGui::generate_dotrain_text()`, the call to `.to_string()` on `self.dotrain_order.dotrain()` is necessary because there are two different implementations of the `dotrain()` method - one for WASM targets returning a String and one for non-WASM targets returning a &str. The `.to_string()` ensures type compatibility across different compilation targets.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:37-44
Timestamp: 2025-03-31T14:36:11.049Z
Learning: The OrderbookYaml implementation in crates/js_api/src/yaml/mod.rs intentionally parses YAML on demand without caching results. This is a deliberate design choice by the author to process YAML only when needed rather than optimizing for repeated calls.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1477
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-03-31T18:53:12.208Z
Learning: In the DotrainYaml struct, the cache field is kept public (`pub cache: Cache`) without additional getter methods, which is consistent with the existing design pattern in the codebase where other fields like `documents` are also public.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1474
File: crates/js_api/src/yaml/mod.rs:31-34
Timestamp: 2025-03-31T13:57:59.660Z
Learning: The OrderbookYaml constructor in crates/js_api/src/yaml/mod.rs does not need early YAML validation. The author prefers to validate YAML only when it's actually used rather than during initialization.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1838
File: crates/cli/src/output.rs:29-41
Timestamp: 2025-05-19T07:14:24.219Z
Learning: For the rainlanguage/rain.orderbook repository, findolor prefers minimal documentation for straightforward functions like `output` in crates/cli/src/output.rs where the implementation is self-explanatory.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/yaml/dotrain.rs:20-20
Timestamp: 2025-04-07T09:52:30.960Z
Learning: In the DotrainYaml struct, the newly added `cache` field is kept public without documentation, which the maintainer confirmed is acceptable for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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`.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1599
File: crates/common/src/fuzz/impls.rs:91-113
Timestamp: 2025-04-11T05:55:22.504Z
Learning: Empty frontmatter validation is already handled in DotrainYaml::new through the YamlError::EmptyFile error when the yaml parser produces empty documents.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/settings/src/yaml/mod.rs:176-178
Timestamp: 2025-06-18T19:23:33.747Z
Learning: In crates/settings/src/yaml/mod.rs, the YamlError enum has two distinct error variants: `KeyNotFound(String)` for when a specific YAML key is not found in a hash/map, and `NotFound(String)` for when other types of entities (like networks, orderbooks, etc.) are not found in the configuration. These serve different purposes and should not be consolidated.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1689
File: crates/common/src/frontmatter.rs:6-8
Timestamp: 2025-05-08T06:43:46.920Z
Learning: The user (findolor) prefers to keep documentation minimal and doesn't require explicit @param documentation for the `validate` parameter in the `parse_frontmatter` function.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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: rouzwelt
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#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: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T23:34:42.328Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must use the format:
TOTAL:number
ADDITIONS:number
DELETIONS:number
with no extra text, formatting blocks, or explanations, and must still exclude lock files and reassess after each new commit.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
| it('prevents multiple simultaneous token loading requests', async () => { | ||
| // Mock getAllTokens to return a promise that doesn't resolve immediately | ||
| const tokenPromise = new Promise((resolve) => { | ||
| setTimeout( | ||
| () => | ||
| resolve({ | ||
| value: [ | ||
| { | ||
| address: '0x1234567890123456789012345678901234567890', | ||
| name: 'Test Token 1', | ||
| symbol: 'TEST1', | ||
| decimals: 18 | ||
| } | ||
| ] | ||
| }), | ||
| 50 | ||
| ); | ||
| }); | ||
| (mockGui.getAllTokens as Mock).mockReturnValue(tokenPromise); | ||
|
|
||
| render(DeploymentSteps, { props: defaultProps }); | ||
|
|
||
| // Wait for the first call | ||
| await waitFor(() => { | ||
| expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1); | ||
| }); | ||
|
|
||
| // Even if component re-renders while loading, shouldn't call getAllTokens again | ||
| // This is handled by the loadingTokens guard in the component | ||
| await waitFor( | ||
| () => { | ||
| expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1); | ||
| }, | ||
| { timeout: 100 } | ||
| ); | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider extracting the timeout value to a constant.
The 50ms timeout and 100ms wait timeout could be extracted to named constants for better maintainability and clarity of intent.
+const TOKEN_LOAD_DELAY = 50;
+const RACE_CONDITION_CHECK_TIMEOUT = 100;
+
it('prevents multiple simultaneous token loading requests', async () => {
// Mock getAllTokens to return a promise that doesn't resolve immediately
const tokenPromise = new Promise((resolve) => {
setTimeout(
() =>
resolve({
value: [
{
address: '0x1234567890123456789012345678901234567890',
name: 'Test Token 1',
symbol: 'TEST1',
decimals: 18
}
]
}),
- 50
+ TOKEN_LOAD_DELAY
);
});
(mockGui.getAllTokens as Mock).mockReturnValue(tokenPromise);
render(DeploymentSteps, { props: defaultProps });
// Wait for the first call
await waitFor(() => {
expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1);
});
// Even if component re-renders while loading, shouldn't call getAllTokens again
// This is handled by the loadingTokens guard in the component
await waitFor(
() => {
expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1);
},
- { timeout: 100 }
+ { timeout: RACE_CONDITION_CHECK_TIMEOUT }
);
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| it('prevents multiple simultaneous token loading requests', async () => { | |
| // Mock getAllTokens to return a promise that doesn't resolve immediately | |
| const tokenPromise = new Promise((resolve) => { | |
| setTimeout( | |
| () => | |
| resolve({ | |
| value: [ | |
| { | |
| address: '0x1234567890123456789012345678901234567890', | |
| name: 'Test Token 1', | |
| symbol: 'TEST1', | |
| decimals: 18 | |
| } | |
| ] | |
| }), | |
| 50 | |
| ); | |
| }); | |
| (mockGui.getAllTokens as Mock).mockReturnValue(tokenPromise); | |
| render(DeploymentSteps, { props: defaultProps }); | |
| // Wait for the first call | |
| await waitFor(() => { | |
| expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1); | |
| }); | |
| // Even if component re-renders while loading, shouldn't call getAllTokens again | |
| // This is handled by the loadingTokens guard in the component | |
| await waitFor( | |
| () => { | |
| expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1); | |
| }, | |
| { timeout: 100 } | |
| ); | |
| }); | |
| const TOKEN_LOAD_DELAY = 50; | |
| const RACE_CONDITION_CHECK_TIMEOUT = 100; | |
| it('prevents multiple simultaneous token loading requests', async () => { | |
| // Mock getAllTokens to return a promise that doesn't resolve immediately | |
| const tokenPromise = new Promise((resolve) => { | |
| setTimeout( | |
| () => | |
| resolve({ | |
| value: [ | |
| { | |
| address: '0x1234567890123456789012345678901234567890', | |
| name: 'Test Token 1', | |
| symbol: 'TEST1', | |
| decimals: 18 | |
| } | |
| ] | |
| }), | |
| TOKEN_LOAD_DELAY | |
| ); | |
| }); | |
| (mockGui.getAllTokens as Mock).mockReturnValue(tokenPromise); | |
| render(DeploymentSteps, { props: defaultProps }); | |
| // Wait for the first call | |
| await waitFor(() => { | |
| expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1); | |
| }); | |
| // Even if component re-renders while loading, shouldn't call getAllTokens again | |
| // This is handled by the loadingTokens guard in the component | |
| await waitFor( | |
| () => { | |
| expect(mockGui.getAllTokens).toHaveBeenCalledTimes(1); | |
| }, | |
| { timeout: RACE_CONDITION_CHECK_TIMEOUT } | |
| ); | |
| }); |
🤖 Prompt for AI Agents
In packages/ui-components/src/__tests__/DeploymentSteps.test.ts around lines 519
to 554, the timeout values 50ms and 100ms are hardcoded in the test. Extract
these timeout values into named constants at the beginning of the test or file
to improve maintainability and clarify their purpose. Replace the hardcoded
numbers with these constants in the setTimeout and waitFor calls.
There was a problem hiding this comment.
no need to implement this
There was a problem hiding this comment.
@findolor Understood! I'll skip the timeout constant extraction suggestion. The current implementation with inline timeout values works fine for the test's purpose.
✏️ Learnings added
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/__tests__/DeploymentSteps.test.ts:519-554
Timestamp: 2025-07-11T08:46:07.581Z
Learning: In packages/ui-components/src/__tests__/DeploymentSteps.test.ts, findolor prefers to keep hardcoded timeout values (like 50ms and 100ms) inline in test cases rather than extracting them to named constants, viewing such refactoring as unnecessary for test maintainability.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/errors/DeploymentStepsError.ts:16-16
Timestamp: 2025-07-10T12:52:47.468Z
Learning: In packages/ui-components/src/lib/errors/DeploymentStepsError.ts, the error codes NO_SELECT_TOKENS ('Error loading tokens') and NO_AVAILABLE_TOKENS ('Error loading available tokens') represent different failure scenarios in the token loading workflow and should remain as separate error codes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1588
File: packages/orderbook/test/js_api/gui.test.ts:2037-2057
Timestamp: 2025-04-08T12:53:12.526Z
Learning: In the remote network test for gui.test.ts, asserting that getCurrentDeployment() succeeds is sufficient validation that remote networks were properly fetched, as this operation would fail if the networks weren't correctly processed.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1594
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:0-0
Timestamp: 2025-04-05T13:16:58.971Z
Learning: In the DeploymentSteps component, the `checkingDeployment` state variable should be reset to false both after successful operations and error cases to ensure the deploy button returns to its normal state.
Learnt from: brusherru
PR: rainlanguage/rain.orderbook#1957
File: packages/ui-components/src/lib/components/tables/OrdersListTable.svelte:86-94
Timestamp: 2025-06-27T18:41:18.194Z
Learning: In the rain.orderbook UI components, the tokensQuery should use `enabled: true` rather than `Object.keys($activeSubgraphs).length > 0` because tokens are needed for filtering functionality even when no specific subgraphs are selected. The multiSubgraphArgs falls back to default subgraphs from settings, so disabling the query when no subgraphs are active would break the token filtering feature.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:145-162
Timestamp: 2025-04-08T12:56:20.063Z
Learning: In the Rain orderbook project, there's a default test timeout of 10000ms (10 seconds) configured in the Vite config files, eliminating the need for explicit timeouts in each `waitFor()` call.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1512
File: packages/ui-components/src/__tests__/OrderDetail.test.ts:145-162
Timestamp: 2025-04-08T12:56:20.063Z
Learning: In the Rain orderbook project, there's a default timeout value configured in the Vite configuration for tests, eliminating the need for explicit timeouts in each `waitFor()` call.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1738
File: packages/ui-components/src/lib/providers/toasts/useToasts.ts:34-53
Timestamp: 2025-05-07T13:56:58.034Z
Learning: Making the toast timeout duration configurable (rather than hardcoded at 3000ms) was considered out of scope for the toast refactoring PR, but could be implemented as a future enhancement.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1654
File: packages/ui-components/src/lib/stores/transactionStore.ts:195-198
Timestamp: 2025-04-11T08:46:36.365Z
Learning: In the transactionStore, specific functions like `awaitRemoveOrderIndexing` need custom timeout messages that differ from the generic `TransactionErrorMessage.TIMEOUT` message to provide context-specific guidance to users.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like `packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json`, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1483
File: crates/settings/src/remote_tokens.rs:32-57
Timestamp: 2025-04-07T09:51:52.614Z
Learning: The implementation for remote token fetching in `crates/settings/src/remote_tokens.rs` does not include explicit timeouts/retries, as the team considers the current implementation sufficient for now.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1956
File: packages/ui-components/src/__tests__/VaultDetail.test.ts:177-181
Timestamp: 2025-07-04T09:14:35.748Z
Learning: In the rain.orderbook project, maintainer findolor is fine with mutating mock data directly in test files using @ts-expect-error comments, preferring this pragmatic approach over immutable patterns like spread operators for test data updates.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#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: findolor
PR: rainlanguage/rain.orderbook#1687
File: crates/js_api/src/gui/order_operations.rs:470-489
Timestamp: 2025-04-29T11:17:46.178Z
Learning: In the `get_deployment_transaction_args` method of `DotrainOrderGui`, approvals are intentionally only checked against output tokens as per the design requirements.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1559
File: packages/ui-components/src/__tests__/OrderOrVaultHash.test.ts:94-94
Timestamp: 2025-04-04T11:25:21.518Z
Learning: In the rain.orderbook project, minimal test fixtures are preferred over complete mocks that implement the entire interface. Type casting (e.g., `as unknown as SgVault`) is an acceptable approach to maintain both minimal fixtures and TypeScript type compatibility.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1565
File: packages/webapp/src/routes/deploy/layout.test.ts:12-29
Timestamp: 2025-04-07T08:18:36.473Z
Learning: In test files for this project, hardingjam prefers to use custom mocks (such as for localStorage) rather than relying on environment-provided implementations, as this allows for spying on individual methods and having precise control over implementation details for more robust testing.
Learnt from: hardingjam
PR: rainlanguage/rain.orderbook#1870
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:74-97
Timestamp: 2025-05-20T12:08:13.760Z
Learning: In the WithdrawModal test suite, testing that transactions are correctly passed to the transactionStore is considered sufficient coverage, without needing explicit tests for callback execution.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1903
File: crates/js_api/src/subgraph/vault.rs:129-138
Timestamp: 2025-06-17T16:33:58.549Z
Learning: findolor prefers downstream error handling over early validation checks for empty RPC lists in vault functions, allowing errors to bubble up from provider creation logic naturally.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1916
File: packages/webapp/src/routes/+layout.ts:26-26
Timestamp: 2025-06-10T12:01:07.418Z
Learning: The user findolor prefers to keep string concatenation using the plus operator over template literals in the rainlanguage/rain.orderbook project, even when static analysis tools suggest the change.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1947
File: crates/common/src/raindex_client/orders.rs:462-1643
Timestamp: 2025-06-24T08:45:10.971Z
Learning: User findolor prefers to keep tests simple and avoid refactoring for maintainability when the code is stable and viewed as "one time thing" that won't require frequent changes.
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1975
File: crates/js_api/src/config.rs:44-45
Timestamp: 2025-07-09T07:42:48.458Z
Learning: User findolor prefers to defer code improvements and refactoring suggestions to future PRs when they are not directly related to the current PR's scope, even when the suggestions are valid improvements.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#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: rouzwelt
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#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
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T23:34:42.328Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must use the format:
TOTAL:number
ADDITIONS:number
DELETIONS:number
with no extra text, formatting blocks, or explanations, and must still exclude lock files and reassess after each new commit.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:46:08.530Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report should be the only content in the comment - no text before it, no text after it, no formatting blocks, just the raw report in the exact format: "TOTAL=number\nADDITIONS=number\nDELETIONS=number". The report must exclude lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, cargo.lock).
Learnt from: findolor
PR: rainlanguage/rain.orderbook#1938
File: crates/js_api/src/raindex/mod.rs:102-118
Timestamp: 2025-06-18T12:56:44.290Z
Learning: In the rainlanguage/rain.orderbook codebase, it's acceptable to scaffold unused enum variants in initial implementation PRs when they will be implemented in future PRs, as confirmed by findolor.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:35:26.448Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very last part of any comment, after any learning used section or other content.
Learnt from: rouzwelt
PR: rainlanguage/rain.orderbook#0
File: :0-0
Timestamp: 2025-05-21T22:47:21.927Z
Learning: For PR #1884 in rainlanguage/rain.orderbook, the PR size report must always be placed at the very beginning of any comment, before any learning used section or other content.
3 participants
Caution
Merge this PR to enable remote tokens in the strategies rainlanguage/rain.strategies#51
Motivation
See issue: #1270
This PR adds a token selection modal for easily selecting tokens for an order in deployment steps.
Solution
Checks
By submitting this for review, I'm confirming I've done the following:
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Tests
Chores
fix #1270