Closed NoahZinsmeister closed 4 years ago
Sounds great! It would be cool to get the project listed on Gitcoin Grants (and perhaps GitHub Sponsors too) so there’s more money to throw at this initiative.
Thoughts on moving the repo to its own org to decentralize work on it slightly?
@pcowgill thanks for the support, i will consider adding the project to gitcoin/github sponsors!
i think for now i'd prefer to keep the project under my github (given that i'll still be the one pushing updates to npm, etc.), but i'm certainly open to a more collaborative approach w/r/t development! i think this will become easier as i build out a basic framework for this next version.
update: going to be working out of the v6
branch!
Idea for a v6
feature:
Add a new default connector called NetworkWithInDappSigner
and rename NetworkOnly
to NetworkReadOnly
like I mentioned here.
Thanks!
I'd also suggest adding a documentation push for v6
. The info hierarchy of the docs for a newcomer to the lib isn't as intuitive as it could be. Some info I needed I ended up finding eventually, but it would have been nice to have it more prominently featured. Small changes to the docs could push users towards the most helpful info first.
I use yarn workspaces to structure my repo like this:
- packages
- react-hooks
- foo
- bar
Both foo
and bar
use react-hooks
(all namespaced with @sablier
). The problem I have is that I need to pull out of react-hooks
the Hooks that depend on useWeb3Context
, because the values returned are all undefined. Therefore, I have some amount of duplicated code, and if I am to create yet another package that depends on useWeb3Context
, I'll copy and paste the code again.
I'm not sure whether sharing context state between packages is inherently not possible in React, or something that's missing in the current version of web3-react, so pardon me if it's the former.
@pcowgill noted, let's keep thinking about the NetworkOnly
name/docs stuff! and yes in general i hope to make the docs clearer :)
@PaulRBerg not 100% sure what you mean but i think your intuition is correct and state cannot be shared in that way. web3-react is meant to be consumed in a single react app/root.
also, a general update: https://twitter.com/NoahZinsmeister/status/1193711679781163008. hoping to have semi-working code pushed sometime this week (metamask-only to start)
Fwiw the issue was that I had different versions of web3-react
in those packages, hence a different instance of React was getting bundled, hence the Contexts were different.
Great to hear about the update!
Migration to lerna monorepo (publish core and individual connectors separately)
This would be really interesting; the current bundle size of this package is quite large at the current time, given that its meant to be a DX wrapper around web3 instances in a React application.
It could be that the bundle size appears to be more bloated than reality, since some of the dependencies might be required anyway by a web3.js or ethers.js, but including @0x/subproviders
just for a trezor connection (that I might not use) is painful.
@sohkai totally! the large bundle always annoyed me, and i was never fully satisfied with @0x/subproviders
. also i could never get dynamic imports to work correctly so i had to rely on passing in api
arguments to connectors which needed external dependencies, which was also annoying.
i'm laser-focused on minimizing dependencies in v6 with the help of the monorepo, and connector dependencies will all be scoped to the specific package they're required in.
beta version up on npm, works with injected and walletconnector connectors atm.
also @pcowgill i created a gitcoin grant and applied to the github sponsors waitlist
also @pcowgill i created a gitcoin grant and applied to the github sponsors waitlist
@NoahZinsmeister Glad to hear it!!
some bugs squashed, and fortmatic + portis connectors added!
now is a good time to start checking out the code/reporting bugs, if anyone is feeling motivated :)
also, check out these bundle sizes @sohkai !
https://bundlephobia.com/result?p=@web3-react/core@6.0.0-beta.8 https://bundlephobia.com/result?p=@web3-react/injected-connector@6.0.0-beta.8
I'm currently using the custom InjectorConnector and NetworkOnlyConnector from the Uniswap repo. If I switch to 6.0.0-beta.8
, can I remove them (and the polling is handled correctly)?
@PaulRBerg in theory yes! (but it's not quite ready yet 😛)
also, i haven't ported the network connector yet
some updates:
network
and walletlink
connectorsactivate
function of connectors with an sdk dependency (fortmatic, portis, etc.), which is really nice for initial load-times. (see e.g. https://github.com/NoahZinsmeister/web3-react/blob/v6/packages/portis-connector/src/index.ts#L69)@0x/subproviders
(the main package where we need to do this) isn't tree-shaking appropriately (see https://github.com/0xProject/0x-monorepo/issues/1400), so i'll be working around that going forward (for now, i decided to use a direct import, see https://github.com/NoahZinsmeister/web3-react/blob/v6/packages/network-connector/src/index.ts#L4), though i'm somewhat open to dropping the dependency altogetherlast set of connectors that i'm planning to be ready for the initial v6 release are published! (frame, ledger, trezor, authereum, squarelink, torus)
next and final steps for the mvp release are:
alright all, we're getting close! i'm dog-fooding the latest v6 release on https://uniswap.exchange, and for the most part everything's been pretty smooth. aiming to publish a stable release (with some more/improved docs) before the new year!
we did it!! yarn add @web3-react/*@latest
(6.0.2)
Congrats!
Hi
web3-react
peeps! I want to give everyone a status update on the future development of the project.While I'm open to being proved wrong, I consider the overall design of
web3-react
to be sound (using React context to pass down relevant web3-related manager functions and descriptive variables with a generic connector format for specifying requirements specific to different providers). However, I think the current codebase leaves something to be desired in terms of thoughtfulness around function memoization, provider initialization, error messages, multiple simultaneous provider support, etc.I have a basic framework in my head for how I'd like to structure the next version of the library to address some of these issues, but unfortunately not too much time to work on it.
I'm going to note down some of these ideas here, and set a tentative deadline of 1/1/2020 to get a beta version of the new architecture published.
Feel free to use this thread as a sounding board for questions/suggestions/comments/ etc. Thanks for your interest in the library, and I hope you'll continue to follow along as it continues to evolve!