-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Example Plugin Implementation #5393
Conversation
|
Your Render PR Server URL is https://web3js-docs-pr-5393.onrender.com. Follow its progress at https://dashboard.render.com/static/srv-cc6n52pgp3jv8lhb6gb0. |
…e/web3.js into wyatt/4.x/5091-chainlink-plugin
|
This pull request introduces 1 alert when merging d0d388b into aeceed2 - view on LGTM.com new alerts:
|
|
This pull request introduces 1 alert when merging db296ff into aeceed2 - view on LGTM.com new alerts:
|
| "ts-jest": "^28.0.7", | ||
| "typescript": "^4.7.4" | ||
| }, | ||
| "dependencies": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should those be peerDependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure they can be since the plugin is actually importing the packages?
import { ContractAbi } from 'web3-eth-abi';
import Contract from 'web3-eth-contract';
import { Web3PluginBase } from 'web3-core';
import { Address, Web3APISpec } from 'web3-types';
// @ts-expect-error 'Web3' is declared but its value is never read.
import { Web3 } from 'web3/dist/web3';There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't really matter. The only difference here is if you put peer dependencies and set a broad range like ">=4.0.0 < 5" it will warn the user if he is supplying an invalid version, otherwise it would use his version. On the other hand, if you leave it as regular dep, it will install the plugin version of web3 along with a user-supplied version of web3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packages/web3/src/index.ts
Outdated
| * This comment _supports3_ [Markdown](https://marked.js.org/) | ||
| */ | ||
| import Web3 from './web3'; | ||
| import { Web3 } from './web3'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not do both module export and named export instead of just module export?
Named export generally works better with IDE (auto-import and type hinting)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this commit I've updated Web3 to be exported via default and named
| privateKey?: HexString | Buffer; | ||
| }) => Promise<ReturnType>; | ||
|
|
||
| export abstract class Web3PluginBase<API extends Web3APISpec> extends Web3Context<API> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is how the rest of the modules in web3 are built. The only issue I see with this is once we have plugins that depend on other plugins, types won't work because we are augmenting Web3 class and plugins are using Web3Context.
Alternative of top of my head would be:
export const plugin1 = {
namespace,
init: (web3: Web3) => Plugin1Api
}
declare module web3{
interface Web3 {
plugin1: Plugin1Api;
}
}
and if you require plugin1 in plugin2:
import plugin2 from "plugin2"
export const plugin1 = {
namespace,
needs: [plugin1.namespace]
// because we imported plugin2, Web3 class here will be augmented with plugin1 api
init: (web3: Web3) => Plugin1Api
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#5490 tracks this
| getPrice: () => Promise<Price>; | ||
| } | ||
|
|
||
| declare module 'web3/dist/web3' { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tested if end user imports Web3 from 'web3' (instead of 'web3/dist/web3') will they see augmented API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After this commit, Web3 is now exported as a named export which means this is now:
import { Web3 } from 'web3';
declare module 'web3'| import { Web3EthInterface } from './types'; | ||
| import { Web3PkgInfo } from './version'; | ||
|
|
||
| export default class Web3 extends Web3Context<EthExecutionAPI> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will break minified web3.js build #5345
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit updates Web3 to be exported via default and named. I've created a test example that uses the web3.min.js and calls various functions to ensure the minified build works
jdevcs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to keep this as example for others to implement plugins, :
web3-plugin-example example package should be placed under tools
|
|
||
| public constructor(abi: ContractAbi, address: Address) { | ||
| super(); | ||
| this._contract = new Contract(abi, address); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should leverage context coming via inheritance Web3PluginBase and use that to instantiate contract. Ideally with every usage there should not be need to check :
if (this._contract.currentProvider === undefined) this._contract.link(this); if context is used while instantiation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#5492 tracks this and there seems to be a bug with updating a context that was passed upon instantiation of Contract
|
This pull request introduces 1 alert when merging a2f43db into e2afb75 - view on LGTM.com new alerts:
|
Muhammad-Altabba
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great beside tiny stuff in addition to the already mentioned points by other reviewers.
…e/web3.js into wyatt/4.x/5091-chainlink-plugin
Co-authored-by: Muhammad Altabba <[email protected]>
…e/web3.js into wyatt/4.x/5091-chainlink-plugin
Co-authored-by: Muhammad Altabba <[email protected]>
Co-authored-by: Muhammad Altabba <[email protected]>
| '0xc41b9a4f654c44552e135f770945916f57c069b80326f9a5f843e613491ab6b1'; | ||
|
|
||
| requestManagerSendSpy.mockResolvedValueOnce(expectedGasPrice); | ||
| // Not sure what's being mocked here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we, please, have an issue for investigating the matter and enhancing this piece of code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed by this commit
Example implementation for #5091
Unresolved Issues
registerPlugin#5491Web3Contextshould update when.linkis used on plugin #5492Points of Discussion
I believe theWeb3APISpecon this line should beChainlinkPluginAPI, but when making the change the following error appears for thisAttempted fixes for this include: Fix typing compatibility when linking a contract to a context #5416 andWeb3ContextGeneric Fix #5480In order to get the declare module to work, I needed to update the Web3 package from using theThis commit updatesdefaultexport to a named one - I'm not sure if/how this affects anythingWeb3to be exported usingdefaultand named exportRelated to this change, importingThe above mentioned commit also updates this to useWeb3like this is the only way I could get the module augmentation to workweb3to augment module instead ofweb3/dist/web3The return type for getPrice is inferred from the contract ABI instead ofChainlinkPluginAPIThis doesn't matter so much because the type the end user will see when callingweb3.chainlink.getPriceis defined byChainlinkPluginAPI(i.e. user will seegetPricereturnsPromise<Price>)