-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
refactor(workspaces): provider additions for collections under personal workspace #3859
Merged
AndrewBastin
merged 56 commits into
refactor/workspaces
from
refactor/workspaces-collection-provider-additions
May 22, 2024
Merged
refactor(workspaces): provider additions for collections under personal workspace #3859
AndrewBastin
merged 56 commits into
refactor/workspaces
from
refactor/workspaces-collection-provider-additions
May 22, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collection ID can be inferred from request ID by removing last index from the path.
…ewRequest` type Collection ID serves the purpose.
…ns performed over it
Ensure the entire collection tree is rendered if the search query matches a collection name.
jamesgeorge007
force-pushed
the
refactor/workspaces-collection-provider-additions
branch
from
February 27, 2024 17:35
54706e3
to
845db07
Compare
Only the IDs (workspace, provider & request IDs) to restore the handle are stored under `localStorage` and the handle is restored back at runtime.
jamesgeorge007
force-pushed
the
refactor/workspaces-collection-provider-additions
branch
3 times, most recently
from
April 24, 2024 11:16
3c0af78
to
ee1e98e
Compare
jamesgeorge007
force-pushed
the
refactor/workspaces-collection-provider-additions
branch
12 times, most recently
from
May 17, 2024 08:44
f80efd4
to
9d1c154
Compare
jamesgeorge007
force-pushed
the
refactor/workspaces-collection-provider-additions
branch
from
May 17, 2024 09:39
9d1c154
to
199d9d1
Compare
jamesgeorge007
requested review from
AndrewBastin,
amk-dev,
nivedin and
anwarulislam
as code owners
May 17, 2024 11:44
AndrewBastin
approved these changes
May 17, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Ensure child collections are created instead of the action resulting in new root collections.
jamesgeorge007
force-pushed
the
refactor/workspaces-collection-provider-additions
branch
4 times, most recently
from
May 21, 2024 18:50
20f9cd1
to
cf35354
Compare
- Increase test coverage. - Move store mock data under `__tests__/__mocks__`. - Rephrase test descriptions.
jamesgeorge007
force-pushed
the
refactor/workspaces-collection-provider-additions
branch
from
May 22, 2024 06:25
cf35354
to
37531bd
Compare
AndrewBastin
deleted the
refactor/workspaces-collection-provider-additions
branch
May 22, 2024 07:18
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR ports the existing implementation for import/export, move/reorder, and search corresponding to collections under personal workspace to the provider-based new architecture. It also adds support for searching collections at any depth.
We're also moving to a new inert handle-based approach (proposed by @AndrewBastin). Previously, reactive handles were sent around everywhere with the provider methods expecting the same. This resulted in issues with the reactivity behavior mostly with the issued handle updates not getting reflected in the issued handles since the reference was coming up differently and the value getting automatically unwrapped at places. In the new approach, while obtaining a handle it's just a plain object and the underlying reactive value can be accessed later in time.
Personal workspaces have dynamic path-based IDs (
0/0
,2/1/0
, etc) based on the position (levels are separated by/
, single digit represents root collections) of a resource (collection/request) in the tree. Previously to keep the association between requests open under tabs and the ones from the tree, every time the resultant IDs were computed manually after the action. Say, a request at a deeply nested collection is moved to a different location, each tab has information about the ID path of the request being open from the tree, and necessary updates are made to the above information based on the action computed from the source and destination IDs.With the new handle-based system, since handles are reactive references to a resource, we keep a list of issued handles (obtained while creating/selecting a request,). Each tab keeps a request handle reference under
tab.document.saveContext
, and whenever an action requiring updates to the IDs happens, the corresponding handle is found from the compiled list of issued handles and the respective ID (collectionID
,requestID
) is updated accordingly. The updates are streamed to the tabs via the reactive behavior. The same approach is used for toggling the dirty state associated with requests when any parent-level collection is deleted or if the request itself is deleted.Closes HFE-437.
Changes
Adds the following methods under the personal workspace provider corresponding to the abovementioned features.
Migrate to the new inert handle-based approach.
Move to handle based updates to keep the association between requests from the collection tree and the ones open under tabs.
Additions to the
NewCollectionsRest
component accounting for the ported features mentioned above. The business logic associated with updates to the store for each action resides in the provider definition for each workspace invoked from the component level via the new workspace service implementation.Move the markup and associated logic wrt showing the active workspace and search from the parent level
NewCollections
component to `NewCollectionsRest.Port the collection/request move/reorder logic (markup, events, handlers, etc) into the
NewCollectionsRestCollection
andNewCollectionsRestRequest
components.Introduce a new tree adapter to render the tree with search results. This was required since the existing adapter for rendering the default collection tree operates based on the supplied workspace handle. While, for search, is to be based on the initial data provided to be filtered based on.
The
getChildren
method to be implemented by the tree adapter now takes an additional argument signifying the type of the incoming node (collection/request
). This acts as a safeguard to prevent errors with operations specific to a collection node.Remove
collectionID
from information persisted under the REST tabsaveContext
sincerequestID
accounts for it.initializeDownloadCollection
helper under~/packages/hoppscotch-common/src/helpers/import-export/export
is given an agnosic nameinitializeDownloadFile
since it gets consumed in different contexts. The definition is updated to point to the platform definition to ensure the underlying platform defines the behavior.New helper functions under ~/packages/hoppscotch-common/src/services/new-workspace/helpers.ts to abstract common logic consumed in the provider method definitions.
Formalise a system for creating a persistable handle reference that can be loaded back again - Persist request handles at runtime, write only the unique IDs (provider, workspace & request IDs) required to restore the handle to
localStorage
. Load the request handle back via the IDs at runtime.Introduce writable handles to signify updates to other handle references when an action is performed. For instance, a request from the collection tree is deleted and at the same time the handle issued is updated thereby the request handle persisted under tab
saveContext
is aware of the update (handle type is set toinvalid
) and toggles the dirty state in this case.Adds a test suite for the
PersonalWorkspaceProviderService
with associated mocks and helpers.Checks
Note to reviewers
Switching to a team workspace will result in exceptions at the moment and can be ignored. This PR includes changes specific to the personal workspace. The existing provider definition for teams
test.workspace.ts
is meant as a placeholder to be removed once the teams-side implementation is brought in.