Addons-frontend: Initialize the client with a predictable Redux state object

[kumar303]

For sanity, we should initialize the client (i.e. rendered HTML) with a predictable Redux state object.

For QA: This change could affect the entire app but only for the first page load. Please test as much as possible with this approach:

• Load the site, navigate to another page
• Click the browser refresh button
• Make sure the page looks correct after refresh
• Navigate somewhere else, click refresh, verify, and repeat...

---

How is the current Redux state object unpredictable, you ask? Well, let me begin by mourning the hours of my life lost to this bug. Thanks, let's continue. You can see it in action like this:

• Go to https://addons-dev.allizom.org/en-US/firefox/addon/icloud-test-dev/ in Chrome so you can use Redux Devtools. Be sure to load the URL directly instead of navigating there from another page.
• With Redux Devtools, select the @@INIT action and open the State tab to see the initial state that the page was loaded with.
• Open up addonsByAuthors and you should see something like: loadingFor: { ValentinaDDD-extension: true }.

This means the client will think it's in a loading state yet nothing will ever load!

If you use the logger from https://github.com/mozilla/addons-frontend/pull/6724 then you'll see how the final server render dispatches FETCH_ADDONS_BY_AUTHORS just quick enough to modify state before ServerHtml renders its HTML.

Funny enough, the AddonsByAuthors component does not check if data has already been loaded or is in the process of loading before beginning to load data. Hmm, I wonder if there is a trail of tears behind that decision! All other components would have trouble here because it would be impossible to know if it is safe to begin loading data or not.

[ioanarusiczki]

I tested this on a new profile, loaded AMO dev with FF62(Win10), went on another site then returned and refreshed AMO (mostly I used links that redirect from AMO to other pages). The homepage reloads without any layout issues.

[willdurand]

@ioanarusiczki I am marking this issue as "qa: extra" because we need to repeat the STR for all pages of AMO. This change is rather critical.

[ioanarusiczki]

@willdurand Ok, I will re-check for other pages too and return with the test results.

[willdurand]

I changed the milestone because the patch has landed after this week's tag.

[ioanarusiczki]

@willdurand I tried to cover all AMO new pages and repeated tests on AMO dev (FF63, Win10) while using a comparison with AMO prod. I did not observe new issues while navigating on other pages then returning to AMO and refreshing the page.

Still, while testing this I've noticed a couple of refreshing page issues:

1. If a detail page is reloaded on and on after a while the Add to Collection and Rating Breakdown sections display a red error "An unexpected error ocurred". A search tool's detail page shows above the title a red error too but this was already filed here https://github.com/mozilla/addons-frontend/issues/5392 and it it's more difficult to reproduce it on AMO prod

1. When "Remove" or "Enable" state is displayed on the add-on's detail page after refreshing page the "Add to Firefox" appears for a short while , this is also reproducible on AMO prod (and not reproducible with Disco Pane on AMO dev)

1. Edits are no longer displayed on the edit profile page (such as display name, description or profile picture changed) after refreshing the page. It's also reproducible on AMO prod.

1. The collection edit page closes after refreshing page, it's reproducible on AMO prod too

So please let me know if I should file separate issues for 2, 3 or 4.

[willdurand]

When "Remove" or "Enable" state is displayed on the add-on's detail page after refreshing page the "Add to Firefox" appears for a short while , this is also reproducible on AMO prod (and not reproducible with Disco Pane on AMO dev)

That's because the final add-on state is resolved on the client. We cannot do anything about it.

Edits are no longer displayed on the edit profile page

What do you mean? If you edit a field but don't "save" it, it does not get auto-magically persisted, or did I miss something?

The collection edit page closes after refreshing page, it's reproducible on AMO prod too

That looks good to me given that we do not add a query parameter or anything that would allow the server to know about the "edit" state. That'd be a nice improvement, but it is very low priority.

Everything looks good to me, except that I don't understand (3). We can get feedback on (4) if you open a P4 issue asking for an improvement (a query parameter like ?edit=1 into the URL to open a collection in "edit" state).

[ioanarusiczki]

@willdurand Nevermind about pct 3! I did not click update profile or navigated elsewhere therefore the edit is not saved as you said.
Pct.4 - filed here https://github.com/mozilla/addons-frontend/issues/6773

Verified on AMO dev with FF63(Win10)

[kumar303]

If a detail page is reloaded on and on after a while the Add to Collection and Rating Breakdown sections display a red error "An unexpected error ocurred".

When you refresh a page very quickly, you might abort a network request in progress. This is why you see the red unexpected error banner. It should not happen through normal site usage. See https://github.com/mozilla/addons-frontend/issues/4399