|
| 1 | +# What's Next for Dojo.js |
| 2 | + |
| 3 | +This roadmap captures the near-to-mid term architecture initiatives planned for the main branch. Each stream lists intent, key activities, and expected outcomes to inform prioritisation and sequencing. |
| 4 | + |
| 5 | +## 1. Revamped Type System |
| 6 | + |
| 7 | +- **Objective**: Replace the existing world/type plumbing with the new type system in `packages/core/src/types` to improve safety and compatibility with Cairo models. |
| 8 | +- **Key Steps**: |
| 9 | + 1. Audit current exports and downstream usage across `core`, `sdk`, `state`, and `react` packages. |
| 10 | + 2. Implement adapters or codemods to bridge the new types with legacy consumers while migration is in progress. |
| 11 | + 3. Expand compiler/test coverage to prevent regressions (e.g., schema parsing, manifests, provider actions). |
| 12 | +- **Deliverables**: Updated type definitions, migration guide, comprehensive test suite for the new abstractions. |
| 13 | + |
| 14 | +## 2. Framework-Agnostic Application Bindings |
| 15 | + |
| 16 | +- **Objective**: Reduce React-specific hooks in favour of framework-agnostic bindings that can power multiple UI layers. |
| 17 | +- **Key Steps**: |
| 18 | + 1. Extract core data subscription logic (currently in `@dojoengine/react`) into reusable primitives (signals, observables, store interfaces). |
| 19 | + 2. Provide thin React adapters while enabling alternative bindings (e.g., Solid, Vue, Svelte) to consume the same core APIs. |
| 20 | + 3. Update examples and documentation to highlight the framework-neutral approach. |
| 21 | +- **Deliverables**: Core binding package with React wrapper, updated samples, migration notes. |
| 22 | + |
| 23 | +## 3. Abstract Starknet.js Dependencies |
| 24 | + |
| 25 | +- **Objective**: Introduce an abstraction layer over Starknet.js so that downstream packages can swap providers or polyfill functionality. |
| 26 | +- **Key Steps**: |
| 27 | + 1. Identify all points where Starknet.js types/classes are imported directly (providers, accounts, signing flows). |
| 28 | + 2. Define an interface-based contract (e.g., `IStarknetTransport`, `Signer`, `AccountAdapter`) and implement default Starknet.js adapters. |
| 29 | + 3. Provide dependency injection hooks in SDK/provider constructors and document how to supply alternative transports. |
| 30 | +- **Deliverables**: Adapter interfaces, default Starknet.js implementation, updated dependency guidelines. |
| 31 | + |
| 32 | +## 4. TanStack/DB Integration |
| 33 | + |
| 34 | +- **Objective**: Leverage TanStack DB for richer client-side entity persistence, caching, and querying. |
| 35 | +- **Key Steps**: |
| 36 | + 1. Experiment with a proof-of-concept mapping Torii entity snapshots into TanStack DB tables. |
| 37 | + 2. Define schema generation rules based on Dojo manifests and integrate with state management. |
| 38 | + 3. Expose opt-in APIs within the SDK or a companion package for consuming TanStack DB features. |
| 39 | +- **Deliverables**: Prototype integration, API surface proposal, pilot example demonstrating offline/query benefits. |
| 40 | + |
| 41 | +## 5. Native gRPC Client Enhancements |
| 42 | + |
| 43 | +- **Objective**: Continue maturing the native gRPC client for reliability and feature completeness. |
| 44 | +- **Key Steps**: |
| 45 | + 1. Close remaining parity gaps with Torii WASM client (subscriptions, controllers, token operations). |
| 46 | + 2. Harden connection lifecycle management (reconnects, backoff, streaming ergonomics). |
| 47 | + 3. Ship performance benchmarks and cross-platform validation (Node, Bun, browser with WASM transport). |
| 48 | +- **Deliverables**: Stable gRPC client API, resilience improvements, documentation and benchmarks. |
| 49 | + |
| 50 | +## 6. Frontend Observability Integrations |
| 51 | + |
| 52 | +- **Objective**: Provide opt-in hooks to plug observability tools (Sentry, PostHog, etc.) into Dojo.js-powered apps. |
| 53 | +- **Key Steps**: |
| 54 | + 1. Define instrumentation points (SDK events, subscription lifecycle, transaction workflows). |
| 55 | + 2. Create lightweight adapters for popular observability providers with configuration patterns. |
| 56 | + 3. Document best practices and privacy considerations for instrumenting on-chain interactions. |
| 57 | +- **Deliverables**: Observability integration guide, reference adapters, example instrumentation snippets. |
| 58 | + |
| 59 | +## Cross-Cutting Considerations |
| 60 | + |
| 61 | +- Prioritise documentation and migration notes alongside each feature. |
| 62 | +- Invest in automated tests and benchmarks as new abstractions are introduced to safeguard performance and developer experience. |
0 commit comments