Skip to content
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

Refactor internal data pipeline #177

Closed
KyleAMathews opened this issue Mar 7, 2016 · 1 comment
Closed

Refactor internal data pipeline #177

KyleAMathews opened this issue Mar 7, 2016 · 1 comment
Labels
stale? Issue that may be closed soon due to the original author not responding any more.

Comments

@KyleAMathews
Copy link
Contributor

At the heart of Gatsby is a data pipeline that extracts data from files, transforms the data, passes the data to React.js wrapper components, and finally assembles these components into an app using React Router.

But the code that does this doesn't cleanly reflect this pipeline. In thinking this through, there's also some valuable extension points that could be added. A site should be able to intervene if desired at each step of this pipeline. This refactor would also make the code much more testable.

Some interesting possibilities this refactor should unlock.

You'd be able to easily integrate with a 3rd party CMS (or perhaps legacy CMS). Gatsby right now is tied to using files for pages that are actually on your hard drive. But with the right hook, a site could fetch pages from another system and return them to Gatsby. These "virtual" files could be written to a tmp directory (Webpack only understands real files) and everything should just work. Gatsby could also expose an update hook so while developing, you could update data in your third-party system which when pushed to Gatsby would cause the mapped tmp file to be overwritten causing a hot reload.

Another idea to chew on. It might make sense to only have one Webpack loader for all static files. Right now there has to be a separate loader for each file type e.g. md, html, yaml, etc. And extending Gatsby to support a new file type isn't supported unless you fork Gatsby. If Gatsby just had one loader for all page types, then supporting a new file type as a page or to override the core behavior would just mean adding a function in your app.js and adding a wrapper component. This would make choosing which files become pages explicit e.g. in app.js (probably) would return the file types as array of extensions e.g. ['js', 'jsx', 'md', 'json']. Having our own simplified "file transform" API would be much more simple then expecting people to learn oddities of Webpack loaders.

This was referenced Mar 12, 2016
@jbolda jbolda added the stale? Issue that may be closed soon due to the original author not responding any more. label Jun 11, 2017
@stale
Copy link

stale bot commented Oct 22, 2017

This issue has been automatically closed due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale? Issue that may be closed soon due to the original author not responding any more.
Projects
None yet
Development

No branches or pull requests

2 participants