-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Version: v6! #37
Comments
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 |
Idea for a Add a new default connector called Thanks! |
I'd also suggest adding a documentation push for |
I use yarn workspaces to structure my repo like this:
Both 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 @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 Great to hear about the update! |
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 |
@sohkai totally! the large bundle always annoyed me, and i was never fully satisfied with 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 |
@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/[email protected] |
I'm currently using the custom InjectorConnector and NetworkOnlyConnector from the Uniswap repo. If I switch to |
@PaulRBerg in theory yes! (but it's not quite ready yet 😛) also, i haven't ported the network connector yet |
some updates:
|
last 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!! |
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!
The text was updated successfully, but these errors were encountered: