Thin gRPC wrapper around WalletManager #34
Conversation
…sure as the number of Layer-1 blocks.
…ary when wrapping WalletManager within a gRPC service.
…not the best and it is because now the inner components of WalletManager need to call the API of WalletManager.
# Conflicts: # examples/wallet-manager.ts # package-lock.json # package.json
…client side bugs.
Moving to a TS-first gRPC compilation solution
…t (minimal) interface.
|
We just added linting and formatting utilities to the project but actually triggering them would cause huge changes. It's best to trigger those utilities into another PR. |
src/utils.ts
Outdated
| // This function will return the same object with the minimal set of methods required to work for the | ||
| // requested context. | ||
| export function buildWalletManager(rawWMFullConfig: any): IClientWalletManager | ILibraryWalletManager { |
There was a problem hiding this comment.
I think we should type the param here. Since this is the actual interface that the user will see it's usefull to have it typed
There was a problem hiding this comment.
Mmm. This function is just parsing with a known schema for the full config and then deciding if it must return a client object or the library object. Maybe it's doing too much but if we type the argument like fullConfig: WalletManagerFullConfig, then we shift the burden of parsing to the developer (which may not know how to do it or may forget to do it).
Maybe the goal for this function is different from what I understood?
There was a problem hiding this comment.
What i mean is that ultimately this is the function that will be exposed to the user, won't it? So in that case, typing the parameter can be helpful for the user of the lib, IMO, since you can use the hints of the IDE to understand what the function is expecting as arguments. If the argument names are expressive enough, you might even get started without looking at any documentation
There was a problem hiding this comment.
Agreed. Changed as suggested.
# Conflicts: # README.md # examples/package-lock.json # package-lock.json # package.json
|
Missing documentation and then should be good to go |
| @@ -1,12 +1,17 @@ | |||
| { | |||
| "name": "@xlabs-xyz/wallet-monitor", | |||
| "version": "0.1.16", | |||
| "version": "0.2.0", | |||
|
🎉 |
Started fresh with a new branch name / draft PR because the old one was diverging too much from the original goal.
At this stage, there is a gRPC wrapper around the needed functionality of
WalletManageringrpc-wrapperfolder. There is also an example ofWalletManagerusing a stub object to hook into the gRPC service inexamples-dfolder.