Clear workspaces on reconnect and fetch immediately on return #182
Conversation
|
Yeah, the back issue was there for quite some time, and it was caused simply because the callback for enable/disable was executing only when the table selection changed. When you come back from IDE&Project view, the table is not yet changed, the old data is still present, with the same old selection. At some point the poller is updating the table values, which in the end triggers the callback that checks what is selected. Of course, cleaning up the elements in the table also triggers the callback...fixing the issue. |
| @@ -454,7 +456,7 @@ class CoderWorkspacesStepView(val enableNextButtonCallback: (Boolean) -> Unit) : | |||
|
|
|||
| this.indicator.fraction = 1.0 | |||
| updateWorkspaceActions() | |||
| triggerWorkspacePolling() | |||
| triggerWorkspacePolling(false) | |||
There was a problem hiding this comment.
I don't really see the harm in requesting the workspaces a bit earlier.
src/main/kotlin/com/coder/gateway/views/steps/CoderWorkspacesStepView.kt
Show resolved
Hide resolved
|
Ahhh I see, that makes sense. Thanks for explaining the issue! |
My thinking here is that if you try connecting to a new URL you still see the old workspaces until the new connection is successful which could be confusing (the new URL shows in the text field yet the workspaces below it belong to something else and the list will no longer update since the poller was stopped). Also thought it might make sense to fetch immediately if you come back to this step since it is not clear that the data there is possibly stale (especially if you were on a previous/next step for a long time); I think I would assume a fresh fetch when I interact with the next/previous buttons but this is just my personal assumption. Fetching immediately also "fixes" an interesting bug where if you hit back you are unable to connect to a workspace until the next poll goes through. I considered looking more into this but figured it would be best to block the next step on fresh data anyway.
|
Going to hold off merging because I just rebased and now when I hit back the button never becomes available. |
code-asher
force-pushed
the
asher/clear-fetch-workspaces
branch
from
3143ebb to
2b7b2a9
Compare
|
I figured the easiest fix is to clear in |
Fixes the back button never being available. Plus it makes it so you have to wait for the next fetch which I think makes sense so you are not trying to connect with potentially stale data.
code-asher
force-pushed
the
asher/clear-fetch-workspaces
branch
from
2b7b2a9 to
e209bd3
Compare
My thinking here is that if you try connecting to a new URL you still see the old workspaces until the new connection is successful which could be confusing (the new URL shows in the text field yet the workspaces below it belong to something else and the list will no longer update since the poller was stopped).
Also thought it might make sense to fetch immediately if you come back to this step since it is not clear that the data there is possibly stale (especially if you were on a previous/next step for a long time); I think I would assume a fresh fetch when I interact with the next/previous buttons but this is just my personal assumption.
Fetching immediately also "fixes" an interesting bug where if you hit back you are unable to connect to a workspace until the next poll goes through. I considered looking more into this but figured it would be best to block the next step on fresh data anyway.