Add cached settings for listViewOrderbookFilters #1700
Conversation
|
""" WalkthroughThis change introduces several new persistent writable stores in the settings module, each backed by local storage with JSON serialization and error handling. The stores are now imported and used directly in Svelte components, replacing previous reliance on page data or local writable stores. UI components and their props are updated to use the new store types and logic. The Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant SvelteComponent
participant SettingsStore (localStorage)
participant UIComponent
User->>SvelteComponent: Interacts (e.g. toggles checkbox)
SvelteComponent->>SettingsStore: Update store value (e.g. showMyItemsOnly, activeOrderStatus)
SettingsStore->>localStorage: Persist value (JSON serialize)
SvelteComponent->>UIComponent: Pass updated store as prop
UIComponent->>SettingsStore: Read current value (subscribe)
SettingsStore->>UIComponent: Emit current value
Possibly related PRs
Suggested labels
Suggested reviewers
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
hardingjam
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (8)
packages/ui-components/src/lib/index.ts(1 hunks)packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts(1 hunks)packages/webapp/src/lib/index.ts(0 hunks)packages/webapp/src/lib/stores/settings.ts(1 hunks)packages/webapp/src/routes/+layout.svelte(1 hunks)packages/webapp/src/routes/orders/+page.svelte(1 hunks)packages/webapp/src/routes/vaults/+page.svelte(1 hunks)tauri-app/src/lib/storesGeneric/fetchableStore.ts(1 hunks)
💤 Files with no reviewable changes (1)
- packages/webapp/src/lib/index.ts
🧰 Additional context used
🧬 Code Graph Analysis (1)
packages/webapp/src/lib/stores/settings.ts (2)
packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts (1)
cachedWritableStore(30-64)packages/ui-components/src/lib/index.ts (2)
cachedWritableStore(120-120)ConfigSource(71-71)
🔇 Additional comments (11)
packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts (1)
1-64: Well-implemented persistent store with good error handling!This implementation of a cached writable store is solid. I particularly like:
- Comprehensive JSDoc with clear examples
- Proper TypeScript typing with generics
- Robust error handling with silent fallbacks
- Clean separation of concerns with getCache/setCache helpers
The store correctly handles localStorage persistence while gracefully degrading when localStorage is unavailable or errors occur, which is excellent for resilience.
tauri-app/src/lib/storesGeneric/fetchableStore.ts (1)
2-2: Import path change looks correct.The update from a relative import to an absolute alias path is appropriate for the new utility location.
packages/ui-components/src/lib/index.ts (1)
120-120: Export of the new cachedWritableStore utility looks good.The cachedWritableStore is now correctly exported alongside other stores, making it available for use throughout the application.
packages/webapp/src/routes/orders/+page.svelte (2)
5-5: Great improvement using persistent settings!Importing settings directly from the centralized store rather than relying on page data improves maintainability and ensures user preferences persist across sessions.
14-15: Properly simplified store destructuringThe restructuring correctly removes stores that are now imported directly from the settings module, making the code cleaner and more maintainable.
packages/webapp/src/routes/vaults/+page.svelte (2)
5-6: Good implementation of persistent settings importsThese imports correctly leverage the new persistent stores for user preferences, ensuring a consistent approach across different views in the application.
18-19: Properly simplified store destructuringThe destructuring of page stores has been correctly adjusted to remove properties that are now imported from the centralized settings module.
packages/webapp/src/lib/stores/settings.ts (4)
1-23: Well-implemented settings store with proper error handlingThe
settingsstore implementation is robust with appropriate serialization, deserialization, and error handling. The JSDoc comments clearly explain the purpose and default values.
24-44: Good implementation of hideZeroBalanceVaults persistent storeThe store includes proper type checking in the deserializer to ensure the returned value is always a boolean, with a sensible default of
truewhen parsing fails.
46-66: Well-implemented showMyItemsOnly storeThis store correctly implements the PR objective of preserving the user's preference for displaying only data connected to their wallet. The error handling and type checking are robust.
68-88: Properly implemented activeSubgraphs storeThis store supports the PR objective of preserving active network selections. The implementation includes proper error handling with a sensible default empty object.
There was a problem hiding this comment.
Actionable comments posted: 6
🔭 Outside diff range comments (2)
tauri-app/src/lib/storesGeneric/fetchableStore.ts (1)
45-52: 🧹 Nitpick (assertive)Use Number.parseInt instead of global parseInt.
For consistency with the UI components package, update to use
Number.parseInthere as well.export const fetchableIntStore = (key: string, handleFetch: () => Promise<number>) => fetchableStore<number>( key, 0, handleFetch, (v) => v.toString(), - (s) => parseInt(s), + (s) => Number.parseInt(s), );🧰 Tools
🪛 Biome (1.9.4)
[error] 51-51: Use Number.parseInt instead of the equivalent global.
ES2015 moved some globals into the Number namespace for consistency.
Safe fix: Use Number.parseInt instead.(lint/style/useNumberNamespace)
tauri-app/src/lib/stores/settings.ts (1)
159-159:⚠️ Potential issueFix logical error in condition check
There's a logic error in the condition that checks if orderbooks are undefined.
- !$settings?.orderbooks === undefined || + $settings?.orderbooks === undefined ||The current expression first negates the result of
$settings?.orderbooks(converting it to a boolean) and then compares that boolean toundefined, which is likely not the intended logic.
♻️ Duplicate comments (1)
packages/webapp/src/routes/+layout.svelte (1)
17-20: Consider making the settings synchronization reactive.The current implementation synchronizes settings only once on component initialization. For consistency, you may want to make this synchronization reactive to handle subsequent changes to page data.
-const { settings } = $page.data.stores; -cachedSettings.set(settings); +$: if ($page.data.stores?.settings) { + cachedSettings.set($page.data.stores.settings); +}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (13)
packages/ui-components/src/lib/index.ts(1 hunks)packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts(1 hunks)packages/webapp/src/routes/+layout.svelte(1 hunks)packages/webapp/src/routes/orders/+page.svelte(1 hunks)packages/webapp/src/routes/vaults/+page.svelte(1 hunks)tauri-app/src/lib/mocks/mockConfigSource.ts(1 hunks)tauri-app/src/lib/stores/settings.test.ts(0 hunks)tauri-app/src/lib/stores/settings.ts(3 hunks)tauri-app/src/lib/storesGeneric/cachedWritableStore.ts(0 hunks)tauri-app/src/lib/storesGeneric/detailStore.ts(1 hunks)tauri-app/src/lib/storesGeneric/fetchableStore.ts(1 hunks)tauri-app/src/lib/storesGeneric/listStore.ts(1 hunks)tauri-app/src/lib/storesGeneric/settingStore.ts(1 hunks)
💤 Files with no reviewable changes (2)
- tauri-app/src/lib/stores/settings.test.ts
- tauri-app/src/lib/storesGeneric/cachedWritableStore.ts
🧰 Additional context used
🧬 Code Graph Analysis (1)
tauri-app/src/lib/mocks/mockConfigSource.ts (1)
packages/ui-components/src/lib/index.ts (2)
mockConfigSource(141-141)ConfigSource(71-71)
🪛 Biome (1.9.4)
packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts
[error] 78-78: Use Number.parseInt instead of the equivalent global.
ES2015 moved some globals into the Number namespace for consistency.
Safe fix: Use Number.parseInt instead.
(lint/style/useNumberNamespace)
[error] 115-115: Use Number.parseInt instead of the equivalent global.
ES2015 moved some globals into the Number namespace for consistency.
Safe fix: Use Number.parseInt instead.
(lint/style/useNumberNamespace)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: test
- GitHub Check: test
- GitHub Check: git-clean
🔇 Additional comments (15)
packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts (1)
30-64: Well-implemented localStorage persistence with good error handling.The implementation properly handles localStorage initialization, fallback to default values, and silently ignores storage failures. This is a robust approach that ensures the application continues to function even when localStorage is unavailable.
tauri-app/src/lib/storesGeneric/fetchableStore.ts (1)
2-2: Import source updated correctly.The import has been successfully updated to use the shared implementation from the UI components package.
tauri-app/src/lib/storesGeneric/detailStore.ts (1)
2-2: Import source updated correctly.The import has been successfully updated to use the shared implementation from the UI components package.
tauri-app/src/lib/storesGeneric/listStore.ts (1)
6-6: Import source updated correctly.The import has been successfully updated to use the shared implementation from the UI components package.
tauri-app/src/lib/storesGeneric/settingStore.ts (1)
2-2: Good refactoring to use the shared implementation.The migration from a local implementation to the shared
@rainlanguage/ui-componentspackage is a positive change that promotes code reuse and simplifies maintenance.packages/ui-components/src/lib/index.ts (1)
120-125: Well-organized exports of caching utilities.The new export statements properly expose the cached writable store utilities for use across the application, following the established pattern in this file and organizing them in the appropriate section.
packages/webapp/src/routes/orders/+page.svelte (2)
5-5: Good switch to centralized persistent stores.Importing the settings directly from the central store improves code organization and enables persistent user preferences across sessions.
14-15: LGTM!The updated destructuring maintains proper code organization.
tauri-app/src/lib/mocks/mockConfigSource.ts (1)
1-37: Well-structured mock configuration for testingThe mock configuration provides a good baseline for testing with the essential components needed. It includes a network, subgraph, orderbook, deployer, metaboard, and accounts.
packages/webapp/src/routes/vaults/+page.svelte (2)
5-6: Appropriate migration to centralized settings storesThe component now properly imports settings from the centralized stores instead of relying on page data, which aligns with the PR's goal to save user preferences across sessions.
8-19: Clean destructuring of remaining page data storesThe code correctly destructures only the stores that are still needed from page data after migrating others to centralized stores.
tauri-app/src/lib/stores/settings.ts (4)
2-2: Appropriately updated import path for cached storesThe code now correctly imports the cached store utilities from the UI components package instead of local implementation.
13-14: Good test preparationAdding imports for mock data and test utilities prepares the file for the new test suite.
277-380: Comprehensive test suite for settings reactivityThe added tests thoroughly verify that changes to the settings store correctly update dependent stores like
activeAccountsItemsandactiveSubgraphs. The tests cover important edge cases such as removing values and changing values.
282-307: Good test hygiene with store resetThe tests properly reset all store values before each test to prevent state leakage between tests, which is a best practice for testing reactive stores.
packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts
Outdated
Show resolved
Hide resolved
packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts
Outdated
Show resolved
Hide resolved
packages/ui-components/src/lib/storesGeneric/cachedWritableStore.ts
Outdated
Show resolved
Hide resolved
|
@hardingjam can we also cache "Include inactive orders"? as it seems to be the last one not being cached |
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
packages/ui-components/src/lib/components/tables/VaultsListTable.svelte (1)
96-106: 💡 Verification agent🧩 Analysis chain
Consider implementing the "Include inactive orders" filter caching.
Based on the PR comments, there's a request to extend caching functionality to include the "Include inactive orders" filter. Since this component already interacts with the cached settings, it would be a natural place to implement that additional feature.
🌐 Web query:
What is the typical implementation pattern for toggling between active and inactive orders in React or Svelte applications?💡 Result:
The typical implementation pattern for toggling between active and inactive orders in React or Svelte applications involves managing state to track which set of orders to display, and conditionally rendering the orders based on that state. Here's how it’s commonly done in both frameworks:
React
- State Management: Use
useStateto track whether the active or inactive orders are being displayed.- Event Handler: Create a function to update the state when toggling.
- Conditional Rendering: Render the orders based on state.
- Example Pattern:
import React, { useState } from 'react'; function Orders() { const [showActive, setShowActive] = useState(true); const activeOrders = [...]; // fetch or pass active orders const inactiveOrders = [...]; // fetch or pass inactive orders return ( <div> <button onClick={() => setShowActive(true)}>Active Orders</button> <button onClick={() => setShowActive(false)}>Inactive Orders</button> <ul> {(showActive ? activeOrders : inactiveOrders).map(order => ( <li key={order.id}>{order.name}</li> ))} </ul> </div> ); }Svelte
- Reactive Variable: Use a reactive variable to track the toggle.
- Event Handler: Simple functions or direct event binding to change the state.
- Conditional Rendering: Use
{#if}blocks or ternary expressions.- Example Pattern:
<script> let showActive = true; let activeOrders = [...]; // your active orders data let inactiveOrders = [...]; // your inactive orders data </script> <button on:click={() => showActive = true}>Active Orders</button> <button on:click={() => showActive = false}>Inactive Orders</button> <ul> {#each showActive ? activeOrders : inactiveOrders as order} <li>{order.name}</li> {/each} </ul>Common Notes:
- Orders data can come from props, API calls, or local state.
- This pattern can be enhanced with tabs, toggles, or buttons.
- You can also consider memoization or derived state if the data is large or expensive to compute.
If you want, I can provide a more advanced example or include managing the data with async fetching!
🏁 Script executed:
#!/bin/bash # Locate the VaultsListTable.svelte file and display relevant sections FILE_PATH=$(fd VaultsListTable.svelte -x echo) echo "File path: $FILE_PATH" sed -n '1,200p' "$FILE_PATH" # Search for any existing "inactive" related state or props in the codebase rg -n "inactive" -n packages/ui-components/src/lib/componentsLength of output: 7988
🏁 Script executed:
#!/bin/bash # Inspect ListViewOrderbookFilters.svelte to see how filters and caching are implemented FILE1=$(fd ListViewOrderbookFilters.svelte -x echo) echo "ListViewOrderbookFilters: $FILE1" sed -n '1,200p' "$FILE1" echo rg -n "Include inactive" "$FILE1" echo rg -n "settings\." "$FILE1" # Inspect CheckboxActiveOrders.svelte to check its implementation FILE2=$(fd CheckboxActiveOrders.svelte -x echo) echo "CheckboxActiveOrders: $FILE2" sed -n '1,200p' "$FILE2"Length of output: 4184
Implement caching for the “Include inactive orders” toggle
Currently, the
CheckboxActiveOrderscontrol only updates the localactiveOrderStatusstore and isn’t persisted in your usersettings, so its state is lost on reload. To align it with your other cached filters (e.g. active subgraphs), you should:• Extend your
ConfigSourcetype to include an optionalincludeInactiveOrders?: booleanfield.
• InListViewOrderbookFilters.svelte, derive a store fromsettings.includeInactiveOrdersand wire the checkbox’s change handler to update that field.
• UpdateCheckboxActiveOrders.svelteto use the derived value instead of its owncheckedflag.Suggested diff in ListViewOrderbookFilters.svelte:
--- a/packages/ui-components/src/lib/components/ListViewOrderbookFilters.svelte +++ b/packages/ui-components/src/lib/components/ListViewOrderbookFilters.svelte @@ <script lang="ts"> -import CheckboxActiveOrders from './checkbox/CheckboxActiveOrders.svelte'; +import CheckboxActiveOrders from './checkbox/CheckboxActiveOrders.svelte'; +import { derived } from 'svelte/store'; export let settings: Writable<ConfigSource | undefined>; export let activeOrderStatus: Writable<boolean>; +// Persist “include inactive orders” in settings +const includeInactiveOrders = derived( + settings, + $settings => $settings?.includeInactiveOrders ?? false +); +function toggleIncludeInactiveOrders() { + settings.update(cfg => ({ + ...(cfg ?? {}), + includeInactiveOrders: !$settings.includeInactiveOrders + })); +} </script> {#if isOrdersPage} <InputOrderHash {orderHash} /> <div class="mt-4"> - <CheckboxActiveOrders {activeOrderStatus} /> + <CheckboxActiveOrders + activeOrderStatus={includeInactiveOrders} + on:change={toggleIncludeInactiveOrders} + /> </div> {/if}And update
ConfigSourcein your types to includeincludeInactiveOrders?: boolean. This ensures the “Include inactive orders” setting is read from and written to your persistentsettingsstore.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (6)
packages/ui-components/src/__tests__/ListViewOrderbookFilters.test.ts(1 hunks)packages/ui-components/src/lib/__mocks__/stores.ts(2 hunks)packages/ui-components/src/lib/components/ListViewOrderbookFilters.svelte(1 hunks)packages/ui-components/src/lib/components/tables/VaultsListTable.svelte(1 hunks)packages/ui-components/src/lib/types/appStores.ts(1 hunks)tauri-app/src/lib/stores/settings.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (16)
- GitHub Check: standard-tests (ubuntu-latest, rainix-rs-static)
- GitHub Check: standard-tests (ubuntu-latest, test-js-bindings)
- 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: standard-tests (ubuntu-latest, rainix-sol-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-test)
- GitHub Check: standard-tests (ubuntu-latest, rainix-sol-legal)
- GitHub Check: standard-tests (ubuntu-latest, rainix-wasm-artifacts)
- GitHub Check: standard-tests (ubuntu-latest, ob-rs-test, true)
- GitHub Check: Deploy-Preview
- GitHub Check: test
- GitHub Check: test
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: test
- GitHub Check: git-clean
🔇 Additional comments (5)
packages/ui-components/src/lib/components/ListViewOrderbookFilters.svelte (1)
22-22: Type narrowing for improved consistency.The prop type has been narrowed from
Writable<boolean | undefined>toWritable<boolean>, which aligns with the cached settings store implementation. This change improves type safety by enforcing thatactiveOrderStatusmust always be a boolean.packages/ui-components/src/lib/types/appStores.ts (1)
8-8: Type narrowing for improved consistency.The store interface type has been narrowed from
Writable<boolean | undefined>toWritable<boolean>, which enforces thatactiveOrderStatusmust always be a boolean value. This change is part of the broader refactoring to standardize types across the cached settings implementation.packages/ui-components/src/__tests__/ListViewOrderbookFilters.test.ts (1)
49-49: Test initialization aligned with new type requirements.The test initialization has been updated to use
trueinstead ofundefinedas the initial value foractiveOrderStatus, which aligns with the type narrowing changes and the default value in the cached settings store.packages/ui-components/src/lib/components/tables/VaultsListTable.svelte (1)
32-32: Type narrowing for improved consistency.The prop type has been narrowed from
Writable<boolean | undefined>toWritable<boolean>, which aligns with the cached settings store implementation. This standardizes the usage ofactiveOrderStatusacross components.packages/ui-components/src/lib/__mocks__/stores.ts (1)
30-31: Mock store type updated to match implementation changesThe mock store for activeOrderStatus has been appropriately updated to match the implementation changes in the actual store. The type is now strictly
booleanwith a default value oftrue.Also applies to: 66-70
❗ First, merge #1698
Checks
By submitting this for review, I'm confirming I've done the following:
Summary by CodeRabbit