Reduce dependency on the VM

[gagdiez]

Currently, the BOS VM is loaded and initialized on every single page - even those that do not depend on it. This creates a lot of delay for page loading, and even slows down the initialization of the wallet (which should be instant, and instead takes a couple of seconds waiting for the VM to load).

This PR separates the wallet selector (used to login) from the loading and initialization of the VM (used to render components), and makes sure that the VM is only loaded when a component has to be rendered.

Separating the VM from the wallet selector allows a couple of improvements:

• The user can see that they are logged in without needing to wait for the VM to be loaded
• Pages that do not rely on the VM load much faster, since they do not need to wait for the VM to load

closes #1264

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
beta.near.org	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 26, 2024 5:44pm
dev-near-org	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 26, 2024 5:44pm
near-discovery-testnet	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 26, 2024 5:44pm

[calebjacob]

Thanks for taking this on @gagdiez! One thing I'm hesitant on with this refactoring is the confusion it creates for knowing when to use useAuthStore() vs useContext(NearContext). I'm pretty familiar with this codebase and I have to admit that I'm already a bit confused.

I might suggest picking one of these routes to continue the refactor before merging:

1. Completely remove stores/auth.ts and refactor away all uses of useAuthStore().
2. Rework your initialization logic to store state in stores/auth.ts so that we can continue with our familiar pattern of useAuthStore() - in this way we wouldn't be calling useContext(NearContext) directly and would probably delete NearContext all together.

I would probably lean towards option 2 since Zustand tends to make our interactions more consistent as complexities grow.

What do you think @shelegdmitriy?

[shelegdmitriy]

I like the usage of useContext but I'd stick with our familiar pattern of useAuthStore()

[gagdiez]

Sure, I can go back to the useStore, I used context because I thought it was more standard practice, but happy to use the existing pattern

[calebjacob]

Either way works for me @gagdiez! I think the only important thing is to make sure we only have one source of truth for auth/wallet state and interactions (right now it's kind of split between store/auth and the NearContext).

[gagdiez]

@calebjacob migrated everything to use context. I might need some help with the rxjs since I have no idea what it is actually doing.

[calebjacob]

@gagdiez Nice! This is how I've always interacted with it without rxjs:

const subscription = selector.store.observable.subscribe(async (value) => {
  setState(value);
  setAccount(value?.accounts[0] ?? null);

  if (value.accounts.length > 0 && value.selectedWalletId && selector) {
    const wallet = await selector.wallet();
    setWallet(wallet);
  } else {
    setWallet(null);
  }
});

Wherever you have cleanup or unmount logic, you can unsubscribe:

subscription.unsubscribe();

[gagdiez]

@calebjacob thanks! I changed the code to not use rxjs, this is ready for a final review