Remove state related to a cluster when removing it #755
Conversation
| workspaces: {}, | ||
| }, | ||
| }; | ||
| return this._fileStorage.get('state') || defaultState; |
There was a problem hiding this comment.
We can get rid of the local state as this call doesn't cause reading from a disk (fileStorage keeps data in memory).
| @@ -102,6 +102,12 @@ export class ConnectionTrackerService extends ImmutableStore<ConnectionTrackerSt | |||
|
|
|||
| private _refreshState = () => { | |||
| this.setState(draft => { | |||
| // filter out connections from removed clusters | |||
| draft.connections = draft.connections.filter(i => { | |||
| const uri = i.kind === 'connection.gateway' ? i.targetUri : i.serverUri; | |||
There was a problem hiding this comment.
This won't scale well once we start adding more connection types, but for now I guess we can go with it.
There was a problem hiding this comment.
I'm aware of this, but it can be easily changed to sth like switch-case
There was a problem hiding this comment.
I was thinking more that the URI should be under the same field across all types of connections so that we don't need any special conditionals here.
| gwConn.connected = !!this._clusterService.findGateway( | ||
| doc.gatewayUri | ||
| ); | ||
| if (doc.port && doc.targetUri) { |
There was a problem hiding this comment.
Something like
if (!doc.port || !doc.targetUri) {
break;
}would help avoid adding another level of nesting.
BTW, when is targetUri not present here?
There was a problem hiding this comment.
Thanks.
I will remove targetUri from the condition - it's a bit confusing as targetUri is always present.
gzdunek
force-pushed
the
gzdunek/remove-cluster-resources-when-removing-it
branch
from
bfd0704 to
535f1da
Compare
|
@ravicious I've just found a bug in |
gzdunek
force-pushed
the
gzdunek/remove-cluster-resources-when-removing-it
branch
from
535f1da to
e09eb75
Compare
* Bring back native scrollbar as the styled one causes content to jump when it becomes visible * Use new colors for theme * Fix not clickable notifications when displayed over xterm * Close `Identity` popover after selecting an option (#741) * Fix getting cwd in presence of lsof warnings (#745) lsof uses stderr to print out warnings. This caused the previous version of ptyProcess to throw an error, even though the exit code of lsof was 0. The existing code already handles non-zero exit codes (asyncExec will reject the promise). Since we don't know why stderr was inspected in the first place, let's just remove the check for it. * Change connections shortcut to `Command/Ctrl-P` (#747) * Resolve issues on logout (#740) * Change app name to `Teleport Connect` (#753) * Show database username suggestions in Teleport Connect (#754) * Move useAsync to the shared package, add docs * Add async variant of MenuLogin * Add Teleport Connect version of MenuLogin to its story * Update gRPC files * Show database username suggestions * Use JSdoc in useAsync Co-authored-by: Grzegorz Zdunek <[email protected]> * Convert useAsync to a named export * Refactor MenuLogin to use useAsync underneath * Rewrite useAsync to use a promise instead of async The Web UI currently doesn't support `async`. To do this, we'd need to configure polyfills there, but we don't have time for that right now. * Replace async with promise in MenuLogin Co-authored-by: Grzegorz Zdunek <[email protected]> * Fix check for the --insecure flag (#758) Fixes gravitational/webapps.e#147. * Remove state related to a cluster when removing it (#755) * Teleport Connect: Add dropdown for database name (#757) * Add required prop to MenuLogin This will be needed for the db name dropdown, where the value is optional. * Update proto files * Include targetSubresourceName when creating a gateway * Set better title for gateway tab * Fix long document titles breaking connection tracker's UI Co-authored-by: Grzegorz Zdunek <[email protected]> Co-authored-by: Grzegorz Zdunek <[email protected]>
Closes: https://github.com/gravitational/webapps.e/issues/154
And closes point 1. from https://github.com/gravitational/webapps.e/issues/240
I simplified previous state restoring as we discussed a few days ago (it allowed to fix a bug with restoring previous state after logout and logging back in).