chore: bump to svelte 5 #334
Conversation
WalkthroughThe pull request introduces significant updates to the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (8)
examples/example-vite-svelte-recs/src/stores.ts (1)
1-8: Consider leveraging new Svelte 5 features for state managementWhile the current store implementation is compatible with Svelte 5, you might want to explore new Svelte 5 features for state management, such as:
- Using the new
statedecorator for simpler state management- Exploring Svelte 5's improved reactivity system
- Updating documentation to reflect Svelte 5 best practices
Would you like help implementing any of these suggestions or creating documentation for the new store patterns?
examples/example-vite-svelte-recs/src/main.ts (1)
17-17: Consider adding error handling and cleanupThe switch to
mount()aligns with Svelte 5's new initialization pattern. However, consider these improvements:
- Add error handling for when the target element is not found
- Consider storing the mounted app instance for proper cleanup
- const app = mount(App, { target: document.getElementById("app")! }); + const target = document.getElementById("app"); + if (!target) { + throw new Error("Failed to find #app element"); + } + const app = mount(App, { target });examples/example-vite-svelte-recs/src/handlers.ts (1)
1-5: Consider initializing the burnerManager variableThe
burnerManagervariable is declared globally but never directly initialized. Instead, it's repeatedly accessed throughget(dojo)in each function. Consider initializing it during setup or removing the unused declaration.-let burnerManager: BurnerManager; +// Remove unused declaration since burnerManager is accessed through get(dojo)examples/example-vite-svelte-recs/src/dojo/componentValueStore.ts (1)
23-23: LGTM! Improved store variable namingThe change from
$storeto$dojoimproves code clarity by using a more specific and contextual variable name while maintaining the same functionality. The derived store's reactivity chain is properly preserved.Consider adding a type annotation to make the store's type more explicit:
- let entityStore = derived(dojo, ($dojo) => ($dojo ? entityId : undefined)); + let entityStore = derived(dojo, ($dojo): Entity | undefined => ($dojo ? entityId : undefined));examples/example-vite-svelte-recs/src/App.svelte (4)
32-35: Enhance setup status feedbackConsider providing more detailed status information to improve user experience.
{#if $dojo} <p>Setup completed</p> {:else} - <p>Setting up...</p> + <p>Setting up Dojo components and connections...</p> + {#if !signer} + <p class="text-warning">Waiting for wallet connection...</p> + {/if} {/if}
Line range hint
43-51: Add error handling for burner managementThe burner selection UI should handle empty states and loading states more gracefully.
- <div>{`burners deployed: ${$burners.length}`}</div> + <div>Burners deployed: {$burners?.length ?? 0}</div> <div> select signer:{" "} - <select on:change={handleBurnerChange}> + <select + on:change={handleBurnerChange} + disabled={!$burners?.length} + > + <option value="">Select a burner</option> {#each $burners as burner} <option value={burner.address}> {burner.address}
Line range hint
79-117: Refactor movement logic and improve error handlingThe movement implementation has several issues:
- Repeated code patterns could be simplified
- Unsafe non-null assertions on signer
- Using console.log for error handling
Consider refactoring the movement logic:
+ const directions = { + Up: (pos) => pos.vec.y > 0, + Down: () => true, + Left: (pos) => pos.vec.x > 0, + Right: () => true + }; + + function handleMove(direction: keyof typeof directions) { + if (!signer) { + console.warn('No signer available'); + return; + } + + if (!position || !$position) { + console.warn('Position not initialized'); + return; + } + + if (directions[direction]($position)) { + client.actions.move({ + account: signer, + direction: { type: direction }, + }); + } else { + console.warn(`Cannot move ${direction}: reached world border`); + } + }Then update the button handlers:
- on:click={() => - position && $position.vec.y > 0 - ? client.actions.move({ - account: signer!, - direction: { type: "Up" }, - }) - : console.log("Reach the borders of the world.")} + on:click={() => handleMove('Up')}
Line range hint
1-122: Consider implementing a game state management patternThe current implementation mixes UI concerns with game logic. Consider implementing a proper game state management pattern to:
- Separate game logic from UI components
- Implement proper error boundaries
- Add loading and error states
- Handle disconnection and reconnection scenarios
This would improve maintainability and user experience.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
examples/example-vite-svelte-recs/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (6)
examples/example-vite-svelte-recs/package.json(1 hunks)examples/example-vite-svelte-recs/src/App.svelte(8 hunks)examples/example-vite-svelte-recs/src/dojo/componentValueStore.ts(2 hunks)examples/example-vite-svelte-recs/src/handlers.ts(1 hunks)examples/example-vite-svelte-recs/src/main.ts(1 hunks)examples/example-vite-svelte-recs/src/stores.ts(1 hunks)
🔇 Additional comments (9)
examples/example-vite-svelte-recs/src/stores.ts (2)
1-4: LGTM! Clean imports with proper type definitions
The imports are well-structured and compatible with Svelte 5, using specific type imports where appropriate.
6-8: Clean store definitions with improved naming!
The simplified store names (dojo, account, burners) follow modern Svelte practices while maintaining type safety. The removal of the redundant "Store" suffix improves readability without sacrificing clarity.
Let's verify that all references to these stores have been updated consistently:
✅ Verification successful
Store renaming has been properly implemented across the codebase
The verification shows that:
- No references to old store names (
dojoStore,accountStore,burnerStore) exist in the codebase - The new store names (
dojo,account,burners) are consistently used in all importing files - Store usage is correct in all files, with proper imports and reactive references (using
$prefix in Svelte components)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining references to old store names
# and verify the new store names are used correctly
echo "Checking for any remaining references to old store names..."
rg -l "dojoStore|accountStore|burnerStore" examples/example-vite-svelte-recs/src/
echo "Verifying usage of new store names..."
rg -A 2 "import.*{.*(?:dojo|account|burners).*}.*from ['\"]./stores['\"]" examples/example-vite-svelte-recs/src/
Length of output: 569
Script:
#!/bin/bash
# Let's try a simpler approach to check store usage
# Check for old store names
echo "Checking for old store names..."
rg "dojoStore|accountStore|burnerStore" examples/example-vite-svelte-recs/src/
# Check for new store names usage
echo -e "\nChecking new store names usage..."
rg "import.*\{.*dojo.*\}.*from.*./stores" examples/example-vite-svelte-recs/src/
rg "import.*\{.*account.*\}.*from.*./stores" examples/example-vite-svelte-recs/src/
rg "import.*\{.*burners.*\}.*from.*./stores" examples/example-vite-svelte-recs/src/
# Check for any direct usage of these store names
echo -e "\nChecking direct usage of store names..."
rg "\$dojo|\$account|\$burners" examples/example-vite-svelte-recs/src/ --type svelte
Length of output: 1707
Script:
#!/bin/bash
# Let's check the actual usage of stores in the files
echo "Checking store usage in files..."
# Check main.ts
echo "=== main.ts ==="
rg "dojo|account|burners" examples/example-vite-svelte-recs/src/main.ts
echo -e "\n=== handlers.ts ==="
rg "dojo|account|burners" examples/example-vite-svelte-recs/src/handlers.ts
echo -e "\n=== App.svelte ==="
rg "dojo|account|burners" examples/example-vite-svelte-recs/src/App.svelte
echo -e "\n=== componentValueStore.ts ==="
rg "dojo|account|burners" examples/example-vite-svelte-recs/src/dojo/componentValueStore.ts
# Check if there are any other files using these stores
echo -e "\nChecking for any other files using these stores..."
fd . examples/example-vite-svelte-recs/src/ -t f -E "stores.ts" -x rg -l "dojo|account|burners" {}
Length of output: 3088
examples/example-vite-svelte-recs/src/main.ts (2)
5-6: Verify store exports match new import names
The change from store-suffixed imports to shorter names aligns with Svelte 5's conventions. Let's verify the exports from the stores file.
✅ Verification successful
Store exports are correctly defined and match imports
The stores file correctly exports all three stores with their new names:
export const account = writable<Account | null>()export const burners = writable<Burner[]>()export const dojo = writable<SetupResult>()
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the stores are properly exported with their new names
# Expected: Find export declarations for 'account', 'burners', and 'dojo'
ast-grep --pattern 'export const $var = $_' ./examples/example-vite-svelte-recs/src/stores.ts
Length of output: 263
Script:
#!/bin/bash
# Let's first check if the stores.ts file exists and its location
fd stores.ts
# Then let's examine its content
cat $(fd stores.ts)
# As a backup, let's also search for export declarations using ripgrep
rg "export.*(account|burners|dojo)" --type ts
Length of output: 2371
11-13: LGTM! Store initialization sequence is maintained
The store updates follow a logical sequence, maintaining the same initialization flow as before. The renamed stores are set in the correct order: dojo first, followed by burners (derived from dojo setup), and finally the active account.
✅ Verification successful
Store initialization and type safety verified
The store definitions in stores.ts are properly typed and initialized:
dojois typed aswritable<SetupResult>burnersis typed aswritable<Burner[]>accountis typed aswritable<Account | null>
The initialization sequence in main.ts correctly matches these types:
setupResfromsetup()is assigned todojoburnerManager.list()returnsBurner[]forburnersburnerManager.getActiveAccount()returnsAccount | nullforaccount
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify type definitions for the new store names
# Expected: Find type definitions or interfaces for the store values
rg -t typescript "interface|type" ./examples/example-vite-svelte-recs/src/stores.ts
Length of output: 263
Script:
#!/bin/bash
# Let's try different approaches to verify the store definitions and usage
# First, let's check if the stores.ts file exists and its content
fd -e ts "stores"
# Then let's look for store-related code including writable definitions
rg "writable|Writable|\.set\(" -A 2
# Finally, check the main.ts content for context
cat "examples/example-vite-svelte-recs/src/main.ts"
Length of output: 7276
examples/example-vite-svelte-recs/src/handlers.ts (1)
2-2: Verify consistent store naming across the codebase
The stores have been renamed from dojoStore, accountStore, and burnerStore to dojo, account, and burners respectively. Let's verify that this naming is consistent across all files.
✅ Verification successful
Let me generate one more verification script to check the store usage in the Svelte files specifically.
Based on the verification results, I can now provide the final response:
Store naming is consistent with the codebase
The store names dojo, account, and burners are correctly defined in stores.ts and match the imports in handlers.ts. The stores are properly typed and use Svelte's writable stores:
dojo: writable<SetupResult>account: writable<Account | null>burners: writable<Burner[]>
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining old store names
echo "Checking for old store names..."
rg -l "dojoStore|accountStore|burnerStore" --type ts --type svelte
# Verify new store names are used consistently
echo "Verifying new store usage..."
rg -l "dojo.*store|account.*store|burner.*store" --type ts --type svelte
Length of output: 345
Script:
#!/bin/bash
# Check for any remaining old store names in all files
echo "Checking for old store names..."
rg -l "dojoStore|accountStore|burnerStore"
# Verify new store names usage
echo "Verifying new store usage..."
rg -l "dojo|account|burners" --type ts
# Get context of store usage
echo "Getting store usage context..."
rg "(dojo|account|burners)" -C 2
Length of output: 497495
Script:
#!/bin/bash
# Search for store usage in Svelte files
echo "Checking store usage in Svelte files..."
fd -e svelte -x cat {} | grep -A 2 -B 2 "dojo|account|burners"
# Check the stores.ts file content
echo "Checking stores.ts content..."
cat examples/example-vite-svelte-recs/src/stores.ts
Length of output: 603
examples/example-vite-svelte-recs/package.json (3)
16-16: Consider upgrading svelte-check for Svelte 5 compatibility
The current version of svelte-check (^3.8.5) might not fully support Svelte 5 features. Consider upgrading to a compatible version to ensure proper type checking.
Let's verify compatibility:
#!/bin/bash
# Description: Check svelte-check compatibility with Svelte 5
# Check latest versions
echo "Latest svelte-check versions:"
npm view svelte-check versions --json | jq '.[-5:]'
# Check for Svelte 5 compatibility in package.json
echo "Checking svelte-check's Svelte peer dependency:"
npm view svelte-check@latest peerDependencies --json13-13: Verify vite-plugin-svelte compatibility
The upgrade to @sveltejs/vite-plugin-svelte@^4 is necessary for Svelte 5 support. Please ensure all features used in the project are compatible with this version.
Let's check the compatibility:
✅ Verification successful
Let me check the project's dependencies to ensure compatibility with the peer requirements.
Let me check the vite config file to see how the plugin is being used.
Compatibility verified successfully
The project's dependencies are properly aligned:
- Using Svelte 5 (
"svelte": "^5") - Using Vite 5 (
"vite": "^5.4.1") - The plugin is used with default configuration without any special options
- No deprecated features are being used
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify vite-plugin-svelte compatibility
# Check latest versions and their compatibility
echo "Latest vite-plugin-svelte versions:"
npm view @sveltejs/vite-plugin-svelte versions --json | jq '.[-5:]'
# Check peer dependencies
echo "Checking vite-plugin-svelte's peer dependencies:"
npm view @sveltejs/vite-plugin-svelte@latest peerDependencies --json
Length of output: 473
Script:
#!/bin/bash
# Check package.json for svelte and vite versions
echo "Project dependencies:"
cat examples/example-vite-svelte-recs/package.json | jq '.dependencies,.devDependencies'
# Check if there are any vite config files that might use specific plugin features
echo -e "\nVite config files:"
fd -e js -e ts vite.config
Length of output: 1244
Script:
#!/bin/bash
# Check the vite config file content
echo "Vite config content:"
cat examples/example-vite-svelte-recs/vite.config.ts
# Check if there are any specific Svelte plugin options being used
echo -e "\nSearching for plugin usage patterns:"
rg -A 5 "vite-plugin-svelte" examples/example-vite-svelte-recs/
Length of output: 6342
15-15: Caution: Svelte 5 is currently in beta
The upgrade to Svelte 5 introduces significant changes as it's currently in beta. Please ensure:
- The application has been thoroughly tested with the new version
- The team is aware of potential breaking changes
- Documentation is updated to reflect Svelte 5 specific patterns
Let's verify the current stable version and check the migration guide:
✅ Verification successful
Svelte 5 is now stable and compatible with the current setup
Based on the verification results:
- Svelte 5 has moved beyond beta and is now stable (latest version 5.2.2)
- The package.json shows compatible versions:
@sveltejs/vite-plugin-svelte: ^4(correct major version for Svelte 5)svelte-check: ^3.8.5(supports Svelte 5 as per earlier peerDependencies check)- Other dependencies are up-to-date and compatible
The upgrade is safe to proceed with as Svelte 5 is no longer in beta and the ecosystem has matured to support it.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check Svelte's latest versions and migration guide
# Check latest versions from npm
echo "Latest Svelte versions:"
npm view svelte versions --json | jq '.[-5:]'
# Check if migration guide exists in docs
curl -s https://raw.githubusercontent.com/sveltejs/svelte/master/documentation/docs/05-misc/02-migrating.md || echo "Migration guide not found"
Length of output: 536
Script:
#!/bin/bash
# Let's verify Svelte 5 status and compatibility
echo "Checking latest Svelte versions:"
npm view svelte versions --json | jq '.[-5:]'
echo -e "\nChecking package.json for related dependencies:"
fd package.json --exec cat {} | jq '.dependencies,.devDependencies' 2>/dev/null
echo -e "\nLooking for Svelte 5 specific changes in the codebase:"
rg -l "runes|snapshot|$state|$derived" --type svelte
echo -e "\nChecking for potential breaking patterns:"
ast-grep --pattern 'export let $_ = $_'
Length of output: 14634
examples/example-vite-svelte-recs/src/dojo/componentValueStore.ts (1)
14-14: Verify consistent store renaming across the codebase
The renaming from dojoStore to dojo appears to be part of a broader store renaming pattern. Let's verify this change is consistent throughout the codebase.
✅ Verification successful
Store renaming is consistent and correctly implemented
The verification shows that:
- The old
dojoStorename is not used anywhere in the codebase - The
dojostore is properly defined in the stores file as a writable store - All imports consistently use the new
dojoname across the codebase:- src/handlers.ts
- src/App.svelte
- src/dojo/componentValueStore.ts
- src/main.ts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify store renaming consistency
# Check for any remaining references to old store names
# Search for old store name
echo "Checking for remaining 'dojoStore' references:"
rg "dojoStore" --type ts --type svelte
# Search for new store name to confirm usage pattern
echo -e "\nVerifying 'dojo' store usage:"
rg "import.*\{ dojo \}.*from.*stores" --type ts --type svelte
Length of output: 354
Script:
#!/bin/bash
# Let's try a different approach without file type restrictions
# First, check for any remaining references to old store name
echo "Checking for remaining 'dojoStore' references:"
rg "dojoStore"
echo -e "\nVerifying 'dojo' store usage:"
rg "import.*\{ dojo \}.*from.*stores"
# Also check the specific file to understand the store definition
echo -e "\nChecking stores definition:"
rg -l "stores?.ts$"
Length of output: 481
Script:
#!/bin/bash
# Let's check the actual stores file and its exports
echo "Checking store definitions in the project:"
fd "stores\.(ts|js|svelte)$" --exec cat {}
# Also check for any other files importing from stores
echo -e "\nChecking all imports from stores:"
rg "from ['\"].*stores['\"]"
Length of output: 986
| const { burnerManager }: any = get(dojo); | ||
| burnerManager.select(target.value); | ||
| accountStore.set(burnerManager.getActiveAccount()); | ||
| account.set(burnerManager.getActiveAccount()); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve type safety and error handling
- The
anytype assertion weakens TypeScript's type safety. Consider using proper typing for the dojo store value. - Async operations in
handleNewBurnerlack error handling. - The burnerManager destructuring pattern is repeated across functions.
Consider these improvements:
-const { burnerManager }: any = get(dojo);
+interface DojoStore {
+ burnerManager: BurnerManager;
+}
+const { burnerManager } = get(dojo) as DojoStore;
export async function handleNewBurner() {
+ try {
const { burnerManager }: any = get(dojo);
await burnerManager.create();
burners.set(burnerManager.list());
account.set(burnerManager.getActiveAccount());
+ } catch (error) {
+ console.error('Failed to create new burner:', error);
+ // Consider proper error handling/user notification
+ }
}Also applies to: 15-18
| export function handleClearBurners() { | ||
| burnerManager = get(dojoStore).burnerManager; | ||
| const { burnerManager }: any = get(dojo); | ||
| burnerManager.clear(); | ||
| burnerStore.set(burnerManager.list()); | ||
| accountStore.set(null); | ||
| burners.set(burnerManager.list()); | ||
| account.set(null); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add user confirmation for destructive operation
The handleClearBurners function performs a destructive operation without user confirmation. Consider adding a confirmation step and documenting the implications of clearing all burners.
export function handleClearBurners() {
+ const confirmed = window.confirm(
+ 'Are you sure you want to clear all burners? This action cannot be undone.'
+ );
+ if (!confirmed) return;
+
const { burnerManager }: any = get(dojo);
burnerManager.clear();
burners.set(burnerManager.list());
account.set(null);
}📝 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.
| export function handleClearBurners() { | |
| burnerManager = get(dojoStore).burnerManager; | |
| const { burnerManager }: any = get(dojo); | |
| burnerManager.clear(); | |
| burnerStore.set(burnerManager.list()); | |
| accountStore.set(null); | |
| burners.set(burnerManager.list()); | |
| account.set(null); | |
| } | |
| export function handleClearBurners() { | |
| const confirmed = window.confirm( | |
| 'Are you sure you want to clear all burners? This action cannot be undone.' | |
| ); | |
| if (!confirmed) return; | |
| const { burnerManager }: any = get(dojo); | |
| burnerManager.clear(); | |
| burners.set(burnerManager.list()); | |
| account.set(null); | |
| } |
| <button on:click={() => client.actions.spawn({ account: signer! })}>Spawn</button | ||
| > |
There was a problem hiding this comment.
Add error handling for spawn action
The spawn action uses a non-null assertion without proper error checking.
- <button on:click={() => client.actions.spawn({ account: signer! })}>Spawn</button
+ <button
+ on:click={() => {
+ if (!signer) {
+ console.warn('No signer available');
+ return;
+ }
+ client.actions.spawn({ account: signer });
+ }}
+ disabled={!signer}
+ >
+ Spawn
+ </button📝 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.
| <button on:click={() => client.actions.spawn({ account: signer! })}>Spawn</button | |
| > | |
| <button | |
| on:click={() => { | |
| if (!signer) { | |
| console.warn('No signer available'); | |
| return; | |
| } | |
| client.actions.spawn({ account: signer }); | |
| }} | |
| disabled={!signer} | |
| > | |
| Spawn | |
| </button |
| const { clientComponents, torii, burnerManager, client } = $dojo; | ||
|
|
||
| $: if (torii && account) | ||
| entityId = torii.poseidonHash([account.address]) as Entity; | ||
| const signer = $account; | ||
|
|
||
| $: if (dojoStore) | ||
| if (signer && torii) { | ||
| const entityId = torii.poseidonHash([signer!.address]) as Entity; | ||
| position = componentValueStore(clientComponents.Position, entityId); | ||
| $: if (dojoStore) | ||
| moves = componentValueStore(clientComponents.Moves, entityId); | ||
| $: if ($burnerStore) burners = $burnerStore; | ||
| } |
There was a problem hiding this comment.
Add error handling for store initialization
The conditional initialization of stores could lead to undefined behavior if accessed before initialization. Consider adding proper error handling and initialization states.
- const signer = $account;
+ let signer = $account;
+ let entityId: Entity | undefined;
+ let position: ComponentStore | undefined;
+ let moves: ComponentStore | undefined;
if (signer && torii) {
- const entityId = torii.poseidonHash([signer!.address]) as Entity;
+ entityId = torii.poseidonHash([signer.address]) as Entity;
position = componentValueStore(clientComponents.Position, entityId);
moves = componentValueStore(clientComponents.Moves, entityId);
+ } else {
+ console.warn('Waiting for signer and torii to be available');
}📝 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.
| const { clientComponents, torii, burnerManager, client } = $dojo; | |
| $: if (torii && account) | |
| entityId = torii.poseidonHash([account.address]) as Entity; | |
| const signer = $account; | |
| $: if (dojoStore) | |
| if (signer && torii) { | |
| const entityId = torii.poseidonHash([signer!.address]) as Entity; | |
| position = componentValueStore(clientComponents.Position, entityId); | |
| $: if (dojoStore) | |
| moves = componentValueStore(clientComponents.Moves, entityId); | |
| $: if ($burnerStore) burners = $burnerStore; | |
| } | |
| const { clientComponents, torii, burnerManager, client } = $dojo; | |
| let signer = $account; | |
| let entityId: Entity | undefined; | |
| let position: ComponentStore | undefined; | |
| let moves: ComponentStore | undefined; | |
| if (signer && torii) { | |
| entityId = torii.poseidonHash([signer.address]) as Entity; | |
| position = componentValueStore(clientComponents.Position, entityId); | |
| moves = componentValueStore(clientComponents.Moves, entityId); | |
| } else { | |
| console.warn('Waiting for signer and torii to be available'); | |
| } |
Introduced changes
Updated Svelte starter to svelte 5
Checklist
Summary by CodeRabbit
Release Notes
New Features
@sveltejs/vite-plugin-svelteandsvelteenhance performance and compatibility.Improvements
Bug Fixes