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

refactor: introduce abstractions at the workspace level #3836

Draft
wants to merge 29 commits into
base: release/2024.3.0
Choose a base branch
from

Conversation

jamesgeorge007
Copy link
Member

@jamesgeorge007 jamesgeorge007 commented Feb 16, 2024

Description

This PR introduces abstractions at the workspace level and ports the existing implementation to the new architecture. This will be done in phases, and the changes will be merged into the head branch. On a high level, business logic specific to each workspace is being moved from component sources to the respective provider definitions. The newly revamped workspace service acts as an interface for other parts of the codebase to access methods implemented by the various workspace providers. There is a given set of API methods that each provider (personal, teams, file-based) will implement, starting with personal initially.

  • Handles - Reference to an entity, say workspace, collection, requests, etc. It also holds the necessary information about the resource being pointed to. It can be invalidated at any point. Hence, it's a ref to a resource that, in turn, can hold reactive data (A handle itself can be invalidated and needs to be aware of changes happening to the inner members).

    export type HandleRef<T, InvalidateReason = unknown> = Ref<
      { type: "ok"; data: T } | { type: "invalid"; reason: InvalidateReason }
    >
  • Views - Compiles information about the underlying representation used to render the UI.

    export type RESTCollectionViewCollection = {
      collectionID: string
    
      name: string
    }
    
    export type RESTCollectionViewRequest = {
      collectionID: string
      requestID: string
    
      request: HoppRESTRequest
    }
    
    export type RESTCollectionViewItem =
      | { type: "collection"; value: RESTCollectionViewCollection }
      | { type: "request"; value: RESTCollectionViewRequest }
    
    export interface RootRESTCollectionView {
      providerID: string
      workspaceID: string
    
      loading: Ref<boolean>
    
      collections: Ref<RESTCollectionViewCollection[]>
    }
    
    export interface RESTCollectionChildrenView {
      providerID: string
      workspaceID: string
      collectionID: string
    
      loading: Ref<boolean>
    
      content: Ref<RESTCollectionViewItem[]>
    }

Todos

  • Drop New prefixes from the newly added components once replacing all instances with newly added components and removing the old ones.
  • Remove the emitWithFullCollection prop from the CollectionsProperties component after porting all usages.
  • Replace workspace-user-collection with user-collection for the type HoppRESTSaveContext under hoppscotch-common/src/helpers/rest/document.
  • Only keep requestHandle under the tab saveContext and remove the IDs (requestID, workspaceID, etc) at runtime.
  • Remove collectionID from requestHandle since it can be obtained from requestID.

Checks

  • My pull request adheres to the code style of this project
  • All the tests have passed

jamesgeorge007 and others added 24 commits February 16, 2024 13:08
Co-authored-by: Andrew Bastin <andrewbastin.k@gmail.com>
Introduce a handle for requests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant