Site Picker: Show selected site first

[nb]

Especially when adding a new post I almost always want to post to the
current site I have worked with – looked at posts, stats, etc.

It doesn’t make much of a difference in the sidebar picker, so I didn’t
exempt it from the change.

Note: in some cases (opening the reader directly) we don’t have the
selected site yet and we can’t show it. For now I decided not to fetch
it if missing.

Testing instructions:

• Open My Sites
• Change your site to a different one from your primary
• Click on Add New post
• You should see the selected site at the top

[enejb]

I think it would make sense to move the comment as well to the new function. Since it gives it a bit of a better idea why we are doing the comparison.

[nb]

Yeah, you’re totally right, @enejb.

[nb]

Fixed in 9edad5b.

[enejb]

One side effect of this is that after selecting a site in the sidebar, next time you open the sidebar the site that you selected is not in the same position but at the very top.

Which I think it is ok but a bit strange, because the sites move around in the sidebar. Could we maybe make this behaviour more dependent on a prop in the site selector?

Since I think it is a really good improvement in the site selector for creating new post or page.

Other then that it works as expected. 👍

[nb]

One side effect of this is that after selecting a site in the sidebar, next time you open the sidebar the site that you selected is not in the same position but at the very top.

After using this branch for a bit, I found having the selected site on top in the sidebar picker very useful, because there isn’t another easy way to go back after clicking ← Switch Site.

Could we maybe make this behaviour more dependent on a prop in the site selector?

To be honest, I’d rather not add too many options :) Added Needs Design Review label instead.

[folletto]

It's not ideal to shuffle items around because breaks the ability to memorize, and makes any temporary change (i.e. switching once and then going back to the usual pattern) breaking it further.

The correct approach in this case should lean to find a way to solve the issue while preserving the mental model. For example, we cando a light highlight (lol — light gray background for example) and have the selector pre-scrolled to the latest position it was.

This covers properly all the needs:

• The latest site selected is immediately accessible
• The order isn't shuffled, so doesn't break memorized patterns

[nylen]

The high-level goal of making it easier to get back to the current site is something I've often wanted to do, but I agree with @folletto that we should do this via scroll position and a highlight, instead of rearranging the sites list. I took this approach in #1641.

I think rearranging sites is even more of a cognitive burden for the typical user who only has 2 or 3 sites. Better to have them stay in the same place with a clear highlight.

From a code debt perspective this is also a cleaner approach. Here are the methods currently in SitesList:

$ perl -ne '/^SitesList.prototype.(.*) =/ and print "$1\n"' client/lib/sites-list/list.js | sort
canManageAnyJetpack
canManageSelectedOrAll
canUpdateFiles
createSiteObject
fetch
fetchAvailableUpdates
get
getJetpack
getLastSelectedSite
getNetworkSites
getPrimary
getPublic
getSelectedOrAll
getSelectedOrAllJetpackCanManage
getSelectedOrAllWithPlugins
getSelectedSite
getSite
getUpgradeable
getVisible
hasSiteWithPlugins
initialize
isConnectedSecondaryNetworkSite
isSelected
markCollisions
onUpdatedPlugin
parse
propagateChange
removeSite
resetSelectedSite
select
selectAll
setSelectedSite
transaction
update
updateSite

We already have lots of methods around selected sites, like getSelectedOrAll, getSelectedOrAllJetpackCanManage,
getSelectedOrAllWithPlugins, etc. And at least three different ways of setting the selected site (select, selectAll, setSelectedSite).

IMO adding miscellaneous methods to SitesList has become a bit of an antipattern for us, and should be avoided if possible.

[nylen]

I know you didn't write this, but... 😢

[enejb]

I think this PR might not be needed any more since #1641 fixes some of the issues that this PR was solving.

[apeatling]

@nb Okay to close?

[nb]

Yeap, @nylen fixed it all in #1641.