Skip to content
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

feat: add connection-error component and account error state #2530

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

lujakob
Copy link
Contributor

@lujakob lujakob commented Jul 3, 2023

Describe the changes you have made in this PR

Add AccountMenu account error state. Add ConnectionError component.

Link this PR to an issue [optional]

Fixes #2377

Type of change

  • feat: New feature (non-breaking change which adds functionality)

Screenshots of the changes [optional]

Add screenshots to make your changes easier to understand. You can also add a video here.

How has this been tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist

  • Self-review of changed code
  • Manual testing
  • Added automated tests where applicable
  • Update Docs & Guides
  • For UI-related changes
  • Darkmode
  • Responsive layout

@lujakob
Copy link
Contributor Author

lujakob commented Jul 3, 2023

@reneaaron this is a working draft. Refinement (especially in styles) is needed, but you could check out my changes/architecture if you want. I broke the "/v1/getinfoo" GET request for the LND connector to simulate failing connections.

@github-actions
Copy link

github-actions bot commented Jul 3, 2023

🚀 Thanks for the pull request!

Here are the current build files for testing:

Download and unzip the file for your browser. Refer to the readme for detailed install instructions.

Don't forget: keep earning sats!

Copy link
Contributor

@reneaaron reneaaron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @lujakob! Left some first feedback, generally I think we are on the right track here. 👍

@@ -70,26 +71,37 @@ export const swrGetAccountInfo = async (
const accountsCache = await getAccountsCache();

return new Promise((resolve, reject) => {
if (accountsCache[id]) {
// don't apply cache for connectors that failed to connect
if (accountsCache[id] && !accountsCache[id].error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we keep accounts with errors out of the cache? Why would we cache them if we exclude them from the cache here? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it.

};
let account: AccountInfo;
if (response.error) {
account = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this case be handled in the catch() block here?

msg.request should throw an Error():

https://github.com/lujakob/lightning-browser-extension/blob/feat/not-reachable-error/src/common/lib/msg.ts#L19-L21

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your suggestion was my first approach. The problem is, the argument of throw new Error() is of type string. But I need to pass an object, to be able to get the name of the connector and error. To change this, I need to refactor dozens of places where msg.request is called in a try/catch block. So on the one hand this is really a big refactor, on the other hand I think what we do now is not completely wrong: we return a connector in error state, that has name as its only property. Considering these two points I opted for the current approach. (Maybe it doesn't feel so wrong for me, because I used this approach in other applications, where the error returns data and therefore is not dealt with as a real error) What do you think?

Comment on lines 62 to 72
const { account } = useAccount();
// keep last tries result, to prevent component flick during loading state
const [lastAccountFailed, setLastAccountFailed] = useState<boolean>(false);

useEffect(() => {
// skip the state during loading phase where only the id is present
if (Object.prototype.hasOwnProperty.call(account, "name")) {
setLastAccountFailed(!!account?.error);
}
}, [setLastAccountFailed, account]);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That feels a bit complex on the first sight. What is it that you want to prevent here?

Isn't it natural to go from error -> loading -> success / error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can disable it and see it. If you replace
{lastAccountFailed || account?.error ? <ConnectionError /> : <Outlet />} with
{account?.error ? <ConnectionError /> : <Outlet />} you see during the loading state after clicking on "Try again" you see the Outlet component for a short moment. A glitch...

<div
className={classNames(
direction === "row" ? "mr-2 flex justify-center min-w-[24px]" : ""
)}
Copy link
Contributor Author

@lujakob lujakob Jul 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reneaaron this change in styles is necessary, because having an icon and loading state results in a very small horizontal jump of the text, due to the rotating loading icon and the icon itself not having the same width. I'm kind of unsatisfied with this change, but I found no better way in preventing this rather annoying UX problem. Please have a look and let me know. You can revert by "show diff" branch master and revert the changes to see what I mean and then test clicking "Try again" button to see the jump.

@lujakob lujakob marked this pull request as ready for review July 13, 2023 17:27
@lujakob
Copy link
Contributor Author

lujakob commented Jul 13, 2023

@reneaaron I updated with master, abstracted the "connectionFailed" state to a hook function and added the connection error to the options page. I added extensive comments to the hook function for explanation. I think this is 95% done now, so let me know what you think. The LND getInfo request url is erroneous for testing. If you throttle/delay the network requests, you can see the loading spinner on the button and test the screen not flicking back to the normal content during loading.

@rolznz
Copy link
Contributor

rolznz commented Sep 4, 2023

We currently have an issue where if you're unable to connect to a connector, then it's impossible to use LNURL auth there. I think it would it make sense to be able to still switch connector, but it be in a failed state (like this). And you can still use the LNURL auth and master key features. What do you think? @lujakob @reneaaron @bumi

@reneaaron
Copy link
Contributor

Yeah, but that should be the case already, right? The failed state would only be reflected on the wallet page (but not in the prompts), right?

@rolznz
Copy link
Contributor

rolznz commented Sep 4, 2023

Yeah, but that should be the case already, right? The failed state would only be reflected on the wallet page (but not in the prompts), right?

I don't think this has been implemented yet. I can't see any change to how the connector init works so that it will still return the connector if it fails

@rolznz rolznz self-assigned this Sep 4, 2023
@lujakob
Copy link
Contributor Author

lujakob commented Sep 30, 2023

Yeah, but that should be the case already, right? The failed state would only be reflected on the wallet page (but not in the prompts), right?

I don't think this has been implemented yet. I can't see any change to how the connector init works so that it will still return the connector if it fails

@rolznz do you think it makes sense for me to look into this? I would need some more information as I don't have the full picture here.

My understanding of lnurl auth is it's a single sign on to log into websites. If I am on www.getalby.com and "login with lightning" the popup opens. Is this the whole thing or is there more to know? Why is there a path for the lnurl auth page in the Options.tsx?

By the way, how do you debug/test lnurl auth in dev mode? If I can successfully login to my www.getalby.com account with the production extension, but not with the dev mode extension.

Maybe a short chat would be helpful?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📝 To-Do
Development

Successfully merging this pull request may close these issues.

Improve handling of errors in connectors
3 participants