-
Notifications
You must be signed in to change notification settings - Fork 1.8k
DO NOT MERGE: alternative state management RFC #2906
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
Conversation
|
The latest changes of this PR are not available as canary, since there are no linked |
Decided not to invite y’all as proper reviewers yet because it’s still WIP but @B2o5T and @thomasheyenbrock we feel that we can rework state management in a 2.x refactor to make the rest of the planned features and plugin API easier to build, and for more intelligent & efficient component rendering - what do you think? |
new Promise(res => setTimeout(res, timeout)); | ||
|
||
const longDescription = ` | ||
The \`longDescriptionType\` field on the \`Test\` type has a long, verbose, description to test inline field docs. |
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.
The \`longDescriptionType\` field on the \`Test\` type has a long, verbose, description to test inline field docs. | |
The \`longDescriptionType\` field on the \`Test\` type has a long, verbose description to test inline field docs. |
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.
Love the idea of moving the doc explorer into its own plugin package! Aligns nicely with all the other plugins, both existing ones and future ones.
My main question here is if we can make this backwards compatible with the existing hooks from v2. In other words, can we keep exporting the ExplorerContext
and the useExplorerContext
hook while moving all the actual state management from the ExplorerContextProvider
component into zustand
?
I guess it would not require a major version bump for graphiql
either way, but we should decide if we're fine with breaking stuff for folks that use @graphiql/react
directly.
@thomasheyenbrock yes this was part of the original plugin proposal in #1689 , the idea was that the plugin API should be able to support doc explorer, query history, etc as plugins! also, |
@@ -0,0 +1,4354 @@ | |||
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. |
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.
this lock file should be removed since you added laddle to workspace
@@ -0,0 +1,22 @@ | |||
{ | |||
"extends": [ |
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.
"extends": [ | |
"root": true, | |
"extends": [ |
this config do nothing, without root: true
always root eslint config is taken in priority
<div className="graphiql-doc-explorer-header-content"> | ||
{prevName && ( | ||
<button | ||
// href="#" |
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.
// href="#" |
@@ -0,0 +1,19 @@ | |||
{ |
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.
{ | |
{ | |
"root": true, |
same here
@@ -0,0 +1,19 @@ | |||
{ | |||
"extends": [ | |||
"plugin:prettier/recommended", |
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.
"plugin:prettier/recommended", |
I don't like eslint-plugin-pretter
since he make a lot of noise, anyway prettier check action is enabled in ci
Tracking issue #2904