-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Proposal: Breaking GraphiQL APIs & New APIs 💥 -> 🚀 #1165
Comments
Feels fine to break these considering the extra opportunities the plugin system offers instead of these |
awesome yes! i think in the case of prettifying it's unique because of monaco, so for that we will use monaco's API directly. here's an example of how i envisioned the prettier plugin looking: as you can see theres a way monaco wants you to set up the formatting provider, so while it would make sense via a reducer, this is the proper monaco way to do it, so that it works with the editor shortcuts and the core monaco formatting handlers. |
@elvin666666 anything you are looking to refer to here? any questions? |
@acao Good evening sir, I want to contribute in open source. So can you give me some issues to work on it(related to GraphiQL plugins or redesigning layout). |
1.
GraphQL.state
(e.g.
GraphiQL.state.query
) is being accessed directly, and is advertised somewhat as a public interface in the Readme and has been for some time. However, our move to context means that providers will contain state. Also there will be multiple queries with multple tabs! Also if I'm not mistaken it's not really reccomended to access Component state directly like that?replacement proposal:
becomes
and this one which will require the parent workspace context to work (i.e. a tab plugin, etc), and already know which is the active tab by default from parent workspace context.
also for non-hooks class component style, they can still in a tab plugin use:
2.
GraphiQL.methods()
There are also Component methods that are used to access values, submit queries programatically, and for many other purposes in the wild.
These also will move to context provider, possibly just dispatch actions with types that pass args mapped to some of the same and some new method names.
then you can readily dispatch actions via a similar interface:
also in a panel/tab context:
a better approach with useGraphiQLReducers()
hopefully we can figure out how to provide side effects for actions in
useGraphiQLReducers
as well?the GraphiQL.methods() interfaces are also accessible outside of a bundler for react JSX (Parcel, Webpack, Rollup, etc). this new proposal however would require one of these bundlers to achieve these kinds of capabilities. You can also use
React.createElement
directly with the contexts we will export to avoid that, but that might grow cumbersome3:
GraphiQL.Logo
and friendsThese are a cute interface but they will be deprecated soon for new patterns for defining your own layouts for the workspace and operation editor panes layout per tab, and replacing components programatically in ways that will be provided by plugins.
Also, @walaura is plugging away at a new theme provider and baseline theme and components that we will begin to adopt into our component tree and you will be able to override the theme defaults and style at the props level, again a prototypical interface over plugins.
Summary
All of these interface will need to be dropped so we can make way for the first proto-plugin features, which will be defining custom components that inherit workspace/operation tab context that you can pass from the GraphiQL component, and will be rendered either in the left or right panes, and will optionally have an icon in the icon bar and labels and such.
These will expose the above mentioned capabilities, and none of this requires a plugin layer yet, and these interfaces should hopefully be close to what the plugin interfaces will be for RC. hooray react for making it so easy to create extensible components!
The way we pass these early "plugins" to GraphiQL will be at the props level, maybe in a
plugins
array. Eventually you'll be able to use graphql config to provide predefined plugins with their own settings overrides in graphql "presets" that you build with webpack, and eventually hopefuly the ability to search, select and install/uninstall/disable etc plugins over the wire! not as far off as it might seem!Notes:
Related Issues:
The text was updated successfully, but these errors were encountered: