Posts: ensure a fetch on mounting for post-list-fetcher

[rralian]

This should address stale data that can otherwise be shown in the desktop app. I don't think this should have much of an impact on server load, like decreasing the polling interval would.

@blowery what do you think of this? I'm really not sure why we didn't want post-list-fetcher to trigger a fetch on mounting in the first place. Anything in the reader that you'd be concerned about?

Testing

I was recreating a reported issue in the desktop app by doing the following in desktop and calypso master.

• open the desktop app, navigate to posts-list page
• in another browser change the title of the top post
• click to the reader, click back to the post-list page
• note that the post-list page can display outdated title for up to a full minute

Then by running the desktop app with this branch for calypso, if you do the same steps as above, you will still see the old title for a split-second, but then it should update to reflect the new title.

[rralian]

Here's a video showing posts-list getting updated right away when reopened (using this branch in the desktop). https://cloudup.com/c_5u5syesQk

[mtias]

Omitting the attribute should set it to true as well.

[mtias]

This makes sense to me. I believe we may have had a situation where the controller initiated a fetch at the start, and the poller would run another one immediately. For what is worth, leading was set to false since the start here.

[rralian]

I believe we may have had a situation where the controller initiated a fetch at the start, and the poller would run another one immediately.

Yes, there is definitely a double-fetch happening when you first load. I'll see if I can figure it out.

[mtias]

I wonder if we could increase the polling interval as well.

[blowery]

@rralian we don't use the post-list-fetcher in the reader. :) we handle kicking off the initial fetch up in the controller. I've been meaning to move to post-list-fetcher, but it's never bubbled up and gotten done.

[rralian]

The double-fetch was happening because we were using some pagination logic to trigger the first fetch. I just removed that in my latest commit and it's working fine for me.

@rralian we don't use the post-list-fetcher in the reader

@blowery cool, thanks for checking in.

I wonder if we could increase the polling interval as well.

@mtias Maybe, but I wouldn't do so here. If we want to tweak, I think we also need to have some idea of what effect we are trying to create, and then track against a metric to see if the tweak is a success.

Testing

We use post-list-fetcher on these pages:

http://calypso.localhost:3000/posts/
http://calypso.localhost:3000/pages/
http://calypso.localhost:3000/post (post editor... the draft drawer and the post-scheduler popover)

You can test this by watching the network tab and filtering on "posts" to see that only a single fetch happens initially, and then polling fetches happen every minute. And of course you'll see pagination fetches as necessary if you scroll.

Also test to make sure the we're not screwing up pagination. The list of posts when paginated (scrolling past 20 posts) should be the same in this branch that you would see in wpcalypso.

You can also test that this helps pages reflect recent changes. Open the posts-list page. Then edit the title of one of the posts in another tab or window. Then move back to the posts-list page. You should see the new title reflected after a split-second. In master you could be waiting up to a minute to see the change.

[rralian]

oh, btw @blowery... I looked around and the only other instance where we use poller with an option of { leading: false } is in feed-streams.js. You may want to give that a look to see if you can change it to use a leading fetch, to avoid the stale data issue we had in the post-list-fetcher.

[mtias]

👍

[blowery]

Thanks for the heads up @rralian, I'll check into it.

[rralian]

argh... I noticed a double-fetch on the /posts page with sites that have < 20 posts (probably coming from infinite-scroll logic). need to track that down. also the draft drawer usually works for me, but occasionally it does this:

It appears to be some sort of rendering issue in the browser, as when I inspect the items they contain the correct html. And if I toggle a css rule from the inspector, it fixes it. If I can confirm this sometimes happens in master, I won't consider it a blocker here. In any case though, back to digging a bit more.

[rralian]

ok, figured it out. Previously when post-list-fetcher was mounted and we had no Posts data, we ran fetchNextPage() immediately to pull the first page of Posts for the query. However, my changes were using the polling method fetchUpdated to get the initial list of posts. Those two methods behave slightly differently. And that was causing some little issues.

So I'm still using polling to initiate fetchUpdated() when the component mounts (or (re)gains focus), but if we have no posts, we exit out of fetchUpdated() and instead run fetchNextPage(). So the upshot is that everything should behave just like it always has, except we now run an immediate query to keep posts fresh whenever a posts-list component is re-mounted or the page has re-gained focus.

Ready for another look.

[gwwar]

🚢