What is Reddit's opinion of Next.js?

From 3.5 billion Reddit comments

Yeh I can relate, FWIW it does get easier with practice. But 100% agree that we’ve sort created as many problems as we’ve solved with modern JS.

there is a pushback happening with some newer frameworks like Astro.build trying to simplify things.

For React, if you haven’t tried Next.js, definitely give it a go, plenty of helpful documentation that could smooth things out for you.

Personal blogs of good people or products.

For example https://kentcdodds.com/blog for react stuff, https://tkdodo.eu/blog/tags/react-query for react-query stuff, https://nextjs.org/blog for next stuff, and so on. Basically, people or companies I've experienced that knows what they're talking about, I tend to follow to some extent or another. Usually by subscribing to their RSS feed and check in on them in my news reader app once in a while.

I mostly agree. I've said that the 3 best parts of angular are typescript, the di system, and rxjs. And ngModules by themselves are a bit annoying but they do multiple jobs and once you understand what you can do with them they aren't a terrible solution to a complicated problem.

There are some solutions to the library paralysis problem of react like next.js and I believe Uber recently released their framework that uses react as the renderer. But angular is still ahead a bit here I think because it's all designed together rather than developed separately and just glued together.

Personally though I disagree about jsx. Some things, like dynamic component layouts, are much simpler with jsx and in general I think it just feels nice to use.

But with the flexibility jsx brings it also brings the ability to overcomplicate templates as you are pointing out. It's a valid criticism where the best answer I have is "learn to not do that". It's not like people don't also write terrible angular components; it's just shifting the potential pain points.

I do agree that reacts biggest weakness is css. For a "view" library they certainly dropped the ball on one of the two fundamental parts of what a view is in a web browser.

I don't think the issue is that you are biting off too much. The issue is that you try to do too many new things at once.

Ditch prisma, ditch typescript and just try something simple.There is not reason why you shouldn't use mysql if that's what you are familiar with.either build a standalone API that will be consumed by your next.js app or skip this step and just do it in next.js https://nextjs.org/docs/api-routes/introduction

for connecting to the database use something like knex and play around... once you are comfortable with this ecosystem then add typescript and then aftewards add prisma or whatever you want

TY for v12 Next.js Team!.

Looks the the upgrade won't be hard due to small # of breaking changes (depending on projects but not for me ;p )

Time to enjoy the faster rebuild/refresh w/ Rush compiler.

Currently, not yet. Soon, yup.

The next big step in React seems to be Server Components where it's basically the component managing the data it needs on the server side (i.e. fetching) and delivers to the client only the code it needs (i.e. static DOM).

Next.js should naturally follow this path; maybe they'll address it during their conference happening on the 15th of June (https://nextjs.org/conf)

More info about React Server Components: https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html

So Next runs on both the server side and the client side.

Anything that uses fs must be run on the server side because fs is the Node file-system module. Importing it creates the error because whenever you import code, you also import everything which that code imports... unless it doesn't exist, then you get errors like this.

Try moving whatever logic you're using to an API route and then calling that API from your client.

😳ty. All the pages are statically built with Next.js and the proposals page is using a cool feature called Incremental Static Regeneration so that once per hour, it will rebuild the page with the latest data from the READMEs instead of using the cached statically-built page: https://github.com/saadq/proposals.es/blob/main/src/pages/index.tsx#L30

I'd recommend reading through the Next.js docs to better understand how you can use the framework. You can fetch data with client-side rendering and use Next.js as a single page app, just like Create React App. Then the question isn't "which framework is better?" but more so "which data fetching strategy makes the most sense for my use case?"

Next.js is an opinionated framework for building React applications.

React, alone, is just a library. To make an typical react application, you need much more than React. You need Babel to transpile your JSX. You need webpack to bundle your code into packages a web browser can consume. You need plugins and a bunch of configuration to make things like CSS/SCSS work. If you are building a Single Page Application (SPA), you need some library to handle routing (e.g. react-router). If you want to marry data from a data source (e.g. a database) to create a site using static site generation (SSG), you need an engine that renders static pages from your React templates based on the data. And so on...

Next.js solves addresses all those things (and more) in an easy to use package. Of course there are other frameworks that also address those things (e.g. Create React App). One of the main differences with Next.js is that is also provides a backend runtime that supports server side rendering (SSR) which is much better for SEO as the initial response from the browser is a fully rendered page instead of a skeleton that gets filled out a half second later with content when React spins up.

Next.js also provides more interesting approaches than simple SSR like incremental static regeneration (ISR) which combine some of the best parts of SSR and SSG.

Finally, Next.js also provides a basic set of capabilities for exposing APIs from the backend (which might otherwise have been created separately with an Express.js backend).

The front page of https://nextjs.org/ has a pretty good section on "Why?". You can do all the things that Next.js enables without Next.js, but it will be a lot of work. Next.js lets you focus on your application instead of on plumbing.

Hey! There are many ways to make a blog with Next.js. If you want to write in markdown, check out this example. You can also learn more about Markdown here. If you'd prefer using a CMS, there's a bunch of different variations of this starter that use different CMS providers.

Are you prepending your variables with NEXT_PUBLIC_ ? You’ll need to if you want to use them on the client.

https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables-to-the-browser

They have a whole section about converting create-react-app to next, which is pretty awesome. This is probably helpful even for a general react app.

1. You don't need to create a separate backend - you can use API Routes! If you already have an existing backend, you of course could just continue calling that. Next doesn't really care where your data is at :) Note the "custom server" in the docs is completely overriding the Next.js server, which is different than having your own Express server with an API that your Next.js app talks to.
2. getInitialProps is an older API, which has been essentially replace by getStaticProps (static) and getServerSideProps (server-rendered) is most cases. There's still a few use cases, but the majority of the time, you should be using the other two. You can read more about it on the original announcement post: https://nextjs.org/blog/next-9-3#next-gen-static-site-generation-ssg-support

getStaticProps is only executed at build time, so whatever data is present when you do your deployment is what's going to be shown on the site.

You have two options to fetch new data with getStaticProps:

1. Trigger a new deployment via a Deploy Hook
2. Use incremental static regeneration.

getStaticProps technically is, the props get injected at build time, but the result is a static artifact. Using getServersideProps will make any page no longer static. Data is read from each request and used to build the HTML to respond with on each call.

Next is technically a Node.js framework that spins up a server that returns a page which includes React at each route. It also supports server-side logic in the form of API routes. A Next.js app requires a Node.js runtime, so on that hosting website it would fit under the 'Services' category.

If you're not using any dynamic features of next, you can use Next's Static Export API to have a static-only bundle that can just be uploaded to and served from a file system. I have not used it myself, but it seems like it may fit your use case.

This, in combination with the native internationalized routing capabilities of Next.js: https://nextjs.org/docs/advanced-features/i18n-routing

Having both of these should get you pretty far. Also, don't worry about none of the languages being English. Most translation related libraries don't assume anything about a "base" language so you should be fine.

It's very important to also read up on the "loaders" section of the next/image documentation (https://nextjs.org/docs/basic-features/image-optimization#loader). If you setup a loader, Next.js doesn't actually do the image processing itself, it just creates a URL with image dimensions and quality for your image service to handle.

In your case you assume that all customers benefit from seeing the post cover as a 500x500 image, and not scaled up or scaled down. But different devices need different images. Some might benefit from a 1000x1000 resolution image, some 250x250. Some might want webp as a format, some can't handle that and want jpg instead.

Next/image makes all these decisions for you and adds some cool stuff like lazy loading and "blur up" image loading. Things you'd all have to do yourself or with an external library if you don't use next/image.

So, I would first reevaluate whether your architecture for a custom image back end in S3 is actually the best option. Why not use an image CDN built for this, like Cloudinary, Imgix, etc. Or create your own custom next/image loader and use any image CDN with enough features to your liking?

Second: check if you're not making too many assumptions about the devices people will use to check your application. If you let go off these assumptions you might find that next/image is a very helpful tool to serve images exactly the way your visitors need it.

Good luck with your project! 👍

It looks like environment variables are what you’re looking for: https://nextjs.org/docs/basic-features/environment-variables

These allow you to set a constant in a config file then use them in your code. On production you set a different value for this variable. Vercel, for example, let’s you set these variables for each environment.

There are two kinds of Next.js env variables too - ones the client can see which are good when you need an API endpoint for the client to switch (which start with NEXT_) and server side only Env variables which are good for things the client should never see.

Using this approach you could set a API_ENDPOINT variable and use that with process.env.API_ENDPOINT in your server side props function. If you need to use this variable on the client side, you’ll switch it to NEXT_API_ENDPOINT and access it from both.

I typically have the pages folder (as is required) and a sibling folder called src. This folder is usually broken down into client and server folders, and from there I would have stuff like you mentioned, components, styles, utils, etc, in the client folder.

You can cut down on path lengths by aliasing paths. I usually at least create a mapping to my src folder, but you can get crazier.

> There’s no actual client-side rendering for pages.

This is incorrect, I think. The initial render happens on the server, but once the client code (JS files) has finished loading, the rendering happens on the client again (as in, route transitions happen on the client, as with usual React apps). This has an explanation: https://nextjs.org/docs/basic-features/pages

literally the first thing on the docs > Recommended: getStaticProps or getServerSideProps

> If you're using Next.js 9.3 or newer, we recommend that you use getStaticProps or getServerSideProps instead of getInitialProps.

> These new data fetching methods allow you to have a granular choice between static generation and server-side rendering. Learn more on the documentation for Pages and Data fetching:

I see a lot of people here rightly pointing out performance issues with this site, but (given the title of this post) are people implying that the choice of Next.Js is at fault?

If static HTML export (or at least some sort of document response caching) is being used, server side rendering wouldn't exist to slow anything down, so the only real Next.Js-related performance bottleneck (on initial load anyway) could be "re-hydrating" the SPA's state to match the pre-rendered page, which I would imagine wouldn't be too noticable or significant.

So surely the main issue is their particular implementation, right?

Not an expert, but you are doing great. What you need to do is style the output.

Something like TailwindCSS makes that a breeze.

https://nextjs.org/blog/markdown

Or you can check this out

https://www.pullrequest.com/blog/build-a-blog-with-nextjs-and-markdown/

Best of luck.

You have to be explicit in what paths are to be rendered with getStaticPaths, even for a dynamic route. If you don't have a finite number of options for the slug, then you won't be able to prerender. Docs: https://nextjs.org/docs/basic-features/data-fetching#getstaticpaths-static-generation

To give a practical use-case for this, I built a site for a photographer recently. Several folders of images, varying numbers of images in each folder. I can use getStaticPaths to read each folder and create a path for each image. Each of these image pages is now prerendered and can be accessed via that slug now at the [slug] page.

I’d use a catch all route.

Let’s say you have a product page, pages/product.js.

This would get you mysite/product/some-product

To use a catch all route, rename product.js to […params].js and put the renamed file into a /product folder, like this: pages/product/[…params].js.

Now, you can add any amount of additional parameters to the URL and they’ll all be put into an array you can use on the product page.

For your request you would then use these URLs: - mysite/product/some-product - mysite/product/some-product/with-warranty - mysite/product/some-product/some-other-thing

Within product/[…params].js, you’ll now get an array like this from the router: - { “params”: [“some-product”] } - { “params”: [“some-product”, “with-warranty”] } - { “params”: [“some-product”, “some-other-thing”] }

For full documentation check out this page:

https://nextjs.org/docs/routing/dynamic-routes#catch-all-routes

I (and countless other devs I imagine) have tried this a few times and I think it's not as useful as it immediately appears. I'm not saying it's a bad idea or anything, but I am less enthusiastic because:

• not everyone will understand or want the technologies you choose to include
• there are many OK ways to set up a Django project, and not everyone will want the config style you choose
• you yourself may want to tweak something every time as you learn new things or develop new tastes, making your scaffolding less convenient

A lot of the work that a scaffolding tool, or any library really, needs to do is convince you that it's making all the right choices and that you can either understand the choices it made or those choices are abstracted away. create-react-app or nextjs come to mind as examples of this done really well. So it is possible, but I imagine it is also much, much more work than it seems to do this well.

Performance is a factor. By removing the need to download the js bundle before rendering and directly serving the HTML can mean the time to first paint is quicker, especially on a slower mobile connection.

​

The other motivation is SEO. Google has come a long way with processing javascript SPA however I've had problems in the past when data is loaded from an API. e.g. it may index the content contained within the js bundle but the posts loaded from a remote API may not be properly indexed.

Other applications also often rely on meta tags, e.g. Open Graph, Twitter Cards, etc. That often don't have support for SPA's.

Depending on your stack, for React projects https://nextjs.org is great option IMO.

Yes. As simply as installing the app (and prereqs like Node.js) on any linux VM and running:

next buildnext start

This can quite easily be in a docker container as well. There are many many places you could choose to host this way. Many places (I have tried both Azure and DigitalOcean) have app platforms that you can just point at your repo and they will detect that it's a node.js app and build the docker image for you every time you commit.

If you want serverless, the choices are reduced but there are still several. AWS Amplify does it, Netlify does it. I expect there are others, but those are the two I see most often. You can also roll your own if you want, it's just more work than the next start option above.

See for more details on both the Node.js and Docker options in the official docs here: https://nextjs.org/docs/deployment#other-hosting-options

Is there a reason you can't use the NextJS dynamic ?

​

https://nextjs.org/docs/advanced-features/dynamic-import

​

Might have better luck.

NextJS is a framework that includes a react based front end and a node based backend, so no real need to have a separate node backend.

You might be looking for this:
https://nextjs.org/docs/advanced-features/custom-server

Where you can override or extend the built-in backend of NextJS

Another great use case for Incremental Static Regeneration! In brief, you don't have to statically build any pages at build time then when they are viewed for the first time, they are statically built (very quickly in my experience). I explained a few details in this thread below, it's definitely worth reading through the docs too.

https://www.reddit.com/r/nextjs/comments/oumsvj/generating_20_million_personalized_pages_seeking/h73j3n8?utm_source=share&utm_medium=web2x&context=3

Nope, that's pretty much it. From the docs:

>Prefetch the page in the background. Defaults to true. Any <Link /> that is in the viewport (initially or through scroll) will be preloaded. Prefetch can be disabled by passing prefetch={false}. When prefetch is set to false, prefetching will still occur on hover. Pages using Static Generation will preload JSON files with the data for faster page transitions. Prefetching is only enabled in production.

It's worth noting that what is being prefetched is the props for that page, it's not fetching images or anything - so usually each prefetch is a handful of kB.

They're also cancelled if the user initiates another navigation I believe.

Also, if you are completely new to NextJS you might find this walkthrough helpful. It's not too long and walks you through the main parts of a Next app:

https://nextjs.org/learn/basics/create-nextjs-app

Oh, I’m in the same boat! Made a quick QR generator project for work using Next.js, but I didn’t explore many of the features and didn’t delve into data fetching on that one. I’m currently working on a portfolio built with Next, feeding data from a separate server running Strapi for the backend.

Here’s the Next.js docs on data fetching: https://nextjs.org/docs/basic-features/data-fetching

I’d keep the axios bit in there as it will be valuable for the employers not using next.js, but just so you’re aware for the next project :)

P.s I’d also recommend looking into something like Storybook that lets you separate your component logic from the pages, enabling you to create a single source of truth complete with docs on each component.

It may seem wrong, but what you are experiencing is simply how Next-js currently functions. They mention it under 'caveats' at the bottom of this page: https://nextjs.org/docs/advanced-features/automatic-static-optimization

Simply stated: if u add getInitialProps to _app, and actually need live data on each page, forget about static page generation. It would be nice if they added this functionality in the future, but it would somehow devaluate the use of static generation if some data on the page should still be fetched and the DOM rerendered.

For now: u could just use getInitialProps on the about.js page, disabling static generation all together. (Im still waiting for a way to use getServerSideprops on app.js)

It is, next has naturally a server that is used when calling getInitialProps in server side rendering or with the api routes, that I think it is the case you are looking for. Check https://nextjs.org/docs/api-routes/introduction

Do you have React experience? If so, I recommend just going with Vercel's own starter tutorial https://nextjs.org/learn/basics/create-nextjs-app

If you are new to frontend and/or React, I recommend starting there before tackling Next.

Like the other comment says, you do them as two separate projects. I personally prefer putting another app in a subpath instead of a subdomain though:

https://nextjs.org/docs/advanced-features/multi-zones

I think you're talking about getStaticProps and getStaticPaths in next.js. Here

OP, Do take a look at them, because they serve the exact purpose you're trying to solve and even have a bunch of examples to fiddle with.

You are correct – Next.js is server-side rendered (SSR) out of the box. During the compilation process, Next will look to see if your page uses getInitialProps or getServerSideProps. If it does, that page will be SSR. If it does not, it will render as static HTML. This is referred to as "static pre-rendering" and it's an optimization of Next.js.

Depending on the type of application you're building, a completely static site might have better performance than SSR. This is why Next.js 9.3 added getStaticProps and getStaticPaths to make it a complete static-site generator (SSG). This is discussed a bit further in their data fetching documentation. Static sites have many benefits:

• Globally scalable
• Save money hosting static files
• Faster performance by serving cached assets from a CDN
• No need to worry about server or database vulnerabilities
• Better developer experience – no complicated deployment process
  

If you want a tangible example, I just wrote a tutorial on Next.js 9.3. Happy to answer any other questions. Either SSR or SSG will be good choices for improved SEO over a client-side rendered (CSR) application.

Just to be clear what is collected is completely anonymous:

- No IP addresses are stored and your project is not identifiable in any way
- It's only enabled during development and build time, never during production
- Only plugins from a whitelist are tracked (for example @zeit/next-css, @zeit/next-sass and the likes) this helps us in deciding which features to develop or spend more time on
- The CLI gives a clear message when booting up for the first time in a project that telemetry is enabled and links to the telemetry page if you require more information.

Furthermore telemetry itself is now extremely common in large projects, including massively popular ones like VS Code.

Unlike these projects, Next.js does not track stacktraces which could include sensitive information.

Security, compliance, and transparency were top priorities in rolling this feature out, and a big motivation behind writing the blog post and making the twitter announcement.

Hi OP. Use a web framework like NextJS. This is the kind of problem frameworks are built for. What you're looking for specifically is dynamic routing (NextJS example), but you need to start at the beginning and learn your framework from the ground up.

Alternatively if you prefer other languages, there are many frameworks available to you.

• C# - use Asp.net
• Python - use Flask or DJango
• PHP - use Laravel, Drupal, or WordPress.
• Ruby - use Rails
• Java - use Spring
• JavaScript - use Nextjs (React), NuxtJS (Vue), Svelte Kit (Svelte), or Angular
• JavaScript - also you can use Express or Koa, and pair either with a template engine.
• Rust - use Rocket
• Deno - use Oak
• GO - use Gin
• Elixir - use Phoenix

There's too many to list, but they're all designed to do in their own way exactly what you're asking for. NextJS is really what you should use right now though. React / NextJS is a very high demand skill set right now, and is growing like crazy. If you become competent at it you can land a very well paid job at a multitude of companies.

Best of luck!

You could use a NextJS rewrite: https://nextjs.org/docs/api-reference/next.config.js/rewrites

You could add something like:

  async rewrites() {
    return [
      {
        source: '/products/lenovo12T:opt*',
        destination: '/product',
      },
    ];
  },

This would render the /product page for /products/lenovo12T and anything else after the 12T (like -with-warranty or whatever).

You can then read the opt param in the page component to see if it says "-with-warranty" or whatever you want.

You can do that by using catch-all-routes and splitting your string into an array. Example code:

export default function DayPage({ food }) { return <div>{food}</div>; }

export function getStaticPaths() { return { paths: [{ params: { food: ["food 12", "3 4"] } }], fallback: true }; }

export function getStaticProps(ctx) { return { props: { food: ctx.params.food } }; }

Codesandbox

Hey folks, Vercel's CEO here. We actively deal with problematic ISPs throughout the world on a regular basis. Our priority is to preserve access to everyone, everywhere, commensurate with local laws and regulations.

In some cases, ISPs are actively inhibiting a large part of the internet by taking an outdated and flawed approach to trying to protect their users. With the rise of privacy-preserving services like Apple's Private Relay, the idea of a single IP representing millions of users will only become more common.

We're taking action to get the IPs off that list right away. Whoever put the IP on that list, and the ISP that downloaded it, is punishing both "nextjs.org" which you use every day, and some other deploy in the same motion. We have a team on call 24x7 when abuse gets reported and it's handled appropriately, so this IP block ends up being completely unnecessary.

(Our Enterprise tier offers dedicated IP pools, but millions of subdomains and domains of our platforms can't each get their own. We must keep all of them online.)

I wouldn’t use redux for that use. You can do auth checks using next-auth and load the server side props to have them ready but only show them if the user is logged in. Or you can even use context to pass the global logged in variable.

Here is a few examples:

https://nextjs.org/docs/authentication

https://link.medium.com/LzpDNyFY1ib (this one uses context for state)

As a practice I use hooks -> context -> useReducer (which is still a hook) -> lastly Redux.. in that order..

I feel like too much state adds more complexity than necessary, plus added weight to your project which can hamper any performance gains you are looking to achieve.

Nextjs doc is both well-written and really easy to use. https://nextjs.org/docs/basic-features/data-fetching I highly suggest you rely on it, unlike most doc, you'll often only need this one to build your app.

Their example of getstaticprops uses data fetching to initialize components. However, it happens at build time.

I'm not using redux (as someone wiser than me said : "don't use redux until you really need it", and I've never needed it despite having a moderate size project), but the most likely answer is you should pass initial, raw data using getstaticprops, and then do redux stuff in useEffect hooks accessing the data returned by getstaticprops using props.

getstaticprops is happening at build time, so it doesn't have access to the component state of the page displayed in the user's browser. Again, I don't know redux.

It's tough being more specific without more info on what you're trying to achieve.

One final word of advice : tackling for nextjs and redux at the same time is probably a tough cookie. Try to get a grasp on nextjs and react first, then decide if you need redux or not. The answer is probably you don't need it.

Yes. Running the start script will start up a node server.

If you really wanted to you can even customize this node server, see https://nextjs.org/docs/advanced-features/custom-server. In which case end up with a server.js file and just run it like you would a server script with express. Next just hides that bit from you.

Hey u/Stackerito! I'm Delba from Vercel.

If you want to extend the Babel config, for example, by using "next/core-web-vitals", you have to set "next/babel" as your .babelrc file will be considered the source of truth and you'll need to explicitly define the next preset. There's more information on the Next.js docs here. You've configured it correctly and using an array for the "preset" option is a commonly used Babel convention.

For question 2, were you getting the error with or without "extends": "next/core-web-vitals" option?

What is your aim with adding the suffix?

If its just visual in the url bar, then you could make use of rewrites, either in nextjs or in your server (nginx, apache, etc)

https://nextjs.org/docs/api-reference/next.config.js/rewrites

I’d say use next image even still. Yes the file size and resolution optimization is moot but next image does a lot more than that, including lazy loading, blur/placeholder values, preloading high priority images, and more. It’s painless to use so why not? check the docs for more info

You can use getIntialProps, as explained here

https://nextjs.org/docs/advanced-features/custom-app

This has the side-effect of disabling automatic

https://nextjs.org/docs/advanced-features/automatic-static-optimization

Long story short, pages that don't have a getStaticProps method will not be statically rendered during build time but will instead be rendered at request time. Whether or not that is an issue depends upon your use case. If all the pages that you need to be statically generated have a getStaticProps method, then it isn't a problem.

make a new directory called store and add a pants.js page in it. But you will probably want to do some like store/[category].js though. Check out the docs on dynamic routes

So next.js recommend to use Api Routes to reverse proxy back-end(go, laravel),

then to consume inside SSR they provide Data Fetching this basically fetch data then throw the result as props

Quick note on this: as I understand, your CSS file needs to be named [component].module.css in order for it to be parsed as a CSS module when importing it into your component file.

Source

React apps can be deployed to pretty much anything, an S3 bucket for example. There's no "backend", you're just serving static files.

You can export static HTML from Next, but it does limit some of the features you can use.

If you're using a "standard" deploy of Next, you'll need to run it on a host that has node.js.

Not a big downside, but you should be aware of it.

Next can build static, just like gatsby. But again, if the SEO is coming async, google, link previews in iMessage, etc won’t like that.

I don’t know your serverless function, but it should be pretty cheap to serve this information and use nextjs getServerSideProps

https://nextjs.org/docs/basic-features/pages

With what your looking for the dream is incremental builds (single pages built by Netlify)

They're both great libraries, and are have great tooling to get up and running quickly. Vue is extremely intuitive if you're more familiar with traditional HTML apps, since you're writing templates in real html, rather than the html-like xml in react's JSX language.

It's a bit of an oversimplification, but the React ecosystem has tended to favor a more functional programming style, which Vue has a more object-oriented API (it has a more FP-like API with the new version 3). If you enjoyed your Ocaml/scheme/haskell unit in college CS, you might really enjoy React.

If you want to get started quickly, definitely use a "batteries-included" project generator/build tool like nextjs (for react), nuxtjs (for vue), or Vue's official CLI. All three are easy to get started with, but remain maintainable to use with large projects. In particular, Nextjs and Nuxtjs are really useful in that they have built-in static site generation and server-side-rendering options, which are extremely useful if you need to maximize performance and Search Engine Optimization

Preact is a pretty popular react-like library with a much smaller bundle size. Nextjs uses normal react, but allows offloading some or most of the runtime overhead by pre-rendering as a static site or server-side rendering on a nodejs server.

Page specific: The serverless target will output a single lambda per page. This file is completely standalone and does not require any dependencies to run:

pages/index.js => .next/serverless/pages/index.js

pages/about.js => .next/serverless/pages/about.js

Source: https://nextjs.org/blog/next-8#serverless-nextjs

You can do it, but here it is not necessary as you already have everything needed to render the script tag during build time. Your approach is good if you don't know i.e. the URL if the script only after fetching it from somewhere.

In Next.js stuff is added to the head like it is explained here: https://nextjs.org/docs/api-reference/next/head

I can’t share the exact code with you but NextJs recently released an example site and repository for a headless site connected with BigCommerce which is pretty close in implementation and a good starting point to see how they handle the basic store logic such as cart management, dynamic routing, checkout flow etc.

Take a look at this https://nextjs.org/commerce

And here is the example front end repo https://github.com/vercel/commerce

Next is a good choice as you can statically generate the majority of your pages and move a lot of your dynamic integration related stuff into their API folder which generates as lambda functions meaning you can keep a lot of the server side interaction, secrets etc out of the front end app that gets sent to the client

Well, no he has a point. Meteor is trying to sell itself to new people - not current users. So the meteor homepage is targeting who? A CEO? A Graphic Designer? Accounting? HR? or the developer?

If they are targeting the developer then they should at least answer a couple important questions or include a basic summary of the system.

> Meteor is an open source platform for web, mobile, and desktop.

...that enables you to prototype quickly and provides SSR, instant push updates, and magic unicorns. Meteor handles routing, isomorphic components, database migrations, and other tasks for you so you can focus on your application. (I'm not sure about all this, just guessing).

Compare Meteor with https://nextjs.org/ which does a much better job explaining it's useful ness.

• Server Rendering React
• Styled-jsx included
• Zero Setup
• Automatic code splitting
• filesystem based routing
• hot code reloading
• universal rendering.
• Fully Extensible
• Complete control over Babel and Webpack.
• Customizable server, routing and next-plugins.
• Ready for Production

I tried doing it using Next.js with mixed results.

I glanced at some blog posts like this one to play around with other options as well. In the end, I scrapped SSR as it didn't feel like it did what I needed it to do and it was becoming too complicated.

We've used it a couple of times now for smaller projects and I can say that it's so easy and quick to get something off the ground without worrying about other setups, as the name suggests it's also very fast using Esbuild, which does have it's limits ( for now ) but will change the way you work as a developer, with instant page reloads being the icing to the cake :D
I can't however talk for larger projects .... something like Next.Js might be a better place to go ( depending on the framework you want to use obviously ) as it's slightly older with more documentation / support and I think they've just switched over to using Rust for compiling ( https://nextjs.org/blog/next-12#faster-builds-and-fast-refresh-with-rust-compiler)

See getStaticPaths with fallback: blocking

https://nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration
https://vercel.com/docs/concepts/next.js/incremental-static-regeneration

It's trying to refer to a property on an object that doesn't exist. I'm not sure what is going on in getEventById() but the data needs to be fetched before the return is rendered. This usually has to be done asynchronously.

Try using a getServerSideProps function https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering

Nextjs offers routing out of the box, so you don't need to add an extra dependency. Others have already linked to the official documentation, and I'd say its a great way to start learning about it!

Edit: to add to the other resources linked here - https://nextjs.org/docs/routing/introduction

For what it's worth, I dropped styled-components a while ago for CSS modules (which works fine in Next 12 of course.)

Set a "theme" in a global stylesheet using root variables, like I did with this small project. And you're good to go.

If anyone says they need programmatic CSS I'd ask for receipts. I bet I can prove they've wasted their money.

With nextJS my choices would be static generation at build time, or server side rendering though, right?

https://nextjs.org/docs/basic-features/pages

Can you explain pages being rendered at run time vs ssr a little bit? If you weren't using ssr to do that, how would it work? Also when you say run time, what do you mean exactly? Build time would be the initial site load, and run time would be each individual request?

To deploy a Next.js application under a sub-path of a domain you can use the basePath config option. basePath allows you to set a path prefix for the application. For example, to use /app instead of / (the default), open next.config.js and add the basePath config:

module.exports = {
  basePath: '/app',
}

Source: Base Path

gotta hop on nextjs train, it does a ton for you.

improves lighthouse scores (page load times) dramatically over react.

you can make something like a serverless API just by putting javascript functions in ex pages/api/u/[id].js which become api routes automagically. There's no other way I'm aware of to make both frontend and backend so easily. https://nextjs.org/docs/api-routes/introduction

AND

they have a bajillion examples of it integrated with other tools: https://github.com/vercel/next.js/tree/canary/examples

All your requirements seem to be met by next.js and subsequently NextAuth which can easily work with MongoDB.

It has file-based routes and you can add your API under an „api“ folder where you could then define your functions.

I‘d suggest you read up on the docs :)

CORS is a security feature of web browsers and is independent of Next.js and React.

CORS is specifically designed to prevent one web page from making HTTP requests in code (e.g. via fetch or XMLHttpRequest) to another web site unless that other web site gives permission. This permission is indicated by HTTP headers returned by the other web site that list what web pages are allowed to talk to it. You can't externally enable CORS for a web site that doesn't support it, itself (*except by proxying it, see below)

CORS doesn't apply when you make a request to the same web server that the page came from (i.e. when you talk to the Next.js API routes). It also doesn't apply when you use HTML Forms.

The reason you're seeing this with redirects is that when you redirect an API request, you're the browser, "hey, talk to this guy instead". And so the browser will try to make a request to that other URL and CORS will apply if it is a different server (different server means different hostname or different port).

The way to make this work is either to only call APIs from other servers that support CORS and are designed to be used this way, or proxy the API calls through the Next.js backend either as API routes or you could try the rewrite feature, though I have not tried it with APIs and don't know how it handles things like Authentication HTTP headers.

I have no guidance on the China aspect of this, but...

If use "Next.js in SSG" means `next export`, then all that is needed is a hosting solution that can serve static files.

If, in contrast, they want `next start` type behavior in order to get things like ISR as part of their SSG project, then I would be inclined to build the site into a container (see the Docker part of the documentation). With the output of their project being a container image, all they need to find is a hosting provider that can run containers. Nearly all public cloud vendors make it trivial to deploy a web application as a container.

As I said, I don't have any China-specific advice, but I have to assume that there are hosting providers inside China that can do either of the above solutions. The first one might be more feasible, but it does mean losing some of the ISR-like capabilities that you get with an actual Next.js backend.

You're right, I'm wrong. I assumed it pre-rendered the HTML for server rendering and then hydrated it by passing JSON to the client React components.

This doc page says one of the reasons to use getStaticProps is when "the data can be publicly cached". https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation

I'm thinking that you likely can't used getStaticProps and protect your site very easily. Next.js likely bundles the code in such a way that only the js for a given page is loaded when the users navigates to that page, but you wouldn't be able to trust that.

So maybe your protected content needs to be loaded from some other endpoint which you can then protect. It could be loaded client-side since you don't care about SEO for this content anyway, and that would still allow you to host your site in a static way.

For for the lack of helpfulness. :)

hey not an expert but maybe I can point you somewhere 🤷‍♂️ at least with the [postID] question. take with a grain of salt because I don't know everything

pretty much all u wanna know is here

if you use getStaticPaths without a fallback then new posts will hit a 404 because the pages weren't generated at build time

so you need to set a fallback, probably fallback: 'blocking', when you return from getStaticPaths. then, when someone makes a request for a post that hasn't been generated, it will generate the page on demand.

the post page won't be generated immediately after the post is created, unless you redirect the post author to the [postID] after it's posted. then it'll be cached and ready to go

then in getStaticProps make sure to enable revalidation so that if a user updates their post it will get re-rendered with the new data the next time the page is requested.

that is a better solution than SSR on every request

Yes, it is possible.

You certainly have to have at least 1 DNS entry (CNAME, usually) to make any subdomain work at all. You could do a wildcard subdomain to keep it at just 1.

You'd then have to some kind of rewrite engine in front of your site to do the translation from subdomain to subfolder. If you are running the real Next.js backend (i.e. you didn't just export a static site), you can do this with Next.js rewrite rules with some regular expressions based on the host header and the request path. Otherwise, you can use something like nginx to do the reverse proxy duties with similar regular expressions.

Keep in mind that your next.js application code will still think it is running in a subfolder, so you'll have some messyness with internal site links.

First, I want to say that I don't think this is the right way to do what you're doing. Extending the built in router will probably cause subtle bugs further down the line and break in weird ways. It looks like you want to add a property the router to track an additional piece of data, and I think that would best be handled using your own custom hook and router events.

That being said, that's not what you asked for :)

In a fresh Next.js TypeScript project, I added an index.d.ts file and added it to my tsconfig.json file. In that index.d.ts file, I added:

/// <reference types="next" />

import { NextRouter, useRouter } from "next/router";

type Router = NextRouter & { from?: string }

declare module "next/router" { export function useRouter(): Router }

This redefined the useRouter hook to return a custom type, one that extends the NextRouter definition with a from field. In my application, I could now do:

import { useRouter } from 'next/router'

const Foo = () => { const router = useRouter() return <>String(router.from)</> }

And TypeScript had the correct types in place. Does that help?

Per Next.js documentation:

>When blur, the blurDataURL property will be used as the placeholder. If src is an object from a static import and the imported image is jpg, png, or webp, then blurDataURL will automatically be populated.
>
>For dynamic images, you must provide the blurDataURL property

(emphasis mine)

In other words if the src is an URL as you seem to use then it won't be blurred by default. You must provide a blurred image yourself. Otherwise you have to import the image statically.

Next.js with server-side rendering is very popular right now. I've been using it for 2 years, and I am pretty happy with it.

The alternative is a JAM stack (https://jamstack.org/). The hosting for it can be very cheap (in many cases $0), but you don't have SSR.

Generate the details statically, and insert a dynamic component where you want to display the user-specific data. Access the context from there. This part will be rendered on the client. See https://nextjs.org/docs/advanced-features/dynamic-import#with-no-ssr

I'm guessing that the component you're trying to import does something with the window object which in SSR is simply not defined. A simple workaround would be Nextjs built-in dynamic import https://nextjs.org/docs/advanced-features/dynamic-import#with-no-ssr

Are you using next/link for each of the links? Without that the page will refresh. Also in next.js 10 you no longer need the “as” prop in case you’re using that.

You need to update Next’s webpack configuration with a loader that supports that kind of asset. You can read about adding a new loader in the docs and you’ll probably want to use file-loader

Nextjs( ssr ) or gatsbyjs ( ssg ) they both shipping with webpack

Gatsbyjs

https://www.gatsbyjs.com/docs/glossary/webpack/

Nextjs

https://nextjs.org/docs/messages/webpack5

If I'm wrong tell me.

https://nextjs.org/docs/basic-features/data-fetching#getstaticpaths-static-generation use getStaticPaths to define the paths should be made at build time

getInitialProps is no longer recommended since version 9.3 (latest is v11) in lieu of getServerSideProps, or ideally getStaticProps.

Source: https://nextjs.org/docs/api-reference/data-fetching/getInitialProps

You don't need Express! Next has its own backend built in. https://nextjs.org/docs/api-routes/introduction

I meant that someone could get a hold of the public email address, and add it to some spam list which your app couldn't prevent.

Have you made other websites before? If you have, these might be helpful.

• Build a serverless website instead of paying for servers. You can host serverless websites on Vercel, Netlify, Hostman, and Qovery for free (but with rate limitations).
• Use a tagged Kanji dictionary. I recommend KANJIDIC+ It already has tags for JLPT level, WK level, and frequency tags.
• Use dynamic routes to map each dictionary entry to a different page: here's the guide if you're working with Next.js
• If you need free databases without credit cards: Atlas (Mongo), Supabase (Postgre), Qovery (MySQL)

If you need more technical guidance, you should probably ask on a different subreddit.

Ah, okay. Have you taken a look at these:

Tutorial: https://vercel.com/docs/next.js/incremental-static-regeneration

E-commerce kit: https://nextjs.org/commerce

The e-commerce kit is said to have ISR for its product pages. I would try to download it and deploy it to a test Kubernetes environment. Then, modify it as you please.

Majority of the time you’ll be using npm run dev. That boots up Next in development mode. It will rebuild the application as you’re coding (Fast refresh).

npm run build compiles the application as if it were to be published to a production server. This is output into the .next/ folder.

npm run start serves the built application. It’s essentially the final product. After you run this command any local changes will not be reflected until you run another build and restart it. Not ideal for development and should only be used for final testing or debugging.

This link from the docs explains things well (already posted below).

I would rather consider using a combo of link preload along with the Head component

Depends on your revalidation strategy, you can define the behavior of that exact scenario to either serve the user 5 posts while the page with 6 builds so the next user will get the newly build page or you can make the user wait for the build so you always serve 6.

https://nextjs.org/docs/basic-features/data-fetching#the-fallback-key-required

ISR is more specifically about updating static content once it's been created.

For handling new pages, the key detail is the fallback attribute returned from getStaticPaths https://nextjs.org/docs/basic-features/data-fetching#the-fallback-key-required

not really, its not the name the wildcard, but the double brackets, the name, of course, is mandatory, since it is the name of the params

https://nextjs.org/docs/routing/dynamic-routes#catch-all-routes

here you can find all the docs but just for reference

/post/[[...slug]].tsx

will match:

/post
/post/mypost
/post/2021/05/16/
/post/2021/05/16/mypost

and so on in the [[..slug]].tsx page you would need some logic to elaborate the given params, since /2021/05/16/mypost will be in the slug object

I'm not sure what your stack is, but I would add the menu items to https://www.sanity.io/ and statically generate it with a static site generator like https://www.gatsbyjs.com/ or https://nextjs.org/ that way you don't need a database and because it's statically generated you can host it for free on one of the many free-tier hosting platforms. Netlify, Vercel etc...

It's hard to tell without seeing the code. It's also worth noting that as of Next v9.3, it's recommended to use getStaticProps or getServerSideProps instead if you can upgrade.

you can use chrome devtools and also vscode debugger (if you use vscode) with Nextjs just follow this guide to configure your debug environment https://nextjs.org/docs/advanced-features/debugging

anyway, console.log is usually able to ‘explode ‘ objects and shows their content, type, size and so on