Lazy Load Provider

[shunkakinoki]

Thank you for an amazing repo!

Just wanted to ask you, is there any way to lazy load the provider?
If so, is there any recommended way to do this?
Would love to learn.

(It would be nice to not having to put the provider in _app.js in next.js, and rather lazy loading it for example)

[tmm]

Can think of some approaches that might work, but need to know more.

Why do you want to lazy load Provider?

[shunkakinoki]

To keep the first load JS size lower!

It's a web optimization thing, but if we could combine #28 and have some onMount hook that loads the Provider too on the client side, just thought it would lead to less boilerplate too!

[tmm]

I haven't tried yet, but you could try loading the Provider next/dynamic.

Also, broke out connectors to separate entrypoints so the final bundle is smaller if you don't want to use specific connectors (i.e. WalletLinkConnector).

[shrugs]

@tmm unfortunately the Provider is a required parent for any of the child hooks to render, which means we can't just next/dynamic it. the ideal solution i think is to allow lazy-loading the connectors prop, ideally with something like getConnectors which takes a ({chainId}) => Promise<Connector[]>. that way the default bundle won't need to include the beefy walletconnect/walletlink libs (which weight in at 176kb of first-run js in my app) until it's demanded by the app

[shrugs]

after some tests, the first-load js penalty for including wagmi/Provider (without any connectors or providers, just <Provider />) is 141kb, which is a bit large i think. wallet connect accounts for some 50kb. not sure what is causing the 141kb first-run js though.

[seeARMS]

+1 on this discussion. wagmi is increasing the first-load JS of my pages pretty significantly (even on pages where there's no need to run any child hooks). A bunch of my pages are statically rendered in NextJS, and this first-load js increase is bringing down the lighthouse scores a bit.

next-bundle-analyzer is showing @ethersproject is 77kb gzipped; aes-js is 17kb gzipped; and bn.js is 11kb gzipped (presumably all of which are deps of this).

[albertpurnama]

Hey @shunkakinoki,

I've used wagmi and lazy loaded the Provider. I've opened a PR with details on how to accomplish this:
#282

I'd also love to get @shrugs's thoughts on this since your comment here suggests that this is not possible. I might be missing something huge here. 🙏

cc @tmm

[shrugs]

i tried something similar back when i wrote that, and when loading a page under a dynamic Provider, the hooks threw on first render since they expected to be able to useContext that the Provider supplies (https://github.com/tmm/wagmi/blob/main/packages/react/src/context.ts#L185) — this may have changed in recent versions of wagmi, though, making this possible?

[bigint]

This is really huge

cc @tmm

[albertpurnama]

See my answer above, it might help you cut down those shared first load js

#32 (comment)

[shrugs]

@albertputrapurnama ah, I've tested this out and figured out what's happening. by making the provider itself dynamic, none of the app can load until that dynamic component is loaded, so that first run js is being executed anyway it's just hidden behind one more server request, which is almost certainly less efficient than including it in the initial bundle and running it anyway. the nextjs firstload just doesn't measure that correctly, since that js is technically code-split out.

[albertpurnama]

You're right, it will indeed prevent entire page to load. The first load JS is technically correct though, but it's not really helpful because the whole page is not being rendered anyway until the Provider is loaded. Taking the Provider into a React.Suspense will also not work because I think the hooks that we used inside the component will get angry.

Do you think there's any way for the hooks to somewhat wait for the provider to be loaded? Like put the hooks a non initialized state until the provider is loaded? At least this way, if we put the provider at the root, we can still render the other parts of the pages that doesn't necessarily require the web3 hooks to render first. Therefore, making the site faster & snappier.

Thank you @shrugs for the further investigation!