Discusses #7

[klngrs]

Looking for assistance getting the rpc param to actually rerender the widget. Not sure of the redirectMap schema...

Context: https://github.com/NEARBuilders/near-bos-webcomponent/issues/7 Demo: https://cloudflare-ipfs.com/ipfs/QmS1AryveoGbC4BWD4wm1CcxkbzrGJDfGS5BVS9HbK1i8P

[petersalomonsen]

Left comments -- I think this change looks good after removing the useEffect for redirectMap.

For context -- when we try to load widgets in code via <Widget src="efiz.near/widget/Tree, we are fetching the code from on chain via an RPC request in the VM. Although during local development, rather than send an rpc request, we first check if this src ("efiz.near/widget/Tree") key exists in the "redirectMap" served from bos-workspace. If the key exists, we get the code from the map -- this check happens in the VM here.

I think the next step in this solution would be a change to bos-workspace. So that during local development, we would pass a local rpc address instead, coming from the local bos-workspace server, to act as a proxy to true RPC. The check against the redirectMap, which bos-workspace is building, will happen here, rather than in the VM. This change would probably happen here: bos-workspace/lib/dev.ts

@petersalomonsen would you agree with this?

The same approach is actually used for playwright tests in DevHub as you can see here: https://github.com/NEAR-DevHub/neardevhub-bos/blob/main/playwright-tests/util/bos-loader.js. So yes, going through an RPC proxy should be a good approach.

Let us figure out the appropriate way to configure this for near-bos-webcomponent.

[elliotBraem]

I started an implementation for how I thought it would work with bos-workspace -- there is a draft pr here: https://github.com/NEARBuilders/bos-workspace/pull/80

It doesn't work yet, I think next I'd want to write some tests rather than hoping it'll work -- but my thought is that this locally served rpc proxy (http://127.0.0.1:8080/rpc) would be what is passed to near-bos-webcomponent here

I get this strange issue: the mock request is getting 200, I see correct req.params, etc... but I'm unable to forward the request to fetch("mainnet") -- I get a "failure to fetch". Maybe because of different origins?

[klngrs]

Cool, thanks all. And thanks @petersalomonsen for the redirectMap explanation. The location of where the redirect was happening was escaping me, but this makes more sense now.

Looks like @elliotBraem is applying the proxy as middleware in the server gateway code.

[elliotBraem]

bos-workspace now supports rpc url via https://github.com/NEARBuilders/bos-workspace/pull/80

URL: http://127.0.0.1:8080/api/proxy-rpc

[petersalomonsen]

would be great with a playwright test that instantiate the webcomponent with and without the rpc option, and with different RPCs. That would be a live example of how to use it.

[elliotBraem]

I've opened up a PR that builds off of this one, (please review #11) -- @klngrs I've invited you as a collaborator

I included two tests -- one without the rpc option and one with a custom value.

It works when I input the rpc url manually within the app itself, but not when it is passed via the parameter. It seems that rpc is initially undefined during connectedCallback, so it falls back to default, then it sets correctly with attributeChangedCallback (see logs), but the default rpc is already being used.

Because of this custom rpc url test fails, but default test passes -- any ideas on to fix this?

[elliotBraem]

Closing this discussion with merging #11