Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(study-tree-ui): fix several bugs and major refactoring #2348

Open
wants to merge 22 commits into
base: dev
Choose a base branch
from

Conversation

smailio
Copy link
Contributor

@smailio smailio commented Feb 18, 2025

Fix all bugs that are fixed in this PR #2325

Fix a minor bug that wasn't fixed by the former PR : when the user move a study in a default workspace from one folder to the other, the old folder wasn't removed from the UI even if it became empty.

Major refactoring

The flow of the updates changed. There're two ways to receive updates about the tree strcture, either by calling the explorer API or when the state of the backend changed, for instance if a study was added or moved and we receive the new state from the backend. Before this PR these two events were handled differently with different logic.

  1. user click
    1. fetch subfolders
    2. compute new tree
    3. set state of new tree
  2. backend state update
    1. compute new tree based on study list
    2. deep right merge new tree to old tree
    3. set state of new tree

This PR unify the way we handle new data :

  1. user click
    1. fetch subfolders
    2. store new subfolders in component state
    3. compute new tree (insert subfolders in new tree)
    4. set state of new tree
  2. backend state update
    1. compute new tree (insert subfolders in new tree, we can do this easily because the subfolders are already in the component state)
    2. set state of new tree

Other major refactoring, we don't use the explorer API to fetch workspaces anymore, we only rely on the study list to compute the workspaces like we used to do a few months ago before the dynamic loading feature.

Before this PR at the loading of the component or when the user click on "root" we would call the explorer API to fetch the list of workspaces, however this never were anything new, because the workspaces don't change often. There's one case where fetching workspace would be usefull :

  1. new workspace is configured and deployed
  2. workspace is big and scan takes hours
  3. user is in a hurry and can't wait the first scan to complete

Handling this case add a lots of complexity to the code and doesn't add much value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant