Add loading indicator for each tab and add error screens for errors in each tab

[jerelmiller]

[relativeci]

#790 Bundle Size — 1.51MiB (+0.45%).

54ce7e9(current) vs 756cf06 main#785(baseline)

Warning

Bundle contains 13 duplicate packages – View duplicate packages

Warning

Bundle introduced one new package: react-error-boundary – View changed packages

Bundle metrics   5 changes 2 regressions

	Current #790	Baseline #785
Initial JS	1.47MiB(+0.46%)	1.46MiB
Initial CSS	0B	0B
Cache Invalidation	92.81%	0%
Chunks	5	5
Assets	12	12
Modules	1213(+0.25%)	1210
Duplicate Modules	45	45
Duplicate Code	3.07%(-0.32%)	3.08%
Packages	183(+0.55%)	182
Duplicate Packages	10	10

Bundle size by type   1 change 1 regression

	Current #790	Baseline #785
JS	1.47MiB (+0.46%)	1.46MiB
IMG	35.85KiB	35.85KiB
HTML	810B	810B
Other	778B	778B

Bundle analysis report Branch jerel/loading-error-indicator Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[phryneas]

If I add something along the lines of

  if (2 > 1)
    throw new ApolloError({ networkError: new Error("Network error") });

here, the whole extension always ends up in a "Client not found" state.

Could you look into that a bit more?

[jerelmiller]

I'm not sure I follow. Let's connect tomorrow (Tuesday).

Edit: I think I understand now that you're adding this arbitrarily to see how the UI behaves as if that error had occurred (that 2 > 1 is so that you can create an "always true" condition ya?).

I'd still love to connect to understand what you're looking for here. I'm intentionally taking over the whole screen to show the error since any error here is unexpected and usually means we can't communicate with the content scripts but perhaps you have some better ideas.

[phryneas]

Yeah, the 2>1 is to keep the TS compiler from yelling that a lot of code after the fixed throw will not be executed.

Generally, I was just throwing errors here to test these changes. What stood out for me was that doing this in the mutation panel had no effects on the connection, but doing so from within the queries panel made the whole connection impossible (probably because this is the first panel we show).
This might be perfectly okay as my test was a bit unrealistic, but it felt a bit weird and I wanted to point it out.

[phryneas]

I also encountered this error, which might be related - but I cannot reproduce it consistently.

https://github.com/apollographql/apollo-client-devtools/issues/new?body=Error%20on%20Mutations%20tab%3A%0A%0A%60%60%60%0AApolloError%3A%20RPC_MESSAGE_TIMEOUT%0A%0AApolloError%0A%20%20%20%20at%20new%20ApolloError%20(chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A63624%3A28)%0A%20%20%20%20at%20chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A63018%3A47%0A%20%20%20%20at%20both%20(chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A68575%3A31)%0A%20%20%20%20at%20chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A68564%3A72%0A%20%20%20%20at%20new%20Promise%20(%3Canonymous%3E)%0A%20%20%20%20at%20Object.then%20(chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A68564%3A24)%0A%20%20%20%20at%20Object.next%20(chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A68577%3A49)%0A%20%20%20%20at%20notifySubscription%20(chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A176104%3A18)%0A%20%20%20%20at%20onNotify%20(chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A176148%3A3)%0A%20%20%20%20at%20SubscriptionObserver.next%20(chrome-extension%3A%2F%2Fgchmlaakeogdadclibhedcdohhknlhnc%2Fpanel.js%3A176197%3A5)%0A%60%60%60%0A%0A%23%23%23%20Additional%20details%0A%3C!--%20Please%20provide%20any%20additional%20details%20of%20the%20issue%20here%2C%20otherwise%20feel%20free%20to%20delete%20this%20section.%20--%3E%0A%0A%23%23%23%20%60%40apollo%2Fclient%60%20version%0A%3C!--%20Please%20provide%20the%20version%20of%20%60%40apollo%2Fclient%60%20you%20are%20using.%20--%3E%0A%0A%23%23%23%20Apollo%20Client%20Devtools%20version%0A4.17.6&labels=%F0%9F%90%9E+bug

[jerelmiller]

@phryneas that error usually occurs when you "update" the extension, whether thats the browser doing it in the background, reloading the extension in dev, or having the webpack extension reload it for you by updating code. Each of these invalidate the extension context so the devtools script is no longer able to communicate to the background service worker script (since that service worker has now been replaced with the updated extension).

I plan to address this separately. So far I can't seem to find any way to automatically reconnect the devtools script with the new service worker without having the user close and reopen devtools. I suppose that makes sense anyways since there might be new code in the devtools script. For that we should probably show a message to the user that the user needs to close and reopen. I'd like to do that separately (in fact, I should probably create an issue for this edit: #1476).

Previously though, when that update would occur, the timeout would mean that the UI appears frozen since we can no longer get messages from the background script, so you'd stop receiving updates from the client. With this change, we at least see an error page so you know something went wrong so its a "something better than nothing" approach for now.