site: Notify users when connecting wallets fail

[ukane-philemon]

Closes # 2241

UI changes:

@norwnd (#2241): As a sidenote, I'm not even sure why this connect button is there in the first place , wouldn't it be better to try re-connect wallet automatically every 30s or something?

This part is not handled in this PR. @chappjc, what do you think?

IMO, using a reconnect loop for wallet connection when are not sure that we will ever connect seems to be undesirable. Wallet connection will be attempted in any part of the client code that requires a connected wallet, plus, like the note above, If a user is missing wallet files, we are going to try forever until they take action.

[chappjc]

Yeah, I don't want to replace the connect button with a background reconnect loop.

Regarding any error from connect, I'm pretty sure we're trying to show errors on the page or form near the UI element interaction that generated the error, not the notification menu (or the transient "pokes" that don't give you much time to digest the error). #1712 (comment)

[buck54321]

I'd prefer to show the message on the page rather than as a tooltip.

[chappjc]

How about an error message "form" that opens up with the messgae, so we don't have to pre-allocate real estate for a possible error?

[buck54321]

How about an error message "form" that opens up with the messgae, so we don't have to pre-allocate real estate for a possible error?

Pre-allocating page space is the simpler option. The "form" you mention, as I understand, is an interactive (probably modal) dialog that would explain the error and possibly provide guidance or options for resolution. I do agree that such an experience is desirable. I'm not sure that we should try that in this PR.

[chappjc]

Yeah, just something you can close when done reading. But didn't mean to suggest we try to provide resolutions or anything smarter that just showing the error.
It's fine to drop the error in div or something on the page. It can be hidden so it doesn't eat space unless needed. I just didn't want to sacrifice layout quality

[ukane-philemon]

I just didn't want to sacrifice layout quality

Yup, these errors can be ugly and I don't quite get where in the page @buck54321 wants this kind of error message since the table where the connect btn is located already has a lot.

[buck54321]

I just didn't want to sacrifice layout quality

Yup, these errors can be ugly and I don't quite get where in the page @buck54321 wants this kind of error message since the table where the connect btn is located already has a lot.

Just to echo @chappjc above

I'm pretty sure we're trying to show errors on the page or form near the UI element interaction that generated the error

I think it looks alright on the page.

buck54321/dcrdex@d165f1f...buck54321:dcrdex:ukaine-connect-err-on-page

[ukane-philemon]

I think it looks alright on the page.

For long errors like the eth error in my PR comment, it will easily look very ugly IMO. But if you want to, we can dump everything below the button.

EDIT:

It's an awfully bad display of lengthy error messages.

I do agree that such an experience is desirable. I'm not sure that we should try that in this PR.

If using a tooltip is not a good resolution to this, we can use a general error modal that can be closed by the user when they are done reading and digesting the error, showing the whole error on the page beside the connect btn does not look desirable IMO.

[chappjc]

If using a tooltip is not a good resolution to this, we can use a general error modal that can be closed by the user when they are done reading and digesting the error, showing the whole error on the page beside the connect btn does not look desirable IMO.

A tooltip is not, I think we agree. Sure, give the modal a try quick. We just don't want a major production over this.

[ukane-philemon]

EDIT: UI changes.

[chappjc]

Seems alright I guess. The work "Message" in "Error Message" is not needed though. It's more like "Connect Error". I also figured we'd have an "x" at the top right like all the other forms instead of an "Ok" button. BTW, it's "OK" not "Ok"

[chappjc]

Anyway, you and @buck54321 work out where to put the error, but IMO it gets messy putting it right next to the button. I think the dialog form that opens is a good compromise because you can't ignore it like tooltips and notifications, and it doesn't touch the page layout.

[ukane-philemon]

I also figured we'd have an "x" at the top right like all the other forms instead of an "Ok" button.

I think it's better they acknowledge that they have seen the error, the x at the top is usually for form dismissal but we can have that instead of the btn if that's better or keep both?

It's more like "Connect Error"

I wanted to be more flexible instead of tying the modal to only Connect Error.

[chappjc]

I think it's better they acknowledge that they have seen the error, the x at the top is usually for form dismissal but we can have that instead of the btn if that's better or keep both?

Whatever really. The button just looks funny. It's chunky and big, and requires a translation (!).

I wanted to be more flexible instead of tying the modal to only Connect Error.

Of course, but the "Connect" part can be a variable inserted by the JS caller. If that's not trivial for whaterver reason, just "Error" is preferable to "Error Message", which looks silly.

[ukane-philemon]

Updated the images above.

[buck54321]

Please consider buck54321/dcrdex@1e50d26...buck54321:dcrdex:error-modal-in-forms

[ukane-philemon]

Please consider buck54321/dcrdex@1e50d26...buck54321:dcrdex:error-modal-in-forms

I could use the existing form structure we have(less code) but the modal is not a "form". Still, we can run with your suggestion, I understand you prefer less code in this case.

EDIT: Done, reduced to one commit : cb81957

[buck54321]

I could use the existing form structure we have(less code) but the modal is not a "form". Still, we can run with your suggestion, I understand you prefer less code in this case.

It's not about less code. The existing forms are modal, since they prevent page interaction until the form is submitted or dismissed. No reason to reinvent the wheel.

[chappjc]

Also, this isn't the first form used this way. The "Export Wallet" form is also purely informational:

(don't bother with the key, it's simnet)

[ukane-philemon]

Noted.