The idea of exposing a Web3 Namespace instead of a Web3 object will help the tree-shaking processes and will provide the required features for a multi-chain future. The idea is to import the specific modules and to have one global web3 namespace which is handling multiple providers and accounts.
The developer should be able to create one global context in the web3 namespace which is acting as a default context. A developer will also have the possibility to create differently named context objects in the web3 namespace which can inherit from each other. The global default context can also be set to another defined context with web3.set('myContext).
This feature will make Web3 multi-chain compatible without instantiating a new Web3 object.
Namespace Interface:
namespace web3 {
init(name: string, context: Context): web3; // Starts the web3 namespace with a default context
add(name: string, context: Context); // Adds a new context
reset(name: string); // Resets the default context
get(name: string): Context; // Returns a added context
}
Context Interface:
interface Context {
provider: AbstractSocketProvider | HttpProvider | CustomProvider
defaultAccount: string;
defaultBlock: string|number;
// ... all other known configuration properties from the Web3 modules.
}
import {web3, Eth} from 'web3';
web3.init('default', {provider: new WebsocketProvider(url, options)});
web3.add('http', {provider: new HttpProvider(url, options)});
const defaultContextEth = new Eth();
const httpContextEth = new Eth(web3.get('http'));
web3.reset('http');
const willUseTheHttpContextEth = new Eth();
web3.get('default'); // Returns the current default context
web3.get('http'); // Returns the Http context
Not possible.
This namespace idea could also be implemented as a standalone experimental module.
In our multi-chain implementation, we use multiple web3 objects and name them by chain. I'm trying to figure out how this approach would be better and I'm drawing a blank. Can you elaborate on "multi-chain future"?
It's a good feature @nivida. I think we should start with the experimental module. I am worried about which package we should add to the global namespace as like management module, which will not be used mostly and that will create overload to bundle size. Also regarding multichain support how we exactly gonna provide support?
@sshelton76
I'm trying to figure out how this approach would be better and I'm drawing a blank.
I think the biggest argument is to not load the complete Web3 library three times. It will use way more memory than to use the specific modules more than once.
Can you elaborate on "multi-chain future"?
I think there isn't really something to add. We will, and we already do connect in DApp's to different nodes and this should be supported in an intuitive way by the Web3 library.
@princesinha19
I am worried about which package we should add to the global namespace as like management module, which will not be used mostly and that will create overload to bundle size.
We can expose all modules as described in the example and tree-shaking will handle this for us.
Also regarding multichain support how we exactly gonna provide support?
With the interface as described above. :-)
I've created a POC module as a preview: https://github.com/ethereum/web3.js/tree/feature/namespace
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions
Most helpful comment
I've created a POC module as a preview: https://github.com/ethereum/web3.js/tree/feature/namespace