Closed ryanslade closed 3 years ago
The original design for this flow has all of the repos shown, with a pending/cloning state for the repos that are queued for cloning. This is the end state we should be aiming to achieve. The long wait after hitting "Save changes" is a workaround solution to prevent this UX issue, and it's supposed to be completely blocking—the user shouldn't be redirected until all repos can be shown in the list (whether or not they've been cloned). In a sense, the problem here is that users are being redirected to the list when they shouldn't be.
@artemruts mentioned that it might be a matter of exposing this in-between state – we know it's meant to be added, but they don't exist yet.
@artemruts Any idea how we can avoid this?
@ryanslade we have to stop waiting for the external services to update last synced
timestamp and immediately navigate back to the repo list on successful response. The repo list then will make a UserRepositories
request to fetch user repos and the response will have the mirrorInfo
object where we can see individual sync states.
In practice UserRepositories
request doesn't show the newly added repos for 3-7 seconds - that's why we wait so long at the save
button.
We do have a way to show different statuses per repo if we receive them from the backend: https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/client/web/src/user/settings/repositories/RepositoryNode.tsx (look for mirrorInfo
)
@arussellsaw since you implemented the logic originally, does that sound right to you?
@ryanslade I will try making on save navigation immediate now. We have only two APIs to try UserRepositories
and externalServices
to see if repos were added (in any state).
The problem I experienced - both queries will register changes at the same time (after 3-7 sec), as if the UserRepositories
query is tied to the ExternalServices
sync time. If the ExternalServices
sync time takes 5 seconds, then the UserRepositories
won't show new repos for 5 seconds.
In theory once last_synced_at
has been updated the repos should exist in the repo
and external_service_repos
table.
When you say the UserRepositories
requests doesn't show any repos do you mean 5-7 seconds after the sync has completed?
Ignore this, superseded by our chat in Slack.
@ryanslade I will try making on save navigation immediate now. We have only two APIs to try
UserRepositories
andexternalServices
to see if repos were added (in any state).The problem I experienced - both queries will register changes at the same time (after 3-7 sec), as if the
UserRepositories
query is tied to theExternalServices
sync time. If theExternalServices
sync time takes 5 seconds, then theUserRepositories
won't show new repos for 5 seconds.
@artemruts Naïve question: would it work to capture the selected repos in a temporary client-side variable when hitting "Save changes" and then using that data to show the list of repositories, and then subsequently replace that list's data based on the API responses? It'd kind of be faking it for the sake of the perceived experience.
@quinnkeast we could try that but I'm wondering if the following will happen:
save
Repository not found
search warningSeems like in that case we're still tied to that 3-7 seconds 🤔
Hmm, that makes sense. Goes back again to the idea that there's no "pending" state for repos—if there were, then it'd be totally okay to show a "Currently cloning" state for the repo when it's clicked in the list.
I don't think we should show the list of repos before they've been created in the repo
table. Instead I think we can detect that we've started a background process and just indicate to the user that something is happening, then prompt them to refresh once we know we have new data. We'll need a new API for this, but it should be fairly straightforward as we can tap into the external_service_sync_jobs
table. Clicking save
currently adds a row to that table already.
We can then show a notice that “repos are being updated” or something and once we know we’re done we can show them the message to say new repos are available, please refresh. I don’t think we should refresh automatically in case they are browsing through their repos and have paginated beyond the first set of results. Once new results arrive the entire list of repos would be reordered anyway since we order by name.
Ryan, do you want me to make an ticket for this new endpoint?
Ryan, do you want me to make an ticket for this new endpoint?
Yes please
@artemruts do you have this ticket ready?
@artemruts do you have this ticket ready?
After adding repos as a user you are redirected to your repositories list page, something like https://sourcegraph.com/users/USERNAME/settings/repositories
However, since repos are being added in the background it's possible for the newly added repos not to appear in the list yet or even for the list to be empty.
It's not obvious at this point that anything is happening and that the only way to check for repos is to refresh the page.
I'm not sure what the best approach is here from a UX perspective, @quinnkeast WDYT?