Potential Future API design

[kesne]

The current API design is heavily hook-based, which makes sense given some of our current constraints and design inspiration. However, as we continue to evolve the API and lean more and more into the suspense- and concurrent- based API patterns, we can simplify the API design so that it does not depend as heavily on hooks.

One of the benefits of this API design is that all of the non-hook APIs can be called conditionally, instead of needing to be called unconditionally to follow the rules of hooks.

A note on providers

The core of providers shouldn't need any work, as they are the most foundational piece of the library, and must exist in react context.

• useLogout - This API is probably fine, as it just returns a method that uses a value read out of the context.
• useWeb3Modal - This is only for advanced use-cases, and just reads a value out of context.
• WalletProvider - This initializes some values into a context, and renders a Provider.
• Provider - This just provides values into context.
• useProvider - This just reads values out of the context.

Thick Providers

I still need to write about this in more depth, but the TL;DR is that we'll have a new provider class, which has the following:

• Built-in cache response.
• Methods on the provider that trigger suspsense.

const provider = useProvider();
const address = provider.getUserAddress();
const balance = provider.getBalance(address);

We probably should figure out a new name for provider with this though.

Downsides:

• Always requires a call to get the provider.
• Lack of hooks means we can't effectively retain + LRU cache responses, potentially infinite cache growth.