-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add substrate connect support to staking dashboard #166
Conversation
I can see that there are some numbers (e.g. Minimum Active Bond, Nominations (active, Inactive, list), Active Validators number) that is not returned to the dashboard when light client is used. I'll add a reminder to myself for that - and we should probably put some "experimental" asterisk when light client is used (as we did with polkadotJS/apps) |
These stats are derived from The fetching is done here, and the callback defined here. Is the light client fetching erasStakers successfully?
|
This fixes the issue. Next version of substrate-connect that will be released today will have that in. |
…esign so that choice menu is not weird
…and normal networks
Hi Nikos, I am having issues running this in Brave browser. The syncing hangs with 0 peers. Do we know what is causing this? On Chrome it is working well. Screenshots for context: Latest logs:
|
@wirednkod Perhaps a separate issue, I am also getting the following console errors on
|
We should open an issue for this.. Im not sure what is really triggering it... We have made some adjustments that may help warnings disappear in next version. |
There is some peculiar decision making with Brave since 1.36. In substrate connect extension we prepare a similar "note" on that for Brave users, and we have added also a note on the landing page. TLDR; |
Got it, thank you for the context. Would a good solution be some browser detection in-app and disable light client support where browsers are being problematic? |
Well we can do that, and its an easy solution, but its a pity to lose Brave users, due to a setting. IMO its better to throw a note for Brave users, that there is a setting that may create issues with websockets, rather than disable light client support. In addition, keep in mind that this is a temp solution, as we have in our roadmap the integration with WebRTC that will overcome these kind of issues |
…oard into nik-add-substrate-connect-support
@@ -24,6 +24,10 @@ export interface Networks { | |||
|
|||
export interface Network { | |||
name: string; | |||
endpoints: { | |||
rpc: string; | |||
lightClient: WellKnownChain; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should now always assume that a light client will exist.
This should be:
lightClient?: WellKnownChain;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, we are assuming they exist as all supported chains have a light client
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a case where they would not exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a case where they would not exist?
The only case is either a custom chain that supports staking or in case we do not want to include light client for a known chain (e.g. polkadot) inside the dashboard. This is of course something that can be altered on a later PR (current PR implementation supports the network UI when light client does not exist [e.g. shows full width button instead of split to 50/50 of RPC/Light client)
src/contexts/Api/index.tsx
Outdated
let _provider: WsProvider | ScProvider; | ||
if (_isLightClient && nodeEndpoint.lightClientEndpoint) { | ||
_provider = new ScProvider(nodeEndpoint.lightClientEndpoint); | ||
if (_isLightClient && endpoints.lightClient) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for the optional lightClient
parameter
if (_isLightClient && endpoints?.lightClient) {
Ready to merge. Please let me know if the optional light client flag is totally necessary, It is probably wise not to add complexity if not needed. |
Same for substrate connect extension. I will open a discussion about that so we can track it better. Dont know though where would be the best place to do so |
Add light client (substrate connect) support to available chains (Polkadot, Kusama, Westend);
Fixes #149;
Some screenshots that show the design result as well: