dojoengine / dojo.js

dojo.js - enter the dojo via js

Dojo: The Provable Game Engine

Dojo is a community driven open-source, Provable Game Engine, providing a comprehensive toolkit for building verifiable games and autonomous worlds.

Dojo.js is the official JavaScript SDK for interacting with Dojo worlds. It is currently a work in progress (WIP), and we are actively seeking contributors.

Read the full dojo documentation

---

Bootstrap a dojo world like so. You will need dojo installed.

npx @dojoengine/create-dojo

Dojo.js Examples

• React-app - A vite react app example using Dojo
• React-phaser - A vite phaser react app using Dojo
• Torii-bot - A small discord bot for interacting with Torii
• vue-app - A vite vue app example using Dojo
• Vanilla-phaser - A vanilla phaser example using Dojo

Contributing to dojo.js

From the repository root, run the following to install all the necessary package dependencies:

pnpm i

Building Packages

Note: Before running the examples, you must build each package.

To build all packages, from the root directory, run:

pnpm run build

To watch for changes on all packages in parallel, from the root directory, run:

pnpm run build-watch

Dojo starter

To install dojo-starter submodule (which allows interactions with the examples), run:

git submodule update --init --recursive

---

Debugging

If you have issues on WSL, install package first then run command:

npm i @dojoengine/create-dojo -g
npx @dojoengine/create-dojo

Examples

To run the examples that have the linked packages, follow the steps below:

Terminal 1: Set up the dojo starter with specific configurations.

cd examples/dojo-starter
katana --disable-fee --allowed-origins "*"

Terminal 2: Build and migrate the dojo starter.

cd examples/dojo-starter

# Build and migrate
sozo build
sozo migrate apply
# From your frontend project directory
DOJO_MANIFEST_PATH=../relative/path/to/contracts/Scarb.toml sozo build --typescript --bindings-output=./dojo/gen

# Run Torii
torii --world 0xb4079627ebab1cd3cf9fd075dda1ad2454a7a448bf659591f259efa2519b18 --allowed-origins "*"

Terminal 3: Start the App

cd examples/<package>
pnpm install
pnpm run dev

dojo.js's Issues

[Enhancement]: Update create-dojo to include new templates

Feedback

Update create-dojo to include new templates

If the request is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[burner] Excessive rpc requests from useBurner() after burner manager initialization

When invoking useDojo(), it internally calls useBurner(), which correctly fetches data from the storage. However, despite the Burner manager being previously initialized, useBurner() is still making unnecessary RPC requests.

Ideally, useBurner() should recognize when the Burner manager is already initialized and avoid making additional RPC calls.

Callback library

With the new torii-client features, along with modularity needed for dojo.js we need to define some generic callbacks which interface with torii-client and allow for higher level abstractions for specific SDKs.

The callback functions should exist within torii-client package and be generic.

The callbacks should expose:

• Specific Entity update
• Any Model update
• Specific Model update
• Composite Model updates

[burner]: Delete burners if not deployed

Feature Request

The Burner manager should delete the burners if they don't exist. This will stop user errors trying to use old burners.

Proposed Solution

No response

Alternatives

No response

Related Code

No response

Additional context

No response

If the feature is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[dojo.js] Testing suite CI

Tasks

Beta Give feedback

1. Generate components
2. Test RPC
3. npx commands
4. Burner tests
5. Core package tests

[core] Complete functionality to all endpoints in World

The goal of the Core package is to be the RPC interface for a dojo world. Currently, not all endpoints are exposed.

With the stability of 0.3.0, we can now extend the functionality to all endpoints of the world to allow easy querying.

Support cairo u256 types

I currently rely on u256 types on most of my models, and since Dojo js stack is not really supporting it yet, I am duplicating a lot of code on my projects, but it is a pain to maintain.
Yesterday I discovered that some of my contribution to that direction does not work anymore, so better formally issue it.

Probably everyone agrees that the best thing is to update the packages and actually support it, right?
I'm willing to do it.
Here's how I see it.
Just don't want to break anything else...

@latticexyz/recs vs. @dojoengine/recs

Is there anything really necessary in Dojo's fork of mud recs?
Can't we just use Lattice's instead?

Talking to @ponderingdemocritus a while back, I got the notion that there isn't really.
Since I needed mud 2.0 for u256, I replaced all my recs imports to mud, while Dojo was on mud 1.0.
But now that Dojo is broadly using mud 2.0, can't we just switch to @latticexyz/recs?
Everything was working fine.

Now I tried replacing my imports to dojo's fork and started getting all sorts of obscure problems, so got back to mud recs.

Recs version with BigInt support

Because of mud 2.0 recs, I added this to generateComponents.cjs

// Extract recs package version
const { dependencies } = require(path.resolve("./package.json"));
const recsVersion = dependencies?.["@dojoengine/recs"] ?? "";
const isRecsVersion2 = /^[\^\~]?2./g.exec(recsVersion) != null;
console.log(
    `...generating for @dojoengine/recs version ${
        isRecsVersion2
            ? "2 (bigint support, Entity as string)"
            : "1 (no bigint, EntityIndex as number)"
    }`
)

This is now broken because the version check is looking in dojo's recs, not lattice's...

So I propose to remove the recs version check and just use mud 2.0 as default, with BigInt support.
OK?

Recs types

Just saying that a u256 is a RecsType.BigInt is not enough.
One u256 is actually two u128 in cairo, using two slots of event data.
Because of that... I added the types field on the generated metadata, so I can type check when parsing event data.

My models are looking like this on contractComponents.ts:

      return defineComponent(
        world,
        {
          seed: RecsType.BigInt,
          minter: RecsType.BigInt,
          domain_id: RecsType.Number,
          token_id: RecsType.Number,
          yonder: RecsType.Number,
        },
        {
          metadata: {
            name: name,
            types: ["u256","ContractAddress","u16","u16","u16"],
          },
        }
      );

But I just dicovered that my types were hijacked!
It is not storing cairo types anymore, instead, only custom types.
@kariy, is that the purpose or you just adapted to the new parser?
Adding all primitive tyes as well will fix this for me.

Event data to components...

Now that I know which model fields are u256, decodeComponent() has to be updated to consume two values from the event data when a u256 pops up...

export function decodeComponent(
    schema: any,
    values: string[],
    valuesIndex: number
): any {
    // Iterate through the keys of the schema and reduce them to build the decoded component.
    return Object.keys(schema).reduce((acc: any, key) => {
        // If the current schema key points to an object and doesn't have a 'type' property,
        // it means it's a nested component. Therefore, we recursively decode it.
        if (typeof schema[key] === "object" && !schema[key].type) {
            acc[key] = decodeComponent(schema[key], values, valuesIndex);
        } else {
            // If the schema key points directly to a type or is not an object,
            // we parse its value using the provided parseComponentValue function
            // and move to the next index in the values array.
            acc[key] = parseComponentValue(values[valuesIndex], schema[key]);
            valuesIndex++;
        }
        return acc;
    }, {});
}

npx core

Makes no sense to me that we use this command to generate the components file:

npx @dojoengine/core xxx/manifest.json yyy/contractComponents.ts

EDIT: nevermind, now that I understand better how it works, I see it is correct.

Unit tests

I have NO idea on how to add unit tests to keep these things working forever.
I'll leave that to someone else to do the base implementation.
Just an idea...

[core] update generate script

Currently, the generate script does not support custom types. The types are currently flattened in the abi, not in the members.

We should move this script to introspect the world and fetch the schema, rather than from the manifest.

[core] add logging

A parameter should be able to be passed into the RPCProvider which enables the logging of the provider actions.

[feature] Jotai State integration

Currently dojo has Recs as a state management package, however often this is too heavy.

For simple dapps a state management like Jotai that is synced with torii would be ideal for experimenting.

This tasks is the design a sync and store using https://jotai.org/

The task contains, but not limited to

• Initial Architecture and design (get review before proceeding)
• Syncing with Torii using the 'State' package
• Exposing a setup function for users
• Building example

[Feature]: Adding PFP and Starknames using useStarkProfile on your frontend template

Feature Request

Hello!

It would be super cool to make the Starknet.id integration by adding .STARK domain and PFPs on your frontend template using our documentation.

Based on each repo we will adapt the method used (check all methods https://docs.starknet.id/)

You have several choices:

• Starknetid.js
• Starknet React
• Starknet.js
• API

Up to you to choose the best method for each repository, the best will be to use the library you are already using!

@Marchand-Nicolas, one of our team members, can help to do it if needed!

Proposed Solution

After connecting wallet, be able to see .STARK domain and PFP like on this example:

Alternatives

No response

Related Code

No response

Additional context

No response

If the feature is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Bug]: torii-wasm not covnerting u256 types correctly

Dojo.js Version

0.3.3

What happened?

During sync using getSyncEntities(), components of u256 type do not sync, throwing an error (screenshot below).
Those types are missing the 0x prefix (screenshot below).

What is the expected behavior?

All data types including u256 should be parsed correctly by torii-wasm, and not crash the client

Steps to reproduce

Sync a component that contains some u256 data type, the client will crash on getSyncEntities()
I traced the bug to the client.getEntities() call at /packages/state/src/recs/index.ts#L28, where I can see the u256 types on entities data returned by torii do not contain the 0x prefix. (see the entities print on the screenshot below)

This project contains u256 types.
If you run it, click on 'ENTER', then 'Create Underworld'.
Refresh to sync, and the error comes up.
https://github.com/funDAOmental/lootunderworld

Trace

Client error:

Result from

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[examples] Vite PWA

We need a very bare bones example of a dojo.js PWA.

Vite has great support for this - https://vite-pwa-org.netlify.app/

This should be fairly straight forward and should be based off the existing react-app, but just extended with the PWA features.

[Bug]: Fix React Examples

Dojo.js Version

0.2.10

What happened?

DojoProvider usage in both react examples is incorrect. Also generate component script is using incorrect dojo-starter path.

What is the expected behavior?

Should provide world address as a first argument in DojoProvider

Steps to reproduce

Run any of the react example

Trace

No response

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[Enhancement]: Core Vite tests

Feedback

• complete test coverage of core with vitetests

If the request is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Enhancement] BurnerManager improvements

I'm proposing improvements to the Burner Manager to give a better experience...

• a function to check if an address is valid or not. If the account does not exist (wrong network or wrong cookies), we have a warning on the console, but there's no way to know if an account exists or not. That response should be stored and accessible from the client.

dojo.js/packages/create-burner/src/manager/burnerManager.ts

Line 107 in f509765

this.masterAccount

• A property that returns the number of burner accounts created (I need it to refresh React hooks after add/delete)

• A method to unselect burner, and select the master account. Once we select a burner, it's impossible to go back to master.

• A way to restore deployed burners but not on cookies (if that's possible)

[Bug]: Failed in running `pnpm create-components` in version 0.5.11-alpha.0

Dojo.js Version

0.5.11-alpha.0

What happened?

wen the pnpm create-components command run in 0.5.0 it works, but when run it in @dojoengine/[email protected] the command line will report an error, both command run in the same environment

What is the expected behavior?

successfully run and create the components

Steps to reproduce

run the pnpm create-components after upgrading the dojo.js to 0.5.11-alpha.0, get an error

downgrade the dojo.js to version 0.5.0, run the same command, it works

Trace

npm ERR! could not determine executable to run

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[Enhancement]: Add Threejs Starter

Feedback

Threejs is a fantastic graphics library and is perfect for grid based games.

This task it to finish a Threejs starter

It will include

• Vite
• Threejs
• Recs for torii state
• Zustand for Client UI state
• Threejs grid component
• VIte PWA

If the request is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Bug]: React package build command fails

Dojo.js Version

0.2.10

What happened?

When running bun run build-react, it fails because of implicit any error.

What is the expected behavior?

When running bun run build-react, it should succeed.

Steps to reproduce

Run bun run build-react

Trace

No response

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[discuss] Codegen world interface

We want to minimize boilerplate writing as much as possible while also improving type safety and completion for the best possible developer experience.

One way we can achieve this is by generating a World Class based on the manifest.json, which builds a typed interface for all potential endpoints into the world.

Ideally, the end goal is something like this:

await dojo.play.create({ account, name: "ohayo"})

This would execute the Play system contract and the Create function.

We could achieve this by generating classes like:

(Slayer is the World Name)

export class Slayer extends RPCProvider {
    public play: PlayContract;

    constructor(worldAddress: string, manifest?: any, url?: string) {
        super(worldAddress, manifest, url);
       
        // each system contract would be nested like this
        this.play = new PlayContract(this);
    }
}

interface IPlayContractFunctions {
    create: (props: CreateProps) => Promise<any>;
    seek: (props: Signer) => Promise<any>;
    roll: (props: RollProps) => Promise<any>;
    buy: (props: BuyProps) => Promise<any>;
    apply: (props: ApplyProps) => Promise<any>;
}

export class PlayContract implements IPlayContractFunctions {
    private slayer: Slayer;
    private name: string;

    constructor(provider: Slayer) {
        this.slayer = provider;
        this.name = "play";
    }

    async create(props: CreateProps): Promise<any> {
        try {
            return await this.slayer.execute(
                props.account,
                this.name,
                "create",
                [this.slayer.getWorldAddress(), props.name]
            );
        } catch (error) {
            console.error("Error in creating entity:", error);
            throw error;
        }
    }
}

Since worlds will contain many contracts we need to nest the classes to avoid potential clashes.

This file could be generated by simply:

bun run generate-systems

Looking for feedback on this.

@tarrencev @broody @JunichiSugiura @rsodre @Matth26 @aymericdelab

[ci] Fix CI

Current issue around wasm module in CI

[core] Add schema introspection endpoint

The core should include a schema introspection read function to allow clients to easily query worlds. This should be added to the RPC provider.

[Enhancement]: support fully qualified contract name

Feedback

Currently, when execute is called on the DojoProvider, under the hood only the name of the contract is looked up.

In this issue, the proposal is to also accept a fully qualified contract name to avoid possible clashes. This by detecting if the given name already contains :: at least once.

This will allow those two behaviors

// Lookup only to the last segment of the module path as currently done.
await execute(props.signer, "actions", "spawn", [props.rps]);

// Search for the exact path.
await execute(props.signer, "emojiman::actions::actions", "spawn", [props.rps]);

If the request is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Bug]: Enum are received as NaN

Dojo.js Version

0.5.1

What happened?

Here is my component generated by the script.
There are 3 enums in customTypes

Machine: (() => {
      return defineComponent(
        world,
        { id: RecsType.Number, x: RecsType.Number, y: RecsType.Number, machine_type: RecsType.Number, direction: RecsType.Number, source: RecsType.Number, source_dist: RecsType.Number, resource_type: RecsType.Number, placed_at: RecsType.Number, last_compute_at: RecsType.Number },
        {
          metadata: {
            name: "Machine",
            types: ["u32","u32","u32","enum","enum","u32","u32","enum","u64","u64"],
            customTypes: ["MachineType","Direction","ResourceType"],
          },
        }
      );
    })(),

here is how I retrieve the machines

useEffect(() => {
        defineSystem(world, [Has(Machine)], ({ value: [newValue] }: any) => {
            console.log(newValue)
        });
    }, []);

But newValue looks like this:

{
direction: NaN, -- customType
id: 1,
last_compute_at: 1708666803,
machine_type: NaN, -- customType
placed_at: 1708666803,
resource_type: NaN, -- customType
source: 0,
source_dist: 0,
x: 1000,
y: 1000
}

And here is my enum definition

#[derive(Serde, Copy, Drop, Introspect, PartialEq, Eq)]
enum ResourceType {
    None,
    IronOre,
    IronIngot,
    IronPlate,
}

I tried without defineSystem but with this and I have the same issue

const machine = useComponentValue(MachineClientComponent, props.machineId);
console.log(machine)

What is the expected behavior?

Not sure if it should at least return a number value, or directly the right enum (they are not generated right now, maybe we need a new generated file with all the enums?)

Steps to reproduce

Using the dojo-starter + threejs example, I sometimes have a number value when I print "last_direction", but most of the time it's NaN. Maybe it's because of the override.
The issue seems to be that @dojoengine/recs is never using the customTypes value, at least I can't see where it is used.

Trace

No response

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[Feature]: Expose query clause to JS

Feature Request

To support more expressive queries, we would need to expose the Clause struct.

Proposed Solution

The function should be able to convert queries like the one below to the necessary query that torii-client will understand.

const player = dojo_starter.findEntity([
    {
        model: "Moves",
        query: {
            player: account.account.address,
            OR: [
                { remaining: { gt: 50 } },
                { last_direction: Direction.Down },
            ],
        },
    },
    { model: "Position" },
] as const);

Alternatives

No response

Related Code

No response

Additional context

A bit more context can be found in this RFC where a new API for interacting with your Dojo world is being discussed.

If the feature is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Feature]: React Native Starter

A very simple React Native Starter based off the dojo-starter repo.

createDojoConfig() not consuming params

createDojoConfig() doesn't look right to me...

dojo.js/packages/core/src/config/index.ts

Line 23 in c152a0a

export function createDojoConfig({ manifest, ...config }: DojoConfigParams) {

shouldn't it be like...

export function createDojoConfig({ manifest, ...config }: DojoConfigParams) {
    return {
        rpcUrl: config.rpcUrl ?? LOCAL_KATANA,
        toriiUrl: config.toriiUrl ?? LOCAL_TORII,
        masterAddress: config.masterAddress ?? KATANA_PREFUNDED_ADDRESS,
        masterPrivateKey: config.masterPrivateKey ?? KATANA_PREFUNDED_PRIVATE_KEY,
        accountClassHash: config.accountClassHash ?? KATANA_CLASS_HASH,
        manifest,
    };
}

Typed torii-client abstractions and query API

Background

Torii-client currently exposes functions to fetch from torii-server. Right now they are low level abstractions, we can improve these to make it very easy for any js app to sync or fetch with a remote torii.

Right now we sync the entire of the world state onload, and also when state changes these are reflected. This is great for prototyping however when applications become more complex and the state grows the whole application and UX slows because of this.

We can provide a clean abstraction for users to query the state allowing for extremely effiecent apps.

Tasks
This task is to build pure JS abstractions within the torii-client package which can then be used upstream in react or other frameworks.

[Feature]: Expo Starter

Create a React Expo starter - https://expo.dev/

[Feature]: Get the % of entities synced when using torii-client

Feature Request

As the number of entities in the world get bigger and bigger, syncing of the torii-client takes more and more time.
Would be a nice addition for UX to know what is the progress of the syncing.

Proposed Solution

i'm thinking we could make a simple API call to the remote torii to get total number of entities and compare that to the number of entities currently synced.

Alternatives

No response

Related Code

No response

Additional context

No response

If the feature is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Bug]: generateComponents script generates incorrect model name

Dojo.js Version

0.2.9

What happened?

suppose if the model file name contracts is <package-name>::models::player_at_position.json, generated model name is PlayerATPosition

What is the expected behavior?

suppose if the model file name contracts is <package-name>::models::player_at_position.json, generated model name should be PlayerAtPosition

Steps to reproduce

Execute npx @dojoengine/core src/target/dev/manifest.json src/dojo/contractComponent.ts <RPC_URL> <WORLD_ADDRESS>

Trace

No response

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

Next.js starter

Very basic next.js starter template that incorporates the grpc and recs libs.

[Bug]: @dojoengine/core show "Failed to create bin" warning

Dojo.js Version

0.6.12

What happened?

When I run pnpm install

And I can't use create-components

What is the expected behavior?

I have modified the code on the contracts, and need to generate the corresponding on the client side.

Steps to reproduce

npx @dojoengine/create-dojo
cd client
pnpm install
npx @dojoengine/core ../contracts/manifests/deployments/KATANA.json src/dojo/generated/contractComponents.ts http://localhost:5050 0x446f1f19ba951b59935df72974f8ba6060e5fbb411ca21d3e3e3812e3eb8df8

Trace

No response

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[Enhancement]: Burner vite tests

Feedback

• complete coverage of burner tests using vitest

If the request is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Feature]: Deterministic burner accounts

Feature Request

Problem: New burner accounts are always created with a random keys and address, stored on the browser.

That causes many drawbacks:

• Users need to be aware of their accounts' vulnerabilities, export, and store keys securely.
• If the browser data is cleaned and the private key is lost, the account and assets are also lost.
• Recovering one address requires the technical ability to dig into a block explorer and find the deployment transaction.
• Increases support occurrences from users who don't know where their keys are and/or lost their accounts
• Terrible user experience

We don't want to expose players to another security risk and we don't want players to lose assets.

From one seed phrase, Ethereum and Starknet wallets always create the same account address sequence wherever they are recovered. Understanding the importance of their seed phrase and storing them securely is something every user needs to understand and be comfortable with before starting to interact with on-chain games.

Proposed Solution

I propose implementing Deterministic Burner Accounts, from a a seed and an index, similar to Ethereum and Starknet wallet accounts.

Obviously, we don't want access to players' seeds and keys! This is the proposed workflow:

• Request player to sign a specific message, known by the game developers
• The signature is never stored or displayed to the player.
• Use @scure/bip32 to create keypairs and addresses
• Deploy, fund, and use accounts to play the game
• Players do not need to securely store their keys
• Browser data can be deleted at any time, for security concerns
• Anywhere player connects their wallets, by signing the same message, their accounts and keys can be recovered and used.

The solution I'm working on includes:

• Passing optional seed and index to the burner manager create() method
• Simulate account address generation with a new burner manager generateKeysAndAddress () method
• Key derivation implementation using @scure/bip32
• Storing the account index, master account, and metadata (signed message contents) to the burner storage

Alternatives

None, currently we can only create random burner accounts.

Related Code

• BIP-32 Hierarchical Deterministic Wallets details how to create accounts from a seed and index
• Someone drafted a proposal for Account keys and addresses derivation standard on Starknet
• ArgentX uses this technique for key derivation.
  how

Additional context

No response

If the feature is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[Bug]: torii.createClient() on Safari and Firefox

Dojo.js Version

0.5.0

What happened?

The torii wasm client on Safari and Firefox takes 60+ seconds to start, or never starts.
On the react-app example, it never returns, freezing the app.

dojo.js/examples/react/react-app/src/dojo/generated/setup.ts

Line 16 in bc3ca83

const toriiClient = await torii.createClient([], {

What is the expected behavior?

The torii wasm client should start quickly, as in Chrome and Chromium.

Steps to reproduce

• Bootstrap the react-app example with dojo-starter
• start katana, migrate, start torii, start client
• open the client on Safari and Firefox: torii.createClient() never returns, freezing the app before it starts

or use on our current deployment, it takes 60+ seconds to start the tori client on Safari, and it never starts on Firefox:
https://pistols.lootunder.world/gate

Tested on macOS 13 and 14
Safari 17.0
Firefox 122.0

Trace

No response

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[create-burner] Client errors when stored burners not found

Repro:

• Run local Katana + Torii
• Open client, create burner wallets
• Close Katana + Torii
• Migrate
• Run local Katana + Torii
• Open client
• useBurner() will trigger a client error when trying to find the stored wallets that do not exist anymore

Dojo 0.3.15
create-burner 0.1.56
game

[core] Add multicall functionality

[Feature]: Vue Starter

Feature Request

Create a minimal Vue starter. It should be identical to the React-App only Vue.

[burner] Remove options

Currently, the burner takes an options parameter in the set. This should be removed as it is not ideal if you want to use the hook in more than 1 place

    const { create, list, get, account, select, isDeploying, clear } = useBurner({
        masterAccount: masterAccount,
        accountClassHash: VITE_PUBLIC_ACCOUNT_CLASS_HASH!,
    });

To:

   const { create, list, get, account, select, isDeploying, clear } = useBurner();

This also means we need to pass the master account and class hash into the create function.

u64 as BigInt

Follow up to Torii core store u64 primitive as string in db, u64 types need to be mapped to RecsType.BigInt instead of RecsType.Number.

That needs to be in sync with the release of the PR above (merged today) by @broody.

dojo.js/packages/core/bin/generateComponents.cjs

Line 59 in 3e12e7c

u64: "RecsType.Number",

[burner] Add option to copy/paste all local storage burners

Right now burners are tied to the browser environment they exist in.

We should offer a solution to copy the entire burner object and paste it into another browser environment so users can take their accounts with them.

[docs] Add doc gen

Adding generated docs on every build would be worthwhile now:

https://typedoc.org/guides/installation/

This should build docs for every package.

create wasm noise

We currently have a js implementation of simplex, but it is not very fast.

https://github.com/dojoengine/dojo.js/blob/main/packages/utils/src/game/simplex.ts

This task is to convert this into WASM, which will be significantly faster.

FYI - this pairs with the onchain simplex noise in the cubit cairo lib.

[Feature]: Torii grpc event subscription and query

Feature Request

Custom events are very useful and powerful for building things like leaderboards, activity logs, narratives, and social loops. But unfortunately, there's no way to use them on javascript clients other than building graphql queries. Most Dojo games have moved to torii gprc sync and do not require graphql to function anymore

The Torii server seems to already have custom events implemented (dojo#1517, (dojo#1420)[https://github.com/dojoengine/dojo/issues/1420], dojo#1567), but they are not accessed by the torii client.

I propose adding custom events support to torii grpc client.

• Torii grpc custom events subscription
• Torii grpc custom events queries

Proposed Solution

torii-wasm / torii-client packages

• Accept subscriptions for custom events
• Expose methods for custom event subscription

Similar to Model Events, Custom events should be easily accessible from the js clients.

react package

• New hook to subscribe to new torii events of a specific type
• Allow custom events to be queried by recs, if possible
• or.. implement a hook to query custom events
• Events must include the block timestamp

Alternatives

It is possible to subscribe to events using graphql.

Related Code

No response

Additional context

No response

If the feature is accepted, would you be willing to contribute it?

• Yes I would be willing to contribute

[dev tools] New package

We should implement some debugging and interface tools that are optional for developers to include in their builds.

[core] Add world sync

We need a clean, fast way to sync the world via Torii.

It should give the option to sync the whole world or sync parts.

This method should be exposed in the core and easily imported downstream.

Add CI for releases

• Add git actions to deploy new releases of the packages

[core] update generate components script to allow custom types

Currently, the core script doesn't support custom types.

We need to allow these to auto generate.

Relevant to #18

[Bug]: Fresh react-app with dojo-starter not working for me with Dojo 0.4.2

Dojo.js Version

0.2.9

What happened?

Having trouble getting the basic react-app template working with the latest dojo stack

╰─➤  torii --version
torii 0.4.2
╰─➤  sozo --version
sozo 0.4.2
╰─➤  katana --version
katana 0.4.2

In Firefox: react-app displays nothing. Network tab shows GET request to torii 0.0.0.0:8080/world.World/SubscribeModels is stuck pending

In Chrome: react-app UI components are displayed. Network tab still shows same request stuck pending. Can create burner wallets but dojo functionality failes with:

uncaught (in promise) Error: Error fetching transaction receipt
    at @dojoengine_create-burner.js?v=eb920faa:27739:15

What is the expected behavior?

Fresh react-app should work the same on common brower types without issue

Steps to reproduce

Setup project

• npx @dojoengine/create-dojo

terminal 1

• cd dojo-starter && katana --disable-fee

terminal 2

• cd dojo-starter && sozo build && sozo migrate
• torii --world 0x33ac2f528bb97cc7b79148fd1756dc368be0e95d391d8c6d6473ecb60b4560e
  • world address from output of migrate command
  • can see that this registers models Moves and Position

terminal 3

• cd react-app
• Change VITE_PUBLIC_WORLD_ADDRESS in .env to same as above
• bun install && bun run dev

Trace

No response

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.