Replies: 5 comments 12 replies
-
|
I like the idea of having a I assume the create fetcher package is meant to be a utility to enable creating pluggable fetching logic for graphiql, however is the logic that complex that it needs to be a separate package? Another way of looking at the question: why does A similar argument goes for About creating the separate editors, my take on it is: the architecture proposal is meant to cater for the maximum required level of flexibility and extensibility. If that goal is achieved, creating a simple build/component abstraction shouldn't be an issue any longer, as it will just be using the editor and specifying reasonably simple default options. So while technically you could say there are two editors, we would just have a single implementation with the second lean editor being a simple usage of the first. |
Beta Was this translation helpful? Give feedback.
-
|
yes thats how i interpreted it! I think here's a few reasons why i would argue for making create-fetcher a seperate package:
however, the toolkit is where we will be moving other |
Beta Was this translation helpful? Give feedback.
-
|
I think for the next rc we should move it to toolkit and, here’s something else thats going into toolkit! @harshithpabbati had rewritten it for this new architecture i think i can make a roadmap just for toolkit, and we can make a list of what we want to pull in from where |
Beta Was this translation helpful? Give feedback.
-
|
@imolorhe thinking we should actually move the fetcher to the the reason being is that all of this would be fantastic to use for the language server, for |
Beta Was this translation helpful? Give feedback.
-
|
we will move the fetcher to |
Beta Was this translation helpful? Give feedback.
-
|
so, if some of the logic that's in it would go to |
Beta Was this translation helpful? Give feedback.
-
|
This sounds super awesome -- I think the approach of a high level, batteries included component which you could "eject" from to build your own high level system out of the lower level bits makes a lot of sense! |
Beta Was this translation helpful? Give feedback.
-
|
I really like that this approach also will allow people to potentially easily consume the many utilities and components for any other kind of graphql related projects they might have |
Beta Was this translation helpful? Give feedback.
-
|
Yes that’s the goal! Hoping that instead of building complex APIs, we can instead build the editor with everything one would need to build their own editor. The theme layer brings up some questions here though - what if someone wants to use a different theming system like chakra UI? They should be able to re-use some of the most powerful components that are potentially decoupled from the theming layer perhaps? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure the theme should be configurable to the extent of choosing the theming system 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
agreed, that's why there will be a configurable application using our chosen theming system, and a way to customize that theme using configuration, plugins/etc, but essentially one chosen theme system. however, if one should want to "eject" from the configuration/plugin-driven the even more arduous and adventurous route would be to use |
Beta Was this translation helpful? Give feedback.
-
|
Here is a PR that's a great starting point towards where we are headed with We also should move many of the graphiql utilities to The end goal is that the rewritten the playground-like project that will emerge from this effort, whatever it will be called, will be based on the same underlying components but will have more advanced features & settings, ways to provide simple "Plugin" components in the UI (custom forms, results panes, variables editors, query editors, etc). there will probably need to be two service layers essentially the current pattern of just dumping props into a single react component will slow us down eventually. it won't enable the kinds of tools people want to build with graphiql or this ecosystem. it's become like the jquery mega-libraries of yore, with API, business and presentation concerns all jumbled together in one giant flat interface. the playground approach to settings via a simple json or yaml config makes way more sense, is more portable across service interfaces, and also might allow for some degree of parity in the transition for playground users, and for more advanced usages, direct use of the SDK and ample examples will serve them well CC @dotansimha |
Beta Was this translation helpful? Give feedback.
-
|
How do the original authors of Playground feel about this proposal - @timsuchanek @schickling @huv1k? I see two potential paths forward, either this one where we re-build playground from the ground up ala 2.0 for monaco with this SDK approach -or- We just set up a team to specifically focus on reviving stability & maintenance of the existing playground codebase, and port it to use There are users helping other users with issues & PRs over there who may make excellent co-maintainers! We can enable discussions in the repository and let the users decide 🗳️ |
Beta Was this translation helpful? Give feedback.
-
The goals are similar to what we had last year, a robust ecosystem for developing web-based graphql development experiences with react and monaco.
The main difference with this variant proposal is two editors instead of one, and though this may seem more impractical, I will attempt to prove why it may be even more practical.
Instead of working directly from the RFC, we could focus on building out
@graphiql/toolkitand@graphiql/reactby porting existing logic into new patterns and APIs. We can adapt components and libraries from graphiql 2 rfc or entirely rewrite many parts as needed.graphiqlwould remain lightweight, potentially more than it is already, a reference implementation for docs & spec development. It would implement the same components and css-in-js theme customization system as thegraphql-ide, and thus be included in the redesign of course.Then,
graphql-ide(tentative title) could move forward with introducing greater customizeability and extensibility without encumbering the tool we use for developing the reference ecosystem@graphiql/toolkitwill become the new home of many of the most importantgraphiql@1business logic. everything from executing operations, to AST manipulations, etc. This logic lives withinsrc/utilitiesor within giant components likeGraphiQL@graphiql/reactwould export hooks for accessing state, theme system components, editor components, doc explorer?, query history, etc. some of these will be abstractions around@graphiql/toolkit. it will act as a reference implementation of@graphiql/toolkitthat other frameworks likesvelteorvue, etc could use for inspiration@graphiql/create-fetcherhas been created to generate a fetcher, which can be used by bothgraphiqlin the current pattern, and internally bygraphql-ide@graphiql/react-doc-explorer- perhaps? though it could just be exported from the@graphiql/reactpackagethoughts?
Beta Was this translation helpful? Give feedback.
All reactions