When you're reading code there are a few things which make the process a lot easier, particularly when it was code written by other people.

1. It's commented well.
2. It's written in a logical way.
3. Lines of text aren't really really long meaning you have to side-scroll.
4. The formatting is consistent.

There's not a lot we can do about the first two other than having a good team, but the second two are something that can be automated and enforced.

In many languages (particularly front-end code) there's a tool named prettier that can configure everything from tab spacing, line length and even if you end a line with a semi-colon or not. I've used it for years and it's brilliant. Unfortunately, it doesn't support C#.

A tool I have found though is CSharpier (https://csharpier.com/), and like Prettier it is an opinionated code formatter.

Add CSharpier to your project

To get started with CSharpier first create a tool-manifest file in the root of your project and then run the install command.

You can do this with the following terminal commands.

Next add a configuration file to your project so that all team members will produce the same results.

To do this add a JSON file named .csharpierrc.json to the root of the solution.

After you add CSharpier you will want to reformat every file in one go, otherwise your going to spend a year going through PRs mostly containing format changes as every file gradually gets reformated.

Do this with the following command.

Configure Visual Studio to auto format on save

There's lots of options for triggering the format; You can do it manually, on Pre-commit hooks, or within CI tools, but I find the best is to have a file format on save. This way not only is it making your code readable to everyone else, it also makes it easier to read as your working on it. Plus when tab spacing doesn't fix itself correctly its a good indication there's something wrong with your code.

To do this you will need to install the Visual Studio extension https://marketplace.visualstudio.com/items?itemName=csharpier.CSharpier

Once installed you then need to configure it to format on save. This is located under Tools | Options | CSharpier | General and can either be configured at a global and project level.

And that's it. Now whenever you save a file it will automatically get reformated.

If you’ve used NextJs then you will probably be familiar with how it handles routing using the file system.

Files named page.tsx are organized into folders and the name of the folder becomes the name of the route. E.g. If the folder were named about-us then the route on the site will be /about-us. To create a page under another page, simply create a folder within a folder. E.g. company/about-us/page.tsx becomes /company/about-us.

Page names can also be dynamic, to do this you use a catch-all route which is defined with square brackets in the folder name. e.g. [slug]/page.tsx.

Now all requests to the route of the site which don’t match a fixed path will be picked up by this page and will include a parameter matching the name within the square backets (in this example “slug”), which you can then use to render the page dynamically.

Dynamic pages can also be nested. E.g. [category]/[product]/page.tsx. In this example a request to /electronics/50-inch-tv will route to the page including the parameters category=electronics, and product=50-inch-tv.

By using triple dots in-front of the parameter name NextJs will catch all requests to subpages and provide the hierarchy as an array to the parameter. E.g. […slug]/page.tsx will capture requests to /company/about-us and have a parameter named slug with the values [‘company’, ‘about-us’].

This is all explained on the NextJs site in detail https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes#catch-all-segments

However, the one thing you can’t do is have two or more dynamic paths at the same level. E.g. Creating…

/[category]/page.tsx

/[slug]/page.tsx

Will lead to an error saying "Error: You cannot use different slug names for the same dynamic path".

The official way to have more than one dynamic path is to separate them by placing one into a subfolder, so in my scenario I could have…

/products/[category]/page.tsx

/[slug]/page.tsx

Now any routes starting /products/ will be routed to the category page rather than the slug page. However this typically doesn’t match the requirement and hasn’t been needed for the majority of sites being built with a CMS.

Creating multiple dynamic paths in NextJs using one catch all page

The first option for enabling multiple dynamic paths at the same level is to have one catch-all routes and within that file figure out what the page should be. E.g. /[…slug]/page.tsx

Now all requests to the site will be captured by this route and within the page you can write custom logic to determine if the first value is a category or generic page.

To keep code clean the actual rendering of the different page types can be split into separate components with page.tsx handling the logic for which to include.

This setup works well, however it has a tradeoff that a lot of functionality provided by NextJs through it’s folder structure is lost. E.g. NextJs support layout files at different levels of the file system but here you would be restricted to just the one.

Creating multiple dynamic paths in NextJs using rewrites

An alternative method is to structure the dynamic pages into separate subfolders as per the official way and then hide this using Rewrites.

What is a Rewrite?

A rewrite is like a redirect, but one that happens server side and is therefore invisible to the user. When a request goes into the server it is first checked against the rewrite rules and if it matches one, the request is rewritten to that URL rather than being passed as it to the application.

Anyone old enough to remember programming in Classic ASP may remember this being one of the methods first used to implement friendly URLs rather than having query strings for everything dynamic.

How to setup a rewrite in NextJs

Rewrites are configured in the next.config.mjs file.

In this example I am creating a re-write for anything going to a path starting /electronics/ to route the request to the path /products/electronics/

Hardcoding the list of categories as re-writes isn’t much better than creating a lot of hard coded sub-folders, but this is easily fixed by dynamically writing the list which will happen when the site is built.

Creating a redirect in NextJs

The solution now works, however any requests to the /products/ url will also resolve as duplicate pages. To overcomes this we can create a standard redirect to put people back on our preferred path.

One thing to be aware of

While this is a solution that will work, one thing to note is that there may be a limit to how far it will scale. If you hit the point of creating over 1000 redirects or rewrites the NextJs build script will start warning of potential performance hits from there being to many redirects.

This isn’t something I’ve experienced, but each rewrite is effectively another check that needs to be performed against each request.

Imagine the scenario your developing an API in .NET 6 and a front end in React. Locally you'd like to run both your API and front end and have the front end call the API. That's when you discover the CORS issue.

What is CORS?

CORS stands for cross-origin resource sharing. It's one of the browser's protections against malicious activity that checks with a server if the domain a request is originating from should actually be able to call HTTP endpoints on the provider.

The server (that's your API) will return if a domain is permitted to make a request to a given endpoint or not. If it's not you'll see a CORS error in the browsers network tab.

When your API and front-end code are running on the same domain this isn't an issue because there's no cross-origin to deal with. However, locally your front-end and backend api are likely on different localhost ports.

How to update ASP.NET CORS settings

In your program.cs file where builder.Build() and app.Run() are being called we need to add some extra logic.

To avoid this having any effect on production you can also wrap is in an environment check.

Using debugging tools when you're developing is something that in my mind is absolutely essential, and I'm shocked whenever I see people response.writing out values to work out what's going wrong in there application. In the past I've written about debugging VueJS in VS Code and the setup for NextJs is somewhat similar.

With VS Code you have launch.json file which instructs how VS Code should start an application in debug mode when you hit F5.

Launch.json for NextJs 14 using app router

The launch.json file for NextJs 14 is very simple and consists of the following:

Launch.json for NextJs 13 using page router

The launch.json file for NextJs13 is slightly different. This one also includes an attach option which will attach to the running process if you've already manually started NextJs from the command line.

This file will also work for NextJs 14, however I found that any component marked as "use client" doesn't hit any of the breakpoints in client side code. It also doesn't trigger chrome to open when the application starts.