This notes are the result of having done this tutorial with some modifications like add SASS and TypeScript.
In Next.js the routing is made taking the pages folder structure as the source of truth, their functioning is pretty simple, if we need a file in the route:
- domainName.com/posts/first-post the file needs to be called
first-posts.js
and will be placed in pages/posts - domainName.com the file needs to be called
index.js
and will be placed in used needs to be in the pages folder - domainName.com/about the file needs to be called
about.js
and will be placed in pages/about
Allows to do client side navigation this means that the page transition happens using JavaScript, instead of the browser -with the <a>
tag, the navigation is with the browser- when the navigation is in the browser the page is recharged. Apart of this, the <Link>
component function almost like an <a>
tag but taking in account the next.js Routing, as example, if we need to go to the route:
- domainName.com/posts/first-post, the
href
property of our Link component will be/posts/first-post
- domainName.com, the
href
property of our Link component will be/
- domainName.com/about, the
href
property of our Link component will be/about
Something interesting about this component, is that in a production build of Next.js, whenever Link components appear in the browser’s viewport, Next.js automatically prefetches the code for the linked page in the background. By the time you click the link, the code for the destination page will already be loaded in the background, and the page transition will be near-instant!
Note: If you need to link to an external page outside the Next.js app, just use an tag without Link.
If you need to add attributes like, className, add it to the tag, not to the Link tag. Here is an example.
More information about the routing here is the documentation and this is an introduction
- Are in the public folder and can be referenced with the same logic as the
href
property reference the pages file, for example, a static file in:
<!-- public/my-image.jpg` will be referenced as -->
<img src="/my-image.jpg" />
<!-- public/logo/my-logo.jpg` will be referenced as -->
<img src="/logo/my-logo.jpg" />
- Public directory can't be renamed
- The files inside the public directory can't be named as any file in the pages folderyarn dev
- Is added with the
<Head>
component the documentation of it is here - Something interesting to note is that
<Layout>
and<Index>
have different data in their<Head>
tag, and this two metadata sources are fused into one.
<meta name="viewport" content="width=device-width">
<meta charset="utf-8">
<link rel="icon" href="/favicon.ico">
<meta name="description" content="Learn how to build a personal website using Next.js">
<meta name="og:title" content="Next.js Sample Website">
<meta name="twitter:card" content="summary_large_image">
<title>Next.js Sample Website</title> <!-- This comes from the <Index> -->
<meta name="next-head-count" content="8">
-
We can find the tutorial to use SCSS files in our project here, this project is already using Sass
-
Since Next.js 9.3 Sass is natively supported, for this reason the next-sass plugin isn't required and instead of node-sass, the dependency is sass.
- To set global styles, first is necessary create a _app.tsx file (.js if the project doesn't use Typescript) with the same config used in this project, in this file will be imported all the stylesheet needed globally.
- Next.js only accepts SASS modules or global stylesheets.
- The module stylesheet can't be imported with destructuring, to use the classes we need to do something like:
import styles from "./layout.module.scss"; <div className={`${styles.container}`}></div>
- Here the information is pretty clear
- The web page life cycle in:
- Pre-rendering is: Server -> HTML -> JS
- Without Pre-rendering is: Server -> JS
- The JS step is called Hydration and it gives interactivity to the pre-rendered page
- Here the information is pretty clear.
- The rendering method can be selected per page.
- Static Generation
- Pre-render the page at build time.
- Is the recommended way and should be used, unless SSR is the only option.
- Is the most performing way because the page isn't generated every time.
- Server Side Rendering
- Pre-render the page in every request.
- Is the best option if the data is updated after the build time.
- The pre-rendered can be completely by passed in favor of client-side javascript render in order to populate the data
- Important, In development mode (when you run npm run dev or yarn dev), every page is pre-rendered on each request — even for pages that use Static Generation.
- The build process is,
next build -> fetch data -> generates the HTML
, this generated HTML include all the data fetched in the build, for this reasongetStaticProps()
isn't recommended if the data will change in every user page request, in this case, is better try Server-side Rendering withgetServerSideProps()
or skipping pre-rendering and use javascript render to fetch the data on client side, but this last is used when the SEO isn't important. getStaticProps
runs only on the server-side. It will never be run on the client-side. It won’t even be included in the JS bundle for the browser. That means you can write code such as direct database queries without them being sent to browsers.- Important, In development mode, getStaticProps runs on each request instead.
- it's value is
true
the paths that have not been generated at build time will not result in a 404 page. Instead, Next.js will serve a “fallback” version of the page on the first request to such a path. - About the fallback pages
- Here the information is pretty clear.
- You should use
getServerSideProps()
only if you need to pre-render a page whose data must be fetched at request time. Time to first byte (TTFB) will be slower than getStaticProps because the server must compute the result on every request, and the result cannot be cached by a CDN without extra configuration. getServerSideProps()
can only be exported from a page, not a component.- More data about this method can be found here
- This is better in pages where the SEO isn't important
- To do this is recommended use the custom hook
useSWR
here we can find more info - The process is:
- next build
- Static generation: of parts that doesn't require the external data
- Fetch data in client: and populate the remaining parts.
- It works with dynamic pages (the ones with
[]
in it's name) - Here the description with the graphics are very clear.
- There are some comments in the
parsePostData.tsx
and[id].tsx
files. - In Development runs in every request, in Production runs in build time
Notes:, the markdown file in the posts folder has a metadata section at the top containing title and date. This is called YAML Front Matter, which can be parsed using a library called gray-matter.
- About Link
as
prop is the path that will be rendered in the browser URL bar. Used for dynamic routes
- The documentation here is pretty clear
- In next is possible generate API resources, it can be done inside the files inside the api folder located in the
pages/api
- The endpoints have the same shape as the node.js middleware.
- There are some built-in req middlewars and res helper methods.
- The API routes precedence is this
- Have the same logic as the pages router
- Here the information is clear
- Do Not Fetch an API Route from getStaticProps() or getStaticPaths()
- See the info here
- This are the steps to deploy the project, is very straightforward
- About the difference between JSX.Element, ReactNode and ReactElement
- About the Next.js types