Code Climate is one of many tools that can help you spot issues in your codebase: duplication, complexity, code smells, and so on. This PR demonstrates a simple configuration for Code Climate to ignore and include only files related to our application's code.

The following is an initial report:

Keep in mind, however, that Code Climate and other static analysis tools should not have more relevance in decisions than developers themselves. They are helping tools, such as ESLint, etc, and as such, anytime you believe the tool is wrong, feel free to contradict it. In our report, for instance, it complains of some SVG files being almost identical – but in that case, the abstraction of such a "static" content would harm code clarity, not help it.

More robust solutions such as Sonar's SonarQube, but these are usually tricky to setup, and have many environment requirements to start working. Code Climate is less impressive, but it's an easy tool to include in your workflow, as it's a third-party service.

This PR holds some improvements and fixes necessary for the upcoming authentication lesson.

• [x] Full implementation of mergeOptions as shown in the live demo.
• [x] Added PUT, PATCH and DELETE methods, for ease of use.
• [x] Added client instance as parameter (inside a context object) of interceptors for self-referencing.
• [x] Added async support to interceptors.

This PR intends to address three things, which are separate in the ~~3~~ 2 commits:

1. Enable server-side rendering of styles (thanks @serhanguney for pointing the issue)
2. Functional component at _document.tsx (thanks @tonycastle for questioning this)
3. ~~Decouple styles SSR from Document logic~~ this was moved to a separated PR.

Each of these commits have comments on the tricky parts, go check it out!

This PR intends to fix some coupling that we identified, especially with UI components living in a module that ain't related to that domain. On top of that, we try to rethink the domains we have, and, as the application evolved, evolve the architecture to reflect the domains we now know exist.

Consuming variables from process.env in multiple parts of your system is a know problem, sometimes even for security reasons. But beyond that, there are some tasks involved in this consuming of env variables that's just repetitive: checking if the value is present, typing the value, etc.

This PR solves it by introducing a main controller for environment variables with these common tasks simplified.

When codebase grows, so does each module/feature's complexity. In a short time, you end up consuming module's assets directly, making it very hard to refactor these modules without touching other parts of the system. IDE tools can help with these refactorings a lot – for instance, by automatically changing import paths when you move some file – but better than that is to remove the problem altogether.

On this PR, we establish each feature as it's own "API", exposing to other modules only what is needed to be exposed. It reduces bloated code, as imports get simpler, and improves predictability, as you from a consumer perspective won't need to navigate path of other modules to consume whatever you need from it.

Yet another helpful way to understand software and spot room for architectural refactoring is to actually put it in a visual way. Dependency cruiser helps us with that.

We won't go deeper on details of this tool, but by implementing it here I hope it serves as reference and inspiration to your own projects. This is what it looks like (click to open an interactive view of it).

Analysing code bundles might be a good source of inspiration on how to reorganize your code or identify heavy files to refactor. Keep in mind this analysis is usually polluted by external codebase, such as React itself, which tend to take a bigger part of your bundle than your own code.

This PR introduces a shortcut script to start the bundle analyzer that is already present in Next.js.

Sentry Issue: NEXTJS-H

TypeError: Cannot read properties of undefined (reading 'grey')
  File "app:///_next/server/webpack-runtime.js", line 33, in __webpack_require__
    /******/ 			__webpack_modules__[moduleId](module, module.exports, __webpack_require__);
  File "app:///_next/server/webpack-runtime.js", line 33, in __webpack_require__
    /******/ 			__webpack_modules__[moduleId](module, module.exports, __webpack_require__);
  File "app:///_next/server/webpack-runtime.js", line 33, in __webpack_require__
    /******/ 			__webpack_modules__[moduleId](module, module.exports, __webpack_require__);
...
(5 additional frame(s) were not displayed)

⚠️ Warning

The changes contained in this PR are considered advanced, and won't be part of the final application. We'll leave it here as a reference and for learning purposes.

This PR builds on top of #19 to improve UX by redirecting users from protected pages before hitting the client-side.

⚠️ Warning

The changes contained in this PR are considered advanced, and won't be part of the final application. We'll leave it here as a reference and for learning purposes.

This PR builds on top of #18 to improve security by leveraging API Routes and cookies.

⚠️ Warning

The changes contained in this PR are considered advanced, and won't be part of the final application. We'll leave it here as a reference and for learning purposes.

We've covered how to go further on UX and state managing by adding touch states and abstracting form state managing to a separate hook. Now, what about we make this whole logic reusable to other forms?

This PR builds on top of the the previous login form state managing to cover:

1. Extract form state management from useLoginForm to useForm
2. Make form state generic, so it can be used with different form inputs (code)
3. Update useLoginForm to use useForm (code)

That's it! Now we could potentially use the same useForm hook to other forms with have :)

⚠️ Warning

The changes contained in this PR are considered advanced, and won't be part of the final application. We'll leave it here as a reference and for learning purposes.

With the introduction of login form state management after Lesson 08: Built in React APIs, we've learned how hard it can become to handle form state manually – input values, validation states, errors, submit state, etc. And, if we manage to have the state itself working, chances are the UX won't be the best anyway. That's probably enough for us to realize how form libraries are essential to building high-quality forms in our applications.

But, what about we push a little bit more, and pretend there was no form library at our disposal? Turns out this is a great opportunity for us to play around with React APIs.

This PR builds on top of the the previous login form state managing to cover:

1. Abstract away form submitting logic and state (code) – let your handlers care for the application needs only (code)
2. Abstract away low-level event handling (code, code, and code)
3. Touch states
   1. Mark inputs as touched when they stop interacting with an input (code)
   2. Bother users only after they have interacted with the input (code)
   3. Or after as soon as they try to submit the form (code)

⚠️ Warning

The changes contained in this PR are considered advanced, and won't be part of the final application. We'll leave it here as a reference and for learning purposes.

This PR intends to showcase two things:

1. Real world use case of a HOC (Higher-Order Component)
2. How to use HOCs to decouple concerns

The idea here is we abstract away the whole styles SSR logic – which was copied from Next.js' official styled-components example – out of the _document.tsx page. The intention is to isolate the complexity of this styles SSR process, and make our custom Document as simple as possible, with only application concerns and not low-level SSR concerns.

Besides that, having the styles SSR encapsulated allows the Document to embark other eventual getInitialProps needs that might become necessary, without us having to mingle the complexity of multiple different concerns.