The future of the Javascript SDK
Some updates and a look behind the scene
Dear fellow magesđ§ââď¸. Today I want to update you on something exiting about the JavaScript SDK. We are working on a new version with a lot of improvements. A lot of these updates are technical so we can scale and maintain the code better in the future. But it also comes with a lot of developer experience improvements for you.
I will share you now some insights and behind the scenes in this and upcoming posts.
More info about updates and the early alpha release for tester and early adopters is coming soon.
Some highlights
The SDK is being redesigned from the ground up, with a few reasons in mind:
- First-class typescript support for better dev-experience for you
- More consistent data across the whole sdk (no more need to concern about lowercase addresses, and chainIds that are a hex-string or decimal)
- A lot of easy accessible utilities on dataTypes (converting a value to Wei, Gwei etc, or reading block explorer links on transactions)
- More scalable in the future and better to maintain
- Modular system so you can choose what features to install and reduce your package size.
- With this modular system, you or third-parties can even expand upon the sdk
- Future proof of adaptation for new networks. We will not assume anymore that EVM/Ethereum is the default network. We can scale to as many networks as we want
Typescript
We are moving to first-class Typescript support. So everything is written in Typescript, which results in no more types that are outdated, provide with an amazing dev-experience (both for us internally, and for you developers)
Monorepo
We are moving towards a monorepo. What this means is that we will subdivide the library in smaller packages. Each domain within the sdk as a separate package. This is good for us in maintain our codebase.
But this also allow you to only install dedicated packages (for example if you are only concerned about the EvmApi, then you donât have all the code included regarding servers etc). This is an optional feature, you can also choose to install all the features by just installing the âumbrellaâ Moralis package.
Example of what using the umbrella package will look like (spoiler alert: not a lot will change regarding v1)
Import Moralis from âmoralisâ
// Start Moralis
Moralis.start(config)
// You will have access to ALL modules, each accessed in its own namespace
Moralis.Server.authenticate()
Moralis.Evm.connect()
Moralis.EvmApi.account.getNFTs()
// Some functionalities will also be forwarded to the Moralis namespace for easy access. For example:
Moralis.authenticate()
Example of only using only a few packages: in this case: the server and evm
// Importing the core module is always required when using individual packages, as it serves for communication and initialisation between packages
Import MoralisCore from â@moralisweb3/coreâ
// Import the modules that you want to use
Import MoralisEvm from â@moralisweb3/evmâ
Import MoralisServer from â@moralisweb3/serverâ
// Register the modules to the core package
MoralisCore.registerModules([MoralisEvm, MoralisServer])
// Now you can use any functionality of these packages
MoralisEvm.connect()
MoralisServer.authenticate()
With the introduction of a Monorepo, we will also move all âconnectorsâ (Metamask, Walletconnect, Magic etc.) to its own package. This way no code or dependencies gets added in your app if youâre not using these connectors. This also resolves some errors we have in v1 of the sdk where users get error messages about missing dependencies.
Example usage:
Import {WalletConnectConnector} from â@moralisweb3/walletconnect-connectorâ
Moralis.Evm.wallets.register(WalletConnectConnector)
// Now users can connect/authenticate via
Moralis.Evm.connect({connector: âwalletconnectâ})
Data consistency
We are implementing a consistent way of handling data within Moralis. So no more issues regarding chainIdâs where you have to check if it is 0x1 or 1. And no more checking if an address is a lowercased address, or when it is a checksum address (address with capital symbols in it). In both cases you will always get an EvmChain object or an EvmAddress object. We also implement a way of data consistency in this between Evm functionalities (such as transferring tokens) and getting data from the api.
An example use case for this is:
You connect to an Eve chain via metamask.
After connecting you get back an EvmAddress
To read value from this address you can use functionalities as:
// This will give you the chain after successful connection (this is an instance of EvmChain)
const chain = Moralis.Evm.chain
// To read the values
chain.hex // -> â0x1â
chain.decimal; // -> 1
// Read additional data
chain.currency // => {name: âEtherâ, symbol: âETHâ, decimals: 18}
chain.rpcUrls // => list of urls
// equality checks can be in any format, or even another EvmChain instance
chain.equals(1) // -> true
chain.equals(â0x1â) // -> true
const otherChain = new EvmChain(1)
chain.equals(otherChain) // -> true
This provides with a lot of utility functions and data consistencies. This same EvmChain instance can also be used as parameters in other functions or api interaction (without converting it to hex or decimals).
This functionality will be used to almost all complex data types where we want to specify formatting on, or where we want to give you utilities.
Everything is still work-in-progress. But if youâre curious then you can see the code at https://github.com/MoralisWeb3/Moralis-JS-SDK/tree/sdkv2
âŚMore updates coming soon, stay tuned
