Skip to content
GitLab
Next
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • R RFCs
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 28
    • Issues 28
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • Frontend
  • RFCs
  • Issues
  • #100
Closed
Open
Issue created Apr 12, 2022 by Miguel Rincon@mrincon🚀Maintainer

New: Use typePolicies and makeVar to store client-side state

New Pattern Proposal: "Use typePolicies and makeVar to store client-side state"

Apollo Client 3 allows us to manage application state with type policies with reactive variables, this pattern may replace client-side resolvers (in some cases?).

Advantages of new pattern

  1. Reactive variables (makeVar) manage updates in components automatically.
  2. Current local resolvers are deprecated by Apollo Client: https://www.apollographql.com/docs/react/local-state/local-resolvers/, and will have to be reimplemented as part of the link chain.

Disadvantages of new pattern

  1. We don't use mutations as with backend changes, and require one more inject to modify state.
  2. We have yet one more way to state state on the client.
  3. We don't have a good way to track local state of the reactive variable using Apollo devtools.
    • See related: https://github.com/apollographql/apollo-client-devtools/discussions/391

What is the impact on our existing codebase?

I expect that we will use the best tool on a case-by-case basis, and each product area will choose an approach that suits them, no sweeping changes.

Reference implementation

Introduce admin_runners_bulk_delete feature flag (gitlab-org/gitlab!81894 - merged)

New

Edited Apr 14, 2022 by Miguel Rincon
Assignee
Assign to
Time tracking