GraphiQL Roadmap Notes
Begin with setting up @graphiql/react workspace & component library tooling with:
- storybook/ladle/etc
- css-in-js framework with css variables-driven customization such as stitches
- using
viteas a bundler - exports hooks, components and providers
- readme
Implement the default style guide & dark mode as color theme(s) from the redesign.
Decide:
- whether themes will each have their own dark mode variant palette, or whether there will just be themes which are light and themes which are dark.
- how users will provide the custom theme
- whether we should use stiches or similar?
- how typography & font rendering & scaling will be handled
Keep in mind:
- many graphiql users are used to a simple html file setup that uses the bundled javascript and css. if we can ship custom themes which are just cdn files that specify css variables that can cascade to whatever stitches is doing, then we're in a good place for them
- users will be re-using these components & hooks for custom sidebar and results components.
the default theme should provide some hooks for accessing theme values inline, for when users want to customize their plugins (if this makes sense with stitches)
Start with tabs and dropdowns towards the basic embedded doc experience (top right of the figma). Following terminology for tab UX elements will follow wai-aria spec - we have tab, tabpanel and tablist
We will need a tabs DX that allows for both a re-rendered tabpanel, and a persistent tabpanel. For example, @radix ui only supports the former. The latter would have wai aria props transform at runtime when the tab changes, as we do in graphiql tabs now, to prevent re-renders of the editor components. In other cases, we do want the components to unmount when toggling the tab editor, in other cases, we just want to execute a state change and tell the underlying editor to switch to the in-memory (or persisted) model for that tab.
this could also include a section for dropdown, or just have a mode where the tabs push into a dropdown when there are too many tabs for the current render width
sandpack also has a great example of this
A utility component to control the size of it's children based on a parent onresize window event listener.
I would re-architect this to have a single provider that listens to onresize (debounced) and tells the child context subscribers the resulting height and width when it changes.
Perhaps a pane component that can have it's own toolbar/footer/etc? Similar to how a Card component might work?
This is a simple set of primitive visual styling components that Laura put together for us to build out and style the classic doc explorer experience. The only things for "classic" DocExplorer needed outside of this simple example are:
- collapsing region for deprecated fields
- toolbar with navigation buttons
- search input component doesn't exist yet?
These aren't as important as others but will help move things along!
- Buttons (for toolbars, forms, etc)
- Form/Input components for user/other settings
- Dropdown menu (for toolbar and otherwise)