Closed elliotBraem closed 6 months ago
Yes we should!
In the example here, window.location is used to determine whether to proxy, which exists as part of the runtime environment.
In our case, we'd want to pass that setting from the CLI which would mean some method of getting the rpc setting from the bos-workspace build script to the gateway's runtime code, correct? Which is independent of the gateway build (I was using nwc as a gateway). So you'd almost need to set a window rpc variable as part of the transpiling process bos-workspace does on the app file, right?
Am I thinking about this correctly?
@klngrs yeah that's a bit confusing, but it used window.location because I believe fast near is working on a paid/private RPC service (see tweet) -- when I updated bos-workspace to use lava rpc this past week, I only needed to set it in the config
param here.
And I believe this config param can be updated in runtime, multiple sites allow you to toggle the RPC (checkout the bottom right of ref.finance).
I think we could pass it to the web component like:
<near-social-viewer src={...} rpc={RPC_URL} />
And in dev, we know the rpc url is going to be from bos-workspace localhost:8080
, or whatever port was configured.
But I don't really know the best way to determine when in dev vs prod... maybe we start with just adding a toggle here. Any ideas here?
Side note... as another example/use case, I was messing with this other repo the other day. I added near-bos-wc script tags to index.html here, and then I used the web component here. I installed bos-workspace because I wanted to locally develop these widgets, too, but didn't want to configure all the redirect map stuff...
For context, this post and then comment
Fast Near was enabled on near.social gateway via this change here, line 97 -- Could we pass RPC the same way here?