Implement renderable output type #18976
Replies: 2 comments
-
@catchingash Just talked about a very similar feature that is built into Facebook's Relay usage at ReactjsConf 2019. |
Beta Was this translation helpful? Give feedback.
-
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing! Thanks for being a part of the Gatsby community! 💪💜 |
Beta Was this translation helpful? Give feedback.
-
Renderable type
Some things in Gatsby might need to return something that isn't abstractable out just as html text to insert. The most universal kind of return like that is React Component. MDX is the best example of that. At the moment, MDX GraphQL types return raw text of module that is meant to be rendered. Internally MDX does some black magic to make this module includable by React and then a special component
MDXRenderer
knows how to require it and render.Renderable type is an attempt to generalize it. This will allow more plugins to define components as part of their data output and also will regularize and hopefully optimize how this gets compiled by Gatsby.
Basic idea
It would be great to be able to query for actual React Components inside GraphQL.
For instance:
Implementation options / ideas
Ideally we want to keep GraphQL output serializeable. This might be relevant if we ever want to have option to host GraphQL server. In addition page-data.json data obv must be serializable. However what could be done is a processing step applied during loading of paga-data.json. By defining a custom processor for certain types, we can, for insteance, process date types into a JavaScript date. In addition this would work for loading some kind of component id or path into an actual React component. This way user could actually use it directly as described above. We could allow defining those "clientSideProcessors" as a parameter of type or field. Or maybe as separate config, not sure yet.
One important requirement for that is that a component must be available in a currently loaded bundle. This can be done by adding a webpack dependency to a page same way as we add a data dependency. When
component
field is resolved it is added as a page dependency to webpack. Webpack can process it with normal chunking mechanism, so a common component like image will be in commons bundle, but eg mdx will be only in page bundle.Beta Was this translation helpful? Give feedback.
All reactions