-
Notifications
You must be signed in to change notification settings - Fork 27k
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
next export
(static builds)
#604
Comments
How about if we ignore Is that something we could consider? |
Definitely. Client-only |
There are two forms of static sites. The one where the data is 100% static, and the one where it's not. And there's a hybrid where you ship props pre-computed with each page and data can still be fetched dynamically |
@rauchg React inherently allows the hybrid form trough its |
What type of static site is this command planning on exporting? Let's perhaps define them these ways:
|
Also, what exactly is the benefit of zeit:next exporting a static site? From my understanding, zeit:now will still wrap static sites in a node.js app (zeit:serve) - and zeit:now even trumps most static deployment options anyway. |
@balupton Allows one to host on github pages, aws s3, etc. |
@jferrettiboke @stretchkennedy Where internal links are unknown at "build time", I think the approach used by static-site-generator-webpack-plugin where you simply list all of the URLs it needs to render in one place, works quite well. Of course you don't want to be doing this by hand - I have a script that does this based on matching file names within a directory: find-posts ( Continuing conversation here from #604 ) |
But the only reason I can imagine of why people want to deploy to them is because they are free and quick hosting -however zeit:now + cloudflare accomplishes the same - with much more coolness |
@balupton Not really, if you have a static site which does not have to render the app or fetch data on the backend before it is sent to the server you can gain a lot of speed. This is the main reason I make static web-apps. |
@yn5 I think he's talking about using cloudflare's caching. For myself, the reason I want to render a static site is to lower the attack surface and to consume fewer resources. Deploying nodejs requires keeping more dependencies up to date than just deploying nginx, and wastes a perfectly good VM even if you put it behind cloudflare. |
I agree with the reasons mentioned by @stretchkennedy and @yn5 - but I'll also add that the over-arching goal should be to move towards being more permissive; rather than to restrict the options. If a particular site is truly static in nature, then why preclude having the option of being able to serve from a static host? Additionally, enabling zeit to work with a flow that one has already invested time in setting up and tweaking (e.g. in your CI/ CD pipeline), rather than having to set up a new flow, is a win. |
I'd like to toss in my hat on how I think this could work really well: static getInitialProps ({ build, req }) {
if (req) {
// server-side
} else if (build) {
// static build (can contains parameters about the page build)
// this happens at the time of the build (next export)
} else {
// client-side
}
}
The cool thing about this is that you can pull in markdown files and other resources (even pre-render a page) all from within that |
@matthewmueller would it be possible to eliminate code from Let's say you use an API to fetch live data during development and you want to "bake" it into a static build (both in the HTML and JSON representation of a page), to eliminate any API requests in production. This would be awesome for a collaborative workflow. To optimize the output you'd probably then remove the dependency on whatever API library you use to fetch data in static async getInitialProps ({ build, req }) {
if (build) {
return myCoolAPILib.fetch('foobar.csv') // Probably load myCoolAPILib through webpack's async import()?
}
} gets turned into: static async getInitialProps () {
return {
// Response from myCoolAPILib
};
} |
So how would you handle code splitting? Right now, for dynamically rendered pages, Next requests a JSON file with the components. Would these be statically published as well? |
@kbingman yep, i believe the json versions are built and written to the filesystem anyway. |
From a dev-ops, scaling, speed and pricing point of view, nothing beats a static page on S3. So this feature is actually super important for us. |
@kbingman those will be statically generated indeed as well |
Is anyone actively working on this yet? If not, I might give it a shot since I'm very interested in this feature. I did some spelunking in the next.js codebase and got an extremely rough proof-of-concept working by basically adding another step to the build using the server's As far as I can tell it's pretty straight-forward. One of the bigger challenges will be to deal with dynamic routes like |
@herrstucki
Thats what I'm looking for. I hope to find a way to generate pages from markdown-files, and list them in a dynamic-navigation. |
I agree with this. Would be awesome to have a react-powered Jekyll replacement. (I realize much of that blog functionality is out of scope). But this definitely would make next.js a solid platform for a larger audience who might want to throw things on gh-pages or S3. |
@kylehotchkiss Absolutely! This is exactly what I currently have in mind. |
@herrstucki I'm working on this a bit, happy to collaborate on a branch. definitely need this feature as well. I think this can be done entirely via the plugin system, then we can make it nicer / a bit more native later. @schoenwaldnils you could achieve that sort of functionality by passing a Regarding routing, at least for an initial implementation, I think only the development server needs to be route-aware, which you can achieved with a custom server. When you export to static, a service like Cloudfront or netlify can take the routing from there and you can use |
PR has landed: #1576 💥 |
Now we've "next export" support built into the core. |
Great to see this happend. Amazing work guys! |
Hi, |
How do you guys handle DOM events with [EDIT] on Mac I need to manually change all |
@juliandavidmr @sbe88 |
This might be built in (if it's not too opinionated), or a separate "core module" (if it has too many "options").
The idea is that one will be able to run
next export
and yield abuild
directory that doesn't require a server.next export -o customDir
should be possiblegetInitialProps
to have pre-rendered data when it's first loadednext.config.js
(export
object)The text was updated successfully, but these errors were encountered: