Forem: Michael La Posta

In a World with AI, Where Will the Future of Developers Lie?

Michael La Posta — Thu, 25 Apr 2024 14:30:00 +0000

Ever since OpenAI released ChatGPT, AI has been at the forefront of many discussions, including people wondering about the future of work, among other things.

People are worried that AI will take their jobs, and I personally believe that developers are no exception. A belief that a lot of other developers don't seem to share at the moment.

Now of course "AI" isn't a new thing, as it exists in perhaps more basic forms in many of the tools we already use every day. But the kind of AI that's being developed now is a lot more advanced, and it's starting to encroach on areas that were previously thought to be untouchable by computers and/or machines.

The Rise of ChatGPT and Large Language Models

When ChatGPT was first released, I'll admit I didn't pay much attention to it. I figured it was just another chatbot, and I didn't see how it could be much different from the ones I had used before in a professional setting.

But I kept seeing "LLMs" pop up in discussions online, and I started to see some of the things that people were doing with it. I saw people using it mostly to generate code and write content, but eventually other things as well.

It was at that point that I realized I needed to start paying attention to ChatGPT and LLMs, and get a better understanding of what they were, and how I could use them to my advantage.

What is a Large Language Model?

I won't bother trying to explain what an LLM is, because frankly, I'm not smart enough to fully understand its complexities! 🤪

But my basic understanding is that essentially, it's a model (code) that's been trained on a massive amount of existing texts (and data), and is able to make predictions of the next most probable word in a sentence based on the words that have come before it.

Geeks for Geeks has a much more in-depth article on the topic if you're interested in learning more.

For things like computer code especially, where the rules are somewhat straight forward, it's easy to see how LLM-based AI can really shine.

Using ChatGPT to be more productive

When I finally decided to look into what all the fuss was about a few years ago, LLMs had already been gaining quite a bit of momentum, and had increased in complexity quite a bit.

So I tried it initially for some useless things like asking it how it was doing, or to tell me a joke.

But I quickly moved to testing it out with code snippets, using GitHub Copilot in VS Code, and I was blown away by how well it could predict what I was trying to write.

I mean it was entirely wrong a lot of the time... probably like 50% or more of the time. And often it would get into these endless loops where it would repeat the same 5 to 10 lines or so of code over and over again.

But when it got the code right, holy crap was it ever right! A bit eerie really, as it was able to predict what I was trying to write before I even finished typing it out. It was like having a pair programmer that was able to read my mind.

But was it really making me more productive? I mean, I was able to write code faster, but I was also spending a lot of time correcting it. And I was also spending a lot of time trying to coax it to suggest the code I wanted.

But I digress...

Are Developers Doomed?

Ok, so back to the topic at hand: the future of AI and developers.

Whenever I see this topic come up online, it's quickly shut down by a lot of devs who say that AI will never be able to replace them because there's just too much creativity and problem solving involved in what they do.

Developing an application isn't just about hacking code after all.

It's about understanding the initial problem or design request. It's about getting all of the details, and understanding the requirements. It's about architecting the environment and figuring out what framework, DB, and APIs will be needed, how to structure the code, and how to make it maintainable and scalable. It's about testing and debugging, and making sure that the code is secure and efficient.

So there's a lot of creativity and problem solving involved in what developers do, and it's not something that can be easily replaced by a machine... Yet.

And I think that's the key thing here: LLMs might not be able to do everything yet, but they're getting better all the time. And as they get better, they're going to start to encroach on more and more of the tasks that we do.

It's not just techies that are at risk

If you follow some of the AI-related forums online, then you might have come across some of the images that some people are generating with AI. Or perhaps you've seen some of the videos or "movies" being created by AI.

Some of them have pretty obvious flaws, like people with three arms, extra fingers, faces that are all distorted, or things like cars appearing out of nowhere or seemingly gliding sideways on the pavement. But some of them are pretty convincing, and it's getting harder and harder to tell what's real and what's not.

But in the case of AI-generated code, AI-generated images, and AI-generated videos, they all have one thing in common: "AI Prompting".

AI and Prompting

So what is AI Prompting?

Well, in a nutshell, prompting, as its name implies, is simply the process of giving the AI a starting point - basically the instructions or directions to get started, and then letting it generate the rest of the content based on that starting point.

You can prompt with a simple sentence like "Using typescript, provide me with code to connect to a T-SQL database using [insert library name]", or you can prompt it with much more complex, multi-sentence, multi-paragraph instructions that go into a lot of specific detail.

From what I've seen, the really well done AI-generated content is usually prompted with a lot of detail. The devil is, after all, in the details right?

Creators - or Prompters?

In the context of using AI to generate content - whether code, images, music, videos, etc., do you even really need to know how to create the content yourself when you have AI at your disposal?

I think the answer is both yes, and no.

I think for simpler AI generation, you can get away with having no knowledge or training in the area that you're generating the content for. But for more complex AI generation, you're going to need to have some kind of a basis in the area to understand or recognize when things go wrong, so that you can fix the issues.

And so we come to my point: Developers, more and more, are going to need to learn how to prompt AI.

The Future of Developers

In fact, this is exactly what my prediction revolves around - the need to understand proper AI prompting.

I see companies leaning more and more towards senior developers, and less so intermediate and junior developers. You can see it already in the postings for jobs online, where most postings are for senior devs, or "intermediate" devs with a resume (but not salary!) that reads like a senior dev.

Now I'm not necessarily saying the shift right now is because of AI. Just that companies already started trimming the fat after covid, and as always, continue to look for any ways to reduce the workforce to save $$$, and AI is a possible way to do that.

My Prediction

Ok, so finally, my prediction is this:

Going forward, as AI becomes more commonplace in tech companies, I believe that tech companies will stop, or at least limit, hiring beginner and intermediate devs. Instead, they'll hire only for a new role for a hybrid type of dev; one that has a lot of experience coding, but has also mastered the art of prompting AI to generate production-ready code.

Essentially, a Senior dev/QA type of hybrid role. A bit like an AI code whisperer, if you will.

The job of this "AI code whisperer" will essentially entail doing AI code prompting as the primary function, but being experienced and knowledgeable enough in multiple languages and frameworks to fix any issues/bugs, or possibly to prompt the AI to fix them when it's wrong. But the main criteria will be to know how to prompt the AI to architect and code the application from start to finish.

Since when can humans predict the future?

If there's one thing humans are really bad at though, it's making accurate predictions about the future, and I'm certainly no exception.

So take my prediction with a grain of salt. I'm probably way off.

But I think it's an interesting thought experiment, and I'm curious what other people's thoughts are on my "AI code whisperer" prediction.

Am I crazy? Or do you think I might be onto something?

Let me know what you think in the comments, and if you disagree, why?

Google's Decision to Effectively Kill-off Small Sites

Michael La Posta — Tue, 02 Apr 2024 17:39:41 +0000

I'm a relatively new blogger, having only started my blog around 6 months ago. I started my blog simply because I enjoy providing helpful information to others, especially when it's from things I've learned or experienced first hand.

In fact, I love spreading knowledge and info so much that I used to write a monthly newsletter for the tech company I worked for, which went out to employees and management across several continents.

Ok ok, I'm making it sound bigger than it really was... the employees I sent it to were limited to the same department as me. But it was still read by several hundred people, and when I decided to retire the newsletter, I received emails from a lot of the employees begging me to keep it going!

Years later, at the same company but in a different department, I joined a team that wrote and maintained the knowledge base for the department, and I absolutely loved it. The employees that used the KB reached out to me regularly to thank me for making the info so well organized and easy to read/follow.

So when I started my blog, I was excited to be able to share my knowledge and experiences with a wider audience, but I made two cardinal sins according to the "SEO gods":

I didn't niche down enough.
I didn't focus on a single, specific topic.

Forgive me SEO gods, for I Have Sinned

What did I do instead? I started my blog writing about two of the most saturated topics on the web ... travel, and tech. 🤦‍♂️

Yeah, I'm that dumb.

But see, I didn't know about the whole "niche down" thing when I started. I didn't even know there were "rules" to blogging and sites in general. I just wanted to write about things I enjoyed, and experiences I learned from. Pfff, what a fool I was! 🤪

And even worse, I'm neither an expert on travel, nor an expert on any tech! I'm just a regular guy who enjoys both, and who has learned a lot about both over the years. But I'm not an expert in either, and I never claimed to be.

In fact, with respect to tech, I consider myself a jack of all tech, master of none. I've dabbled in a bunch of different computer languages, stacks, frameworks, environments, used various different DBs, etc. But I mean, that's kind of a requirement when you're in tech these days isn't it?

But I digress...

The Start of my Blog

So, I started my blog, writing about things I've learned, things I've experienced, things I've found helpful, etc. And I've honestly been enjoying it and having a lot of fun with it. I've been enjoying the process of writing; of researching; of learning new things; and of course most of all - sharing my knowledge and experiences with others.

And in that time, I saw my visibility in Google's SERPs slowly increase. I saw my articles start to rank for various keywords, and I saw my traffic slowly increase.

Now I'm talking really embarrassingly low numbers here... like 10-20 visitors a day, which is pathetic even for a blog. But hey, it was something, and that was enough for me.

The Google HCU Massacre

But then late last year, I think maybe in October or November, I started hearing whispers on Reddit about a Google "HCU" causing some sites to lose 75% to 90% of their traffic. I didn't think much of it at the time, as I was still seeing my traffic slowly increase... until March of this year, when I lost all of my traffic from Google overnight. Instead of 1000+ page impressions a day, I started getting 1-10, and instead of 10-20 visits a day, Google is now bringing me a big fat 0.

"If Your Site Was Affected, You're a Spammer!"

As I've been browsing the subs on Reddit where I've seen this come up, I've seen a number of users commenting things to the effect of "Good, the less spam affiliate garbage the better!", "Your site/content was probably shit", "Try writing actual decent, quality content for a change and maybe you'll rank! 🙄", etc. Basically lumping all sites with massacred traffic into one category: SPAM.

Now, I don't know much about SEO ... I had to look up what the heck a "SERP" was (Search Engine Results Page), forget every time what E-E-A-T (Experience, Expertise, Authoritativeness, and Trustworthiness) is supposed to mean literally 2 seconds after looking it up, don't know what short-tail or long-tail keywords are (and frankly don't really give a shit!), and don't use tools to determine my DA (domain authority), which I know is low.

Why? Because I just want to write (hopefully decent and helpful) content, and hope it occasionally helps others.

But Who Has Actually Been Affected?

Well, according a number of redditors, only affiliate-pushing spam sites, or sites with really bad content have been hit by this recent Google search update.

But as other posters on Reddit have been noting, this HCU has actually been killing traffic to some of the bigger sites and players as well, ones with legit helpful content, and instead favouring the really big players like Reddit, Facebook, Quora (really?), and oddly, the news sites with those invasive, pop-up, non-stop adverts every paragraph or so.

Is This the End for Small Sites?

As I've been reading the doom and gloom comments on Reddit about how only bad, poorly written or spammy content has been hit, I've tried to reflect on my own site...

I do have some pretty poorly written content, which I wrote when I first started my blog, and which I've been meaning to go back and fix up.

And I do have affiliate links in each of my posts - but only static ones, and only 1 or 2 per post.

And I suppose my site isn't the nicest looking in the internet world, and has missing features I haven't found the time to add. But surely it's not that bad, is it?

Maybe it is, maybe it isn't. I don't know. Maybe I'm guilty as charged, and deserve to be buried in the SERPs. But what I do know is that I share an opinion that others are starting to share as well: Google is no longer the search engine it once was.

Google isn't the Only Search Engine in Town

I actually mostly stopped using Google for search sometime last year, before all this HCU stuff started. But for me it was due to something I find extremely egregious: Google's never ending, maddening, "I'm not a robot" captchas.

I get the captchas because I'm almost always on a VPN, and I'm almost always using Firefox. I also have a bunch of privacy and security add-ons installed, which probably doesn't help.

But I'm pretty sure I'm not a robot (although I suppose that's debatable!), and I prefer not having to prove it to Google every 5 minutes or so. So I stopped using Google for search, and switched to using DuckDuckGo instead last year.

And this isn't even the first time I've been burned by Google's decisions. If you're familiar at all with the Google Graveyard, you'll know that Google has a long history of killing off products and services that people have come to rely on. This has happened to me a number of times, in both a personal and professional capacity, and frankly it's getting old.

Where to Go From Here

So where do I go from here?

I'm not entirely sure. I'm not going to stop writing, which I only do when time permits anyway. I'm just going to do like I was when I started my blog, and before I started trying to "SEO" it: write when I can, and hope that what I write is helpful to someone.

Have you been affected by the latest HCU? Are you seeing massive drops/increases in traffic? Are you considering moving away from Google in general?

Let me know in the comments below!

How to Redirect URLs with Netlify

Michael La Posta — Sat, 09 Mar 2024 15:30:00 +0000

In light of a recent post I made about Netlify, I hesitated about whether or not to make this post. In the end, I figured it might still be useful to someone out there, and so I'm posting it after all. Hopefully someone finds it helpful...

In a recent post, I outlined 5 different ways you can redirect URLs in Next.JS.

What I didn't mention in that post, was that most of those methods don't work with my particular setup. It seems that my package manager setup causes a bunch of issues with Netlify, which is where the site I use the redirects with is hosted.

Sigh.

So, after attempting several ways to get the redirects working in Next.js, and failing, I had to find another way.

Thankfully, Netlify has two built-in methods for URL redirection, and they're super simple to use.

Method 1: Using the `_redirects` file

The first, and easiest method, is to use a _redirects file. This is a simple text file that you can create in the root of your site, which contains a list of one-line URL redirects, in a TSV-like format.

Now, I say root of your site, because I'm talking about the root of your website, and not the root of your project folder. So depending on your particular setup, this will likely differ.

According to Netlify, this is your "Publish" directory in your site's settings, however for me that wasn't the case.

The "Publish" directory in my Netlify settings:

I'm using Next.js, and what ends up being the root published directory for my static files is actually the /public/ folder in my project source. So, I had to create the _redirects file in the public folder instead. Again, this may differ for you, so you may need to experiment a bit to find the correct location for your _redirects file.

Basic Syntax

The basic syntax is pretty straight forward:

/old-page-1  /new-page-1
/old-page-2  /new-page-2
/old-page-3  https://www.example.com

Each line contains the old URL, followed by a space or tab (or multiple spaces or tabs), and then the new URL, which can be a local or external redirect. Easy peasy!

Wildcards and Placeholders

You can also use wildcards, which is super handy for redirecting entire paths to a single new page, or for capturing parts of the old URL and appending them to the new URL:

/old-directory-1/* /new-page
/old-directory-2/* /new-directory/:splat

On the 1st line above, we want to redirect any pages within old-directory-1 to a single new page - perhaps a custom 404 page, or a new landing page.

On the 2nd line, we're using the :splat keyword, which is a special variable that captures the rest of the URL after the wildcard in the old URL, and appends it to the new URL.

Note: If you use the asterisk * wildcard, it must appear at the end of the old URL after the final '/', and so of course the :splat must also appear at the end of the new URL after the final '/'.

Rules are matched in order, so if you have a more specific rule that comes after a more general rule, the specific rule will be ignored. For example, in:

/old-directory-1/*              /new-directory/:splat
/old-directory-1/specific-page  /new-specific-page

... because we placed the general rule above the specific rule, the specific rule will never be matched. So, if you have a specific rule, make sure it comes before any general rules that might match it.

If on the other hand you wanted to capture and keep a particular segment of the URL, you could use placeholder variables instead:

/some-folder/:month/*  /some-other-folder/:month/another-folder/:splat

In the above example, we're capturing the :month placeholder from the old URL, and copying it to the new URL. So we're able to change the directories in the URL, while carrying over the month segment.

HTTP Status Codes

Now in the above examples, we included only the old and new URLs, but we might also want to specify the HTTP status of the redirect. The HTTP status code is optional, and if not specified, Netlify will simply default to a 301 (permanent) redirect.

# Permanent redirect
/old-page-1   /new-page-1            301

# Temporary redirect
/old-url-1/*  /new-url-1/:splat      302

# URL rewrite
/visible-url  /actual-url/page.html  200

# Not found
/old-url-2    /custom-error-page     404

In the above example, for the first 2 redirects, we're just adding in the HTTP status code. In these 2 cases, the URL displayed in the browser address bar will change to that of the new URL.

For the 3rd redirect, we're using a 200 status code, which is actually a URL rewrite, not a redirect. And finally, for the 4th redirect, we're using a 404 status code, which will show a custom error page.

In the case of both the 200 and 404 status codes, the URL in the address bar of the browser will not change, only the content of the page will.

Note: If you want to add comments to the _redirects file, you can do so by prefixing the line with a # character, just like in a bash script.

Other Options

Netlify's _redirects file also supports a few other options, such as:

an '!' after the status code to force a redirect, even if a path exists at the old URL
query parameters (ex: ?src=xx or ?src=xx&id=yy)
redirects by country or language
redirects based on cookies present in the request headers

And if you are utilizing Netlify's auth systems, you can also redirect based on the user's authenticated role.

Method 2: Using the `netlify.toml` file

The second method for URL redirection with Netlify is to use a netlify.toml file. This is a configuration file that you can use to specify a bunch of settings for your site, including redirects. So if you're already using the netlify.toml file, you can add your redirects to this file instead of using the specific _redirects file.

With the netlify.toml file, instead of having each redirect on it's own line, you'll add each redirect under it's own section, like so:

[[redirects]]
  from = "/old-page-1"
  to = "/new-page-1"
  status = 301

[[redirects]]
  from = "/old-url-2/*"
  to = "/new-url-2/:splat"
  status = 302

[[redirects]]
  from = "/old-url-3"
  to = "/custom-error-page"
  status = 404

Note that like with the _redirects file, rules in the netlify.toml file are matched in order. So if you have a more specific rule that comes after a more general rule, the specific rule will be ignored.

Also note that while the netlify.toml file allows for the same options as using the _redirects file, albeit with a different syntax, it also allows for setting redirect headers, which you can't do with the _redirects file.

For full details on what redirect options Netlify supports, both in the _redirects file as well as the netlify.toml file, refer to their official documentation on Redirects and Rewrites, which gives many more details than I've covered here.

Final Thoughts

I've been using a _redirects file for a while now, and it not only works amazing well, but it's basically instantaneous. However, I'd suggest that if you are using a framework with its own redirect system, then you may want to use that as a 1st option. By keeping your redirects as part of your codebase, you're not locked in to specific vendor, like Netlify.

On the other hand, if you've found yourself in a situation like I did, where the built-in redirect system of your framework doesn't work with your hosting provider and specific setup, then Netlify's built-in redirect system is a great alternative. Heck, even a lifesaver! 😜

Is Hosting on Netlify Going to Bankrupt you?

Michael La Posta — Wed, 28 Feb 2024 15:00:00 +0000

On Tuesday, February 27, I was casually browsing Reddit, as I often do, when I stumbled on a slightly alarming post in the r/webdev subreddit. The post was titled "Netlify just sent me a $104K bill for a simple static site".

You can read the full post here on Reddit for the OP's story if you didn't catch it, but in short, OP's essentially unknown site got hit by a sudden onslaught of DDoS traffic, racking them up a cool $104,000 bill from Netlify!

Now according to Netlify, normally, they can detect and mitigate DDoS attacks, and the OP's case was simply an anomaly. But instead of immediately waiving the bill, they very nonchalantly suggested they'd only charge him 5% of the bill - only $5,200 - basically a steal right?? 🙄

That is, until some commenters on Reddit suggested OP post the story to Hacker News, which OP did, and then Netlify suddenly changed their tune.

After the story went viral, the CEO commented on the same Hacker News thread that the fees would be waived, and apologized that the support team didn't handle the situation better.

But a lot of damage had already been done, and many Redditors felt that Netlify's response was too little, too late. They commented that they'd lost their trust in the company, and that they had already started migrating their sites away from Netlify, and would never use them again. Others who were considering using Netlify in the future, said they'd now be looking elsewhere.

I've been a Netlify user for a few years now, and while I can't say I find their service perfect as it's missing some pretty crucial support for some things I use, it's still been a pretty good experience overall. And for someone like me (and like the OP), with just a small-time relatively unknown site generating very little traffic every month (basically nothing), their free tier has been a godsend. Or well, at least I thought it was, until I read this story.

The Concern

Ok, so what's the actual reason, assuming you didn't venture off to read OP's story, that a free-tier site was able to rack up a massive bill in a very short amount of time?

Well, I already mentioned it was related to a sudden onslaught of DDoS traffic, but the real concern here is that Netlify doesn't shut down your site when the traffic surges.

In fact, not only do they not shut down the traffic to your site, but apparently OP only received a single email from Netlify about "Extra usage package purchased"! And that was it. No warning, no nothing.

Netlify apparently has agreements in place with paid tiers, but free tiers offer no such provisions. So, if you're on the free tier, and you get hit by a DDoS attack, you're basically screwed. But don't worry, they'll give you a good discount!

Some commenters on Reddit even noted - with such a policy in place - it's almost like Netlify is encouraging DDoS attacks on free-tier sites, as they'd be the only ones who'd benefit from it.

The Aftermath

As I noted at the beginning of this post, many Redditors have already started migrating their sites away from Netlify. But to say Netlify is alone with this policy would be inaccurate.

It seems that a number of other popular hosts with free tiers also don't offer a kill-switch for traffic surges, so moving over to another host may not necessarily solve the problem.

Reading the fine print has yet again shown to be crucial, and I'm just as guilty as the others for not doing so!

After some more backlash, Netlify's CEO posted a follow-up comment on the same Hacker News thread, stating that they'd be reviewing their policies and making changes to ensure that this kind of situation doesn't happen again.

Now while that's a bit of a relief, I wonder how long it'll take for them to actually implement these changes, and if they'll be enough to win back the trust of those who've already left.

Final Thoughts

I'm not entirely sure if it's enough for me, but I guess only time will tell. As it stands, I'm still considering my options.

I'm not sure if I'll be moving my sites away from Netlify just yet, but I'm definitely going to be keeping a closer eye on my traffic and usage from now on.

I've also learned that I need to be more vigilant with the fine print of the services I use, and I hope you've learned the same from this post.

What are your thoughts on this? Are people freaking out too much over this? Have you been affected by a similar situation with Netlify or another host?

Let me know in the comments below.

Fix Path Name Mismatches in Local & Remote Git Repos

Michael La Posta — Thu, 22 Feb 2024 14:30:00 +0000

If you've ever written any computer code, you've undoubtedly (inadvertently) introduced bugs in your code. I mean, are you even a developer if you haven't? 😂
Hell, even ChatGPT makes bugs in it's code suggestions, and it's an AI with access to the best code out there!

But how about when something isn't working as it should on your site, but all of your code checks out fine? 🤔

Hence ...

The Problem

Originally, for no reason in particular, I was naming all of my blog post filenames using Pascal case. Or in other words, the first letter of each word was capitalized.

For example, Fix-File-And-Folder-Name-Mismatches-Between-Remote-And-Local-Git-Repo or something along those lines.

I later realized that this was causing redirects on the live server to lowercase URLs, and sometimes (though oddly not always) resulting in 404 errors. Even when there weren't any obvious, visible issues, I was still getting warnings on some analytics tools and search consoles.

I left things as is initially, but decided a while later that it would probably be safer to just convert everything, file and folder names, to all lowercase.

Initial (Faulty) Git Update

I did this by renaming the files and folders in bash the manual way ... one by one (not very smart I'll admit), and then committing the changes to Git.

I double-checked all of the files in my local repo, and ran a test build, and everything was looking good. I also checked the live site after committing and pushing the changes to my remote repo, and rebuilding the site. No issues that I could see there, so I thought I was in the clear, but I didn't notice one of the posts was still showing up with the old Pascal-case filename.

So after scratching my head for a while and thinking I was going mad, I added the .toLowerCase() method to some of the code to make sure it forced everything to lower case. Somehow though, that post in particular was still showing up with the old Pascal case filenames!

I was super confused, and I couldn't figure out how this was happening until finally, recently, I checked my remote Git repo and realized one of the paths was not synched up properly with my local repo!

Apparently, the old folder name had remained cached in Git, despite me committing and pushing the changes to my remote repo. So I had to figure out how to fix this, but hey, at least I'd finally found the problem! 🥴

First Attempt to Search for a Solution

At first I tried, unsuccessfully, to re-rename the folder using git ... as in, rename it back to Pascal-case and then back to all lowercase. But nope, Git was having none of that.

So I did some Googling, but was mostly finding posts about how to easily convert the local filenames to a different case, but not how to fix the issue of the remote repo not matching the local repo.

I did find much smarter ways to convert the filenames to lowercase though, so that was a plus... albeit too late for me since my filenames were already converted. Hah! 😅

I also found some posts about how to fix the issue of Git not recognizing case changes, but that wasn't my issue. I had already committed and pushed the changes to my remote repo, and the changes were showing up in my local repo. My issue was with the remote repo not being synchronized with the local repo.

Second Attempt to Search for a Solution

I thought "Hey, I've got a whole post for some of the most common git commands that I wrote a while back, so I'll just skim over it and see if I already wrote about the issue and just forgot!"

But alas, I definitely did not include anything about fixing this particular issue in the cheat sheet. 😕
And it makes sense I guess, since I'd never run into this issue before, and I'd never even heard of it before.

The Actual Working Solution

Eventually though, I found this StackOverflow post that had a reply from @andrewvergel with a super simple way to fix the issue:

From bash, run the following commands:

git rm -r --cached .
git add --all .

Note: Don't forget the "." at the end of the commands!

After running the above two git commands, you should review the changes to make sure everything looks good before committing and pushing the changes to your remote repo.

It's likely some other files will be added to the index, so you'll want to make sure those are files you want to add. In my case, I did in fact have a bunch of files added that I didn't want to commit, so I had to unstage them.

To unstage a file, simply run the following command:
git restore --staged <file>

Then, once you're sure only the necessary files are added, do your normal commit, and push the changes.

git commit -a -m "Fixing file name casing"
git push origin <branch>

Explanation

"git rm -r --cached ."

Per the Git docs, the --cached flag in the git rm command will remove the files from it's internal index, but not from the working tree.

"git add --all ."

The --all flag in the git add command will add, modify, and remove index entries to match the working tree.

If that's not super clear though, perhaps @Uriahs Victor's response in the same post is a bit easier to understand:

What this command actually does is deletes the cached version of the file/folder names that git thought still existed. So it will clear its cache but leave everything in the current folder (where you've made your changes locally) but it will see that those other wrong case folders/files do not exist anymore so will show them as deleted in git status. Then you can push up to GitHub and it will remove the folders/files with wrong cases.

And that's basically it!

So to recap, if you notice any weird file-case issues on your live site that aren't appearing in your dev environment, or vice versa, you can run the following commands from bash to sync your local and remote repos:

git rm -r --cached .
git add --all .
git commit -a -m "Fixing file name casing"
git push origin <branch>

Running the above git commands should flush out any cached mismatches and fix your issue.

Hope that helps someone else out there!

Limit the Number of Pre-rendered Pages in Next.js

Michael La Posta — Wed, 14 Feb 2024 14:30:00 +0000

They say that history repeats itself, and it really does ring true for so many things in our lives.

A little bit of Back in the Day ...

Back when the "World Wide Web" first started getting popular, websites were static through and through, because reactive and dynamic web tech hadn't been invented yet.

Enter the dynamic web ...

Then came the dynamic web, and with it, the ability to build sites that were reactive and interactive.

Initially this was done with server-side environments/languages like Java, PHP, ASP, JSP, etc. combined with JavaScript on the client-side, but eventually client-side JavaScript libraries like jQuery started to appear. There was even Flash ... remember that? 😂

But it wasn't really until frameworks like Angular, and libraries like React and Vue came along, that the pendulum swung the other way, and static sites were now seen as old and outdated.

This was a huge leap forward, and it was amazing to see what could be done with this new technology.

The new hotness was to build your site as a single-page application (SPA), and let the client-side JavaScript handle all the rendering. This was an amazing way of doing things, but the issue with this approach is that it's not very SEO friendly, and for very large sites, the initial load time can be quite long.

Hello meta-frameworks ...

More recently, with the advent of meta-frameworks like Next.js, Remix.js, Astro, et al., and the ability to pre-render your site at build time, static sites are back on the menu once again.

But there can be issues with this approach as well, especially for very large sites: pre-rendering your entire site at build time can be very costly, both in terms of build time, as well as the actual dollar cost of running the build.

The Problem

I stumbled on a reddit thread (or maybe it was a Stackoverflow question?) the other day, where someone was asking about migrating a site with over 250,000 pages to Next.js. I think it was an e-comm site or something, but I can't seem to find the thread again. Anyway, the gist of the question was that they were concerned about the build time and cost of pre-rendering all those pages.

Now I have no idea how long it would take to pre-render 250,000+ pages, but I can promise you it wouldn't be quick. If I could make a rough estimate, I'd wager you'd be looking at about 2 hours or so, give or take.

Now that's bad enough, but the real issue is that you'd have to do that every time you update the site. And if you're running a business, you're going to want to update your site fairly regularly, so that's a lot of time and money spent (wasted) on builds.

In an ideal world...

Ideally, you'd be able to do the initial pre-rendering of all your pages in Next.js on your very first build, and then only re-build the pages that have changed since the last build on subsequent builds. This would save a ton of time and money, and would be a much more efficient way of doing things.

I searched online to see if Next.js had this ability, but couldn't find anything. Part of the issue is that with cloud hosts like Vercel and Netlify, your code is pulled fresh from your repo every time you build, so there's no way to know which pages have changed since the last build.

I did see ISR (Incremental Static Regeneration) mentioned a few times, but that's not really what I was looking for. ISR is great for pages that are updated frequently, but it doesn't help with the initial build time.

So what's a Next.js dev to do?

The Solution (well ... sort of)

Unfortunately I don't have a solution for only re-rendering pages that have changed since the last build, but there is a way to limit the number of pages that are pre-rendered at build time.

So while limiting the number of pre-built pages isn't perfect, it's still a good compromise, and might save you time and money in the long run.

The Gist

The gist of this solution is to only spit out the pages that you want pre-rendered in the getStaticPaths function of your page. This is the function that tells Next.js which pages to pre-render at build time.

You could base it on which of your pages are the most popular, or which ones are the most likely to be visited, or you could just pick a random selection of pages. Alternatively, if you're dealing with a blog for example, you could just pre-render the 50-100 most recent posts, the rest of which would get rendered automatically at runtime.

The Code

The following is an (incomplete) example of how you could achieve this:

// pages/[slug].js

import { getAllPosts, getPostBySlug } from '../../lib/api';

export default function Post({ post }) {
  return (
    <div>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </div>
  );
}

export async function getStaticPaths() {
  const posts = getAllPosts();

  // Sort posts by published date, descending
  let sortedPosts = posts.sort((post1, post2) =>
    post1.published > post2.published ? -1 : 1
  );

  // Limit the number of pre-rendered pages to 50
  const paths = sortedPosts.slice(0, 50).map((post) => ({
    params: { slug: post.slug },
  }));

  return {
    paths,
    fallback: 'blocking',
  };
}

export async function getStaticProps({ params }) {
  const post = getPostBySlug(params.slug);

  // Check to make sure the page exists, and return a 404 if it doesn't
  if (post.slug === null) {
    return {
      notFound: true,
    };
  }

  return {
    props: {
      post: {
        ...post,
        content: post.content || '',
      },
    },
  };
}

Now, I've made some assumptions here, namely that you have a lib/api TS or JS file that contains functions for getting all your posts, and getting a single post by slug. I've also assumed that your posts have a published date, and a slug property.

In my own code, I do the sorting by date in the getAllPosts() function, but I included it here in getStaticPaths() for clarity.

Key Points

In this example, we're using the slice() method to limit the number of pages that are pre-rendered to 50. You could also use filter() to only pre-render pages that meet certain criteria, or any other array-manipulation method you like.

In my own code, like with the sorting, I actually slice the array in the getAllPosts() function, but included it here in getStaticPaths() once again for clarity.
The fallback: 'blocking' key in the return object in getStaticPaths(). This tells Next.js to render any pages that weren't pre-rendered at build time at runtime instead, since they haven't yet been rendered.

Alternatively, you could set fallback to true, which will also render the extra pages at runtime, but will show a fallback page while the page is being rendered, whereas setting it to 'blocking' will block loading until the page is rendered, similar to SSR.

I'm using 'blocking' here, because I don't want to show a fallback page, and I don't want to show a loading indicator either. I'd rather just have the page load instantly, even if it takes a few seconds to render, but that's just my preference.
The notFound: true key in the return object in getStaticProps(). This tells Next.js to return a 404 page if the page doesn't exist. When fallback is set to false, Next.js knows to issue a 404 for any pages that aren't in the paths array, but when fallback is set to true or 'blocking', it doesn't know which paths/files exist or not, so you have to explicitly tell it.

The Result

So what does this look like in practice?

Well, if you visit a page that's in the paths array, because it was pre-rendered at build time, you'll see the page load instantly.

On the other hand, if you visit a page that isn't in the paths array, it will be rendered at runtime, and you might see a loading indicator (or a fallback page if you set fallback: true) while the page is being rendered, depending on the size of the page and the speed of your connection.

Note: The rendering of non-pre-rendered pages will only happen once, after which the page will be cached for future visits. So it's not like you'll be waiting for the page to render every time you visit it.

Conclusion

So there you have it. While this solution isn't perfect, it's a good compromise, and might save you time and money in the long run.

Know of a way in Next.js to only re-render pages that have changed since the last build? Please, let me know in the comments!! I'd love to hear about it. 😁

Understanding PostgreSQL RLS, and When to Use it

Michael La Posta — Mon, 05 Feb 2024 16:20:28 +0000

Somewhere around 3rd or 4th quarter 2023, I was starting to look into the requirements of a project I needed to start in the new year. I was trying to decide on which stack I wanted to use, including the database, which of course is a major part of the stack.

Now typically in the past I've used either MySQL or MS SQL Server, as that was either what was available to me, or what I was most familiar with. I was really leaning towards a cloud-based solution this time round though, and I'd been hearing so much buzz about Supabase, that I wanted to see if it made sense for me to use in my project.

One of the main things I saw talked about, one of Supabase's main selling points, was that its underlying DB is PostgreSQL, which allows restricting access via RLS, or Row Level Security.

But what exactly is RLS? And why is it so desirable?

What is PostgreSQL Row-Level Security?

Row-Level Security (RLS) in a database is a feature that allows you to restrict access to individual rows in a database table based on user-defined policies.

These policies are defined at the table level like standard table accesses, but they allow you to restrict which rows a user can access based on specific conditions. RLS applies to all queries that access the table, including SELECT, INSERT, UPDATE, and DELETE statements.

For my purposes, I'd be linking the access control via an authenticated user's ID or role, but you could use other conditions as well, like IP address, or even the time of day.

Why is PostgreSQL Row-Level Security such a big deal?

RLS is important because it allows you to restrict access to rows in a database table based on access policies. This adds an additional layer of security to your database by allowing you to implement access control at the granularity of individual rows rather than just at the table-level.

Some RLS Examples

Full details of PostgreSQL's RLS policies can be found here, but the basic format for creating a policy is as follows:

CREATE POLICY <policy_name>
  ON <table_name>
  FOR <action>
  [USING (<expression>)]
  [WITH CHECK (<expression>)];

Example 1: Bypassing RLS on a table when RLS is enabled

I've included this here just for the sake of demonstrating how the using clause works. In reality, you wouldn't enable RLS on a table in the first place if you were going to bypass it, but just to give you an idea of what the syntax would look like, here's an example:

CREATE POLICY bypass_rls_policy
  ON some_table
  FOR ALL
  USING (true);

So the USING clause essentially just needs to return a boolean value, and if it returns true, then access is granted.

But ok, that's a mostly pointless example, I just wanted to throw it in in case it helps to clarify the syntax.

Example 2: Restricting access to a table based on user ID

Suppose you have a table named tasks in your database, and you want to implement a security policy that allows users to access only their assigned tasks. You could do this by creating a policy that restricts access to rows in the tasks table based on the user's ID:

CREATE POLICY task_assignment_policy
  ON tasks
  FOR ALL
  USING (assigned_to = current_user_id());

This policy would allow users to access only their assigned tasks, and would prevent them from accessing tasks assigned to other users.

Note: In the above example, assigned_to would be a column in the tasks table, and current_user_id() would be a function you define that returns the ID of the currently logged-in user, which means it would of course need to be tied to the user's session.

Example 3: Restricting access to a table based on logged in status

Suppose you have an e-learning site, with course content in the course_content table. You have it setup so that anonymous (non-logged in) users can view the course selection (in a separate table), but they can't view the actual course content. You could do this by creating a policy that restricts access to rows in the courses table based on the user's logged-in status, for example:

CREATE POLICY course_visibility_policy
  ON courses
  FOR SELECT
  USING (is_logged_in());

So in this simple example, no comparison is being made. We're just checking to see if the user is logged in or not. If they are, then they can access the course content. If they're not logged in, then they can't. Super simple!

Note: In the above example, is_logged_in() would be a function you define that returns true if the user is logged in, and false if they are not.

When should you use PostgreSQL Row-Level Security?

This question is the main one I was asking myself when I was looking into Supabase. I mean, I understood the idea behind row-level security, but I couldn't figure out why I would actually need to use it.

This is because in the app I was going to be building, there would be a backend REST API responsible for handling all the security and data access. So while RLS could be used to restrict access to data in the database, the actual restrictions were going to be in the REST API.

It was then that it finally clicked for me, I think thanks to some reddit thread, that RLS is useful, a necessity really, when you're building a frontend-only app (no backend) that accesses the database directly. In that case, you don't have the option of implementing access restrictions in a backend API, so you need to do it via the database directly. And that's where RLS comes in and can be super powerful! 💡😄

Now of course there are other use cases for RLS, but this is the one that finally made it click for me, and made me realize why it's such a big deal.

In a nutshell

So basically, if you're building a frontend-only app, and you're using PostgreSQL as your database (whether through Supabase or not), then you should definitely be using RLS to restrict access to your data.

On the other hand, if you're building a full-stack app and have a backend of some sort, you can still use RLS, but it's not as big of a deal, and you can probably just implement the same restrictions in your backend API.

That's it for this post!

If you were as confused with the purpose of PostgreSQL row-level security as I initially was, I hope it helped to clarify things for you, and why you might want to implement it in your own app.

Build a Weather Widget Using Next.js

Michael La Posta — Sat, 27 Jan 2024 14:30:00 +0000

In this Next.js tutorial, we'll learn how to create a simple weather widget using Next.js, React, and OpenWeatherMap.

I'll be keeping things simple, so styling will be done using plain old CSS, and the weather API calls will use the built-in fetch API.

Note: You can download the final code for this tutorial from my GitHub repo.

Why use Next.js?

This widget is easily doable using basic React, and for the most part, the code will be just basic React. However, we'll need a way to allow backend-only access to our OpenWeatherMap API key (for security purposes) and make the API calls, and Next.js provides us with an integrated way to do this by utilizing the pages/api folder.

Of course, alternatively, if you were using Node.js or another backend (Java, PHP, Python, Ruby, etc.), you would just place all of your API calls there instead of using the backend we'll be creating. That however is outside the scope of this tutorial, and so we'll be sticking with a full Next JS build for this one.

Alright, let's get started!

Bootstrap the Project (optional)

If you're using an existing project, then you've already bootstrapped your project, and can skip ahead to the Setup your OpenWeatherMap API Key section below.

Otherwise, the first step will be to set up the project boilerplate.

1. Create the Project

From the CLI, using yarn, run the following command:

yarn create next-app weather-widget --example with-typescript

Or, if you're using npx, you can use the following:

npx create-next-app weather-widget --example with-typescript

Then, when prompted, use the following settings:

✔ Would you like to use TypeScript? … [Yes]
✔ Would you like to use ESLint? … [Yes]
✔ Would you like to use Tailwind CSS? … [No]
✔ Would you like to use `src/` directory? … [No]
✔ Would you like to use App Router? (recommended) … [No]
✔ Would you like to customize the default import alias (@/*)? … [No]

Note: If you're using Yarn's PnP (no node_modules folder) along with VS Code as your IDE and are seeing "Cannot find module ..." errors in your TS files after the install, see my post here on how to fix those errors.

2. Delete Unnecessary Files

Delete the following files (but not the folders):

public/*
styles/*
pages/api/*
README.md

3. Delete Unnecessary Code

In pages/_app.tsx, delete the following import:

// pages/_app.tsx

import '../styles/globals.css';

Setup your OpenWeatherMap API Key

OpenWeatherMap offers a free API tier, which allows for up to 60 calls per minute, and max 1,000,000 calls per month. So we've got plenty for the purposes of this tutorial.

To get your free key, go to openweathermap.org and create an account.

Once you've created your account:

Go to the API Keys page and copy your API key.
Create a new file in your weather widget project root folder called .env.local and add the following code, replacing [YOUR_API_KEY_HERE] with the API key you obtained from OpenWeatherMap:

   # .env.local

   OPENWEATHERMAP_API_KEY=[YOUR_API_KEY_HERE]

Create the Weather Data API

The weather API is where we need Next.js to come in and help us out.

We'll be creating a basic API that will allow us to make calls to OpenWeatherMap from the frontend, without exposing our API key, by routing those calls through our backend (.js or .ts files in the pages/api folder).

In the pages/api folder, create a file called weather.ts, and add the following code:

// pages/api/weather.ts

// import the Next.js request and response types
import { NextApiRequest, NextApiResponse } from 'next';

// import the OpenWeatherMap API key from the .env.local file
const apiKey = process.env.OPENWEATHERMAP_API_KEY;
const apiUrl = 'https://api.openweathermap.org/data/2.5/weather';

export default async (req: NextApiRequest, res: NextApiResponse) => {
  // extract the query parameters from the request object
  const { q, lat, lon } = req.query;

  // if the API key isn't found in the .env.local file,
  // return a 500 error to the frontend
  if (!apiKey) {
    res.status(500).json({ error: 'API key not found.' });
    return;
  }

  // if either the city name (q), or coordinates (lat and lon) aren't
  // provided, return a 400 error to the frontend
  if (!q && (!lat || !lon)) {
    res.status(400).json({ error: 'Please provide either city or coordinates.' });
    return;
  }

  // because this is running server-side, we're wrapping the API call
  // in a try / catch block to catch any errors that may occur,
  // and if so, return a 500 error to the frontend
  try {
    const query = q ? `q=${q}` : `lat=${lat}&lon=${lon}`;
    const response = await fetch(`${apiUrl}?${query}&appid=${apiKey}&units=metric`);
    const data = await response.json();

    res.status(200).json(data);
  } catch (error: unknown) {
    if (error instanceof Error) {
      res.status(500).json({ error: error.message });
    } else {
      res
        .status(500)
        .json({
          error: error || 'Server error while trying to fetch weather data',
        });
    }
  }
};

Just like Node.js, Next.js gives us access to the process.env object, which allows us to access environment variables, like our OPENWEATHERMAP_API_KEY constant.

After a few basic checks (check that the query parameter was passed with either city name q or coords lat and lon), we then use the fetch function to make the API call to OpenWeatherMap, and return the data to the frontend via the response method.

If the call was successful, we return the data to the frontend with an HTTP 200 status code, otherwise we return an error message with the generic HTTP server error code 500.

Define the Widget Styling

Next up, we'll define the styling for our widget.

In a project this small, we could just use a regular CSS file, which would make the CSS classes global.

I want to scope the CSS to the widget only though, which will avoid possible naming conflicts with other CSS files that could occur in larger projects.

So in the styles folder, create a CSS module file called weather.module.css, and add the following CSS:

/* styles/weather.module.css */

.weatherWidget {
  border: 1px solid #ccc;
  border-radius: 10px;
  max-width: 200px;
  padding: 20px;
  margin: 10px;
  text-align: center;
  background-color: #ccc;
}

.currentWeather {
  margin: 0 auto;
  display: flex;
  flex-direction: row;
  flex-wrap: nowrap;
  justify-content: center;
  align-items: center;
}
.currentWeather div {
  display: inline-block;
  font-size: 2.5rem;
}

.feelsLike {
  font-size: 0.9rem;
  font-style: italic;
}

.weather {
  font-weight: bold;
}

Create the Weather Widget Component

Now it's time to create the actual widget component.

In your project root folder, create a new folder called components, and then inside that folder, either using bash or your code editor, create a file called weatherWidget.tsx.

In weatherWidget.tsx, add the following code:

// components/weatherWidget.tsx

import React, { useState, useEffect } from 'react';

import styles from '../styles/widget.module.css';

interface WeatherWidgetProps {
  city?: string;
  coordinates?: { lat: number; lon: number };
}

interface WeatherData {
  name: string;
  main: {
    temp: number;
    feels_like: number;
  };
  weather: {
    description: "string;"
    icon: string;
  }[];
}

const WeatherWidget: React.FC<WeatherWidgetProps> = ({ city, coordinates }) => {
  const [weatherData, setWeatherData] = useState<WeatherData | null>(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        let query = '';

        if (city) {
          query = `q=${city}`;
        } else if (coordinates) {
          query = `lat=${coordinates.lat}&lon=${coordinates.lon}`;
        } else {
          console.error('Please provide either city or coordinates.');
          return;
        }

        const response = await fetch(`/api/weather?${query}`);
        const data: WeatherData = await response.json();

        setWeatherData(data);
      } catch (error) {
        console.error('Error fetching weather data:', error);
      }
    };

    fetchData();
  }, [city, coordinates]);

  return (
    <div className={styles.weatherWidget}>
      {!weatherData ? (
        <div>Loading weather ...</div>
      ) : (
        <>
          <h2>{weatherData.name}</h2>

          <p className={styles.weather}>{weatherData.weather[0].description}</p>

          <div className={styles.currentWeather}>
            <img
              src={`https://openweathermap.org/img/wn/${weatherData.weather[0].icon}@2x.png`}
              alt={weatherData.weather[0].description}
            />
            <div>{Math.round(weatherData.main.temp)}°C</div>
          </div>

          <p className={styles.feelsLike}>
            Feels like: {Math.round(weatherData.main.feels_like)}°C
          </p>
        </>
      )}
    </div>
  );
};

export default WeatherWidget;

In the above code, we're using the useState and useEffect hooks to fetch the weather data from our API, and then display it in the widget.

We're using useEffect so that the API call can be made if / when the city or coordinates props change. So if this was in an app with a select box of cities, the widget would update automatically when the user selects a new city.

Note: I've left out proper error handling for the weather API call, opting to just log the error to the console for the sake of this tutorial.

In a real app, you'd want to handle any errors more gracefully, perhaps by displaying a message to the user, and probably by using a state variable to track the error, and then displaying the error message in the widget.

Update the Index Page

Finally, we'll update the index.tsx page to use our new widget.

Simply replace the contents of the original boilerplate in pages/index.tsx with the following code:

// pages/index.tsx

import React from 'react';
import WeatherWidget from '../components/weatherWidget';

const Home: React.FC = () => {
  return (
    <div className="App">
      {/* Example using city name */}
      <WeatherWidget city="Montreal" />

      {/* Example using coordinates */}
      {/* <WeatherWidget coordinates={{ lon: -73.5878, lat: 45.5088 }} /> */}
    </div>
  );
};

export default Home;

In the above code, I'm using "Montreal" as the city name, but you can of course replace that with any city name you want.

If you have trouble getting the weather for a particular city, you can comment out that line, and uncomment the second example which uses the coordinates for that city instead.

And that's it for the setup and tutorial!

The Final Result

Now, if you run yarn dev (or npm run dev), you should get something like the following widget showing in your browser:

Additional Thoughts

The OpenWeatherMap API is pretty robust, and there are other paid API endpoints that you can access, such as 4-day, 8-day, and 16-day forecasts, among other things.

Because I'm using the free version of the API in this post however, the access is limited to current weather and a 5-day forecast.

For further info on the free "current weather" API we're using in this tutorial, refer to the Current weather data API documentation for all the available data points.

5 Ways to Redirect URLs in Next.JS

Michael La Posta — Fri, 19 Jan 2024 14:30:00 +0000

Chances are at some point in the development of a web app or website, you've changed the path to a URL for whatever reason. Maybe you've changed the name of a page, or you've changed the structure of your site. Whatever the reason, you'll need to redirect the old URL to the new one.

In this post we'll explore 5 different methods you can use to redirect URLs in Next.JS, using Pages router, each with their own pros and cons.

Note that for the purposes of this post, I'm assuming permanent redirects. If you need temporary redirects, you can simply change the permanent property to false in the first 3 code examples below.

Method 1: Using next.config.js

The first method I'll outline is probably the simplest, and when it works, the fastest.

I say "when it works" because it's not necessarily supported by all hosts. For example, Vercel of course supports it, but Netlify doesn't currently appear to. As for other hosts, you'd need to verify with them, but I'd imagine it varies.

To use this method:

If you haven't already, create a next.config.js file in the root of your project (at the same level as your package.json file).
Add the following code to the file:

   // next.config.js
   module.exports = {
     async redirects() {
       return [
         {
           source: '/old-url-1',
           destination: '/new-url-1',
           permanent: true,
         },
         {
           source: '/old-url-2',
           destination: '/new-url-2',
           permanent: true,
         },
         etc...
       ]
     },
   }

That's it! Now, when a user visits /old-url-1, they'll be redirected to /new-url-1. The same goes for /old-url-2 and /new-url-2, etc.

Setting permanent to true will make the redirect permanent, and cause a 308 HTTP status code to be returned, which is what you want in most cases. If you need a temporary redirect, you can set permanent to false, which returns a 307 HTTP status code instead.

This method is super simple, and allows for a lot of options including dynamic path matching and even regex matching.

For full details, check out the official Next.JS redirects documentation.

Method 2: Using getStaticProps

Now, I'm including this purely because it's listed in the official Next.JS documentation, but it doesn't actually seem to work!!

Well, that's not entirely true ... it works amazingly well in development, but doesn't seem to work at all in production. And call me crazy, but isn't production exactly where you would need it to work? 🤔🤨

If you use the redirect key in getStaticProps in production, you'll likely get the following error during build time:

Error: 'redirect' can not be returned from getStaticProps during prerendering

According to user timfuhrmann in this github thread, this style of redirect only works if fallback is set to true or 'blocking', but I couldn't get it to work any way I tried. I guess I'm doing something wrong, but the docs make no mention of how to correctly do it, and I couldn't find any other info on it.

So, I'm not entirely sure what the purpose of having it is, and why it's listed in the official documentation. I'm including it here for completeness, and so that in the event you run into this error like I did, you understand it's because it doesn't seem to work in production.

If you know what I'm doing wrong, and what the docs obviously don't mention, please let me know in the comments and I'll be sure to update this post.

The code is as follows:

// pages/[slug].js | pages/[...slug].js
export async function getStaticProps({ params }) {
  let redirectUrl = '/';

  if (params.slug.includes('old-url-1')) {
    redirectUrl = '/new-url-1';
  } else if (params.slug.includes('old-url-2')) {
    redirectUrl = '/new-url-2';
  }

  return {
    redirect: {
      destination: redirectUrl,
      permanent: true,
    },
  }
}

export async function getStaticPaths() {
  return {
    paths: [
      { params: { slug: 'old-url-1' } }
    ],
    fallback: false,
  }
}

Note: if you're using dynamic paths, you'll likely need to export both getStaticProps and getStaticPaths, whereas for a direct path match, you'll only need getStaticProps

Now when a user visits /old-url-1, they'll be redirected to /new-url-1, but again, this only seems to work work in development.

Like Method 1 however, this method also allows for dynamic path matching and regex matching, so if you only need redirects in dev, this could be a solution. That said, I'd recommend using Method 1 instead, as it's much simpler and more reliable when supported by your host.

For more info on this method, you can check out the official Next.JS getStaticProps documentation.

Method 3: Using getServerSideProps

Unlike getStaticProps, getServerSideProps does work in production. So if you need redirects in production, this is a good option, albeit a slower one compared to Method 1.

This method uses server side rendering, so while it's not as fast as a static redirect, it's still being done server-side, which can be a plus.

You also don't need to worry about fallback or revalidate options, as they're not needed here.

The code is quite simple:

// pages/[slug].js | pages/[...slug].js
export async function getServerSideProps({ params }) {
  let redirectUrl = '/';

  if (params.slug.includes('old-url-1')) {
    redirectUrl = '/new-url-1';
  } else if (params.slug.includes('old-url-2')) {
    redirectUrl = '/new-url-2';
  }

  return {
    redirect: {
      destination: redirectUrl,
      permanent: true,
    },
  }
}

Again, this method also allows for dynamic path matching, which you would accomplish by using the params object, and by placing the code in a file with a dynamic route name, like [id].js, [slug].js or [...slug].js.

Method 4: Using a middleware.ts or .js file

This method is quite a bit more complicated, but it's also a lot more flexible. Using middleware, you can redirect to any other URL, including external URLs.

You can also use conditional logic, cookies, and you can set the response headers as well.

To use this method, you'll need to create a middleware.ts or middleware.js file in the root of your project (at the same level as your package.json file).

Add the following code to the file:

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(req: NextRequest) {
  if (req.nextUrl.pathname === '/old-url') {
    return NextResponse.redirect(new URL('/new-url', req.url))
  }
}

Or, alternatively, using path matching:

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(req: NextRequest) {
  return NextResponse.redirect(new URL('/new-url', req.url))
}

export const config = {
  matcher: '/old-url/:path*',
}

Note: In my test middleware.js file, VS Code is showing an error with the NextResponse import, but it's working fine. Seems to be something not updated as it wants me to keep the file in the pages directory, which is no longer required / supported.

An important caveat with this method though, per the Next.JS docs, is that it currently only supports the Edge runtime, and not the Node.js runtime.

Refer to the official Next.JS middleware documentation for the full list of features and options.

Method 5: Using useEffect

And finally, the last method I'll outline is using useEffect in a React component. This method is probably the most flexible, but it's also not really a true redirect.

This method would be somewhat similar to the old school method of using a meta refresh tag in the <head> of your HTML document, but instead of using a meta tag, we'll use React's useEffect along with Next's useRouter to redirect the user to the new URL.

Like the middleware method, we can redirect to an external URL, as well as use conditional logic, cookies, etc.

The code is as follows:

import { useEffect } from 'react';
import { useRouter } from 'next/router';

export default function OldPage() {
  const router = useRouter();

  useEffect(() => {
    router.push('/new-url');
  }, []);

  return (
    <div>
      <h1>Old Page</h1>
    </div>
  );
}

Well, those were the 5 different methods I wanted to outline in this post. Note that if you're using App Router instead of Pages Router, you might have different options / methods available to you.

Hope you learned something new in this post, and that it helped if you got stuck somewhere in your own code. 😀

Fix "Cannot find module ..." TypeScript errors in VS Code

Michael La Posta — Sat, 13 Jan 2024 15:00:00 +0000

As a developer, I'm all too familiar with things not working as planned, and bugs popping up anywhere and everywhere. I'm also all too familiar with the frustration that comes with it.

But finding / creating bugs while coding is just par for the course, so it's nothing new. It's just part of the job. And I've learned to accept it.

What really frustrates me though, is when I bootstrap a new project, and there are errors right from the get-go! 😡

The Project

Enter this new project I started. I'm using NextJS and Yarn 3, and I bootstrapped it using Next's create-next-app with Yarn, as such:

yarn create next-app

✔ Would you like to use TypeScript? … [Yes]
✔ Would you like to use ESLint? … [Yes]
✔ Would you like to use Tailwind CSS? … [Yes]
✔ Would you like to use `src/` directory? … [No]
✔ Would you like to use App Router? (recommended) … [No]
✔ Would you like to customize the default import alias (@/*)? … [No]

Pretty straight forward and simple no?

TypeScript ... check
ESLint ... check
Tailwind CSS ... check

Certainly, nothing really out of the ordinary here. That said, I am using Yarn 3 (Yarn Berry), which uses it's "Zero Installs" plug and play system, and means that there's no node_modules folder. As I've experienced before, the missing node_modules folder can cause issues sometimes.

The Problem

So I opened Visual Studio Code and checked out the tailwind.config.js file, and I was greeted with this succulent error:

Cannot find module 'tailwindcss' or its corresponding type declarations

I thought it seemed strange, because I selected Tailwind in the create-next-app options. Create-next-app surely would have installed what was needed right? So I checked my package.json and sure enough, the tailwindcss dependency was there, along with the React dependencies and types.

"dependencies": {
  "next": "14.0.2",
  "react": "^18",
  "react-dom": "^18"
},
"devDependencies": {
  "@types/node": "^20",
  "@types/react": "^18",
  "@types/react-dom": "^18",
  "autoprefixer": "^10.0.1",
  "eslint": "^8",
  "eslint-config-next": "14.0.2",
  "postcss": "^8",
  "tailwindcss": "^3.3.0",
  "typescript": "^5"
}

In any case, I decided to check the index.tsx file, and it was even worse, spitting out '... Cannot find module ...' and '... no interface exists ...' errors all over the file! 😱

Cannot find module 'next/image' or its corresponding type declarations.

JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.

First Attempts to Fix the Issue

Being relatively new to TypeScript and working with it, I vaguely remembered having issues with TypeScript imports before in Visual Studio Code, but thought I had taken care of the issue globally previously. Apparently not. 🤨

VS Code SDK & TypeScript Version

So I ran the steps I thought I did last time this happened, which was to install the VS Code SDK package from the CLI ...

yarn dlx @yarnpkg/sdks vscode

and then select the workspace TypeScript version, and finally restart the TypeScript server.

But ... it didn't work this time. I was still getting the same damn errors. 😒

So, I rolled up my sleeves, prayed to the Google-fu gods, and started searching for a solution.

Opting Out of Yarn PnP

I found a few posts on Stack Overflow, but most of the "solutions" were to simply opt-out of Yarn PnP, which was exactly what I wanted to avoid. This post on Stack Overflow for example had several people talking about setting the Yarn version to classic or adding the nodeLinker: node-modules option in .yarnrc.yml to downgrade Yarn and create the node_modules folder.

Uhh, no thanks... I'm not going back to the old node_modules mess!

Installing the Dependencies with npm

Others in the same thread suggested to use npm to install the dependencies, and then re-run Yarn. But, that's completely pointless, and ... then why use Yarn at all in the first place? 🤔

Explicitly Installing Types

I figured I might as well try installing the types explicitly, despite assuming they'd already be there (not in package.json, but in the main code), so I ran:

yarn add -D @types/next @types/tailwindcss

But that also did nothing as I figured, and it should also be noted that these packages have been deprecated per npmjs.org:

So, time to put on my thinking cap and figure this out the right way...

The Actual Solution

I went back over what I did last time, and noticed I had also explicitly set the Yarn version to berry last time, which I hadn't done this time.

So I tried that again, and thankfully, finally, it got things working! 🎉

I had originally mistakenly assumed that because I bootstrapped the project with Yarn Berry, that it would have already been set to berry by default, but it seems that isn't the case.

Explicitly setting it to berry added a "packageManager": "yarn@4.0.1" to package.json, and then running yarn again after caused Yarn to pull in any updated dependencies, including those for TypeScript.

Step-by-Step Instructions

So here's what I had to do to fix the issue while keeping Yarn PnP, step-by-step:

From the CLI:

yarn set version berry && yarn
yarn dlx @yarnpkg/sdks vscode

Then in Visual Studio Code:
1. Set the TypeScript version to the workspace version:
  1. Open a TypeScript file, and open the command palette:
    - on a Mac, press ⌘ + Shift + p
    - on a PC, press Ctrl + Shift + p
  2. Choose Select TypeScript Version.
  3. And then select Use Workspace Version.
2. Restart the TypeScript server:
  1. Go back into the command palette:
    - on a Mac, press ⌘ + Shift + p
    - on a PC, press Ctrl + Shift + p
  2. Choose TypeScript: Restart TS server.

Note: Yarn also recommends installing the ZipFS extension for VS Code, so you may need to get that as well if you don't already have it installed.

And that's it - super simple!

The errors disappeared in all of the files, and I was able to get back to work without having to resort to downgrading Yarn and opting out of PnP.

So if you're experiencing any issues like I was, whether:

Cannot find module '...' or its corresponding type declarations

JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.

... and you don't want to revert back to the old node_modules mess, then try the steps above to see if they fix your issue(s).

Did this help you out? Let me know in the comments below!

Fix "Unknown at rule @tailwind" errors in VS Code

Michael La Posta — Sat, 06 Jan 2024 14:00:00 +0000

TailwindCSS is something I've only just come into recently, while working on an existing project started by someone else. So I'm a complete beginner when it comes to Tailwind.

Initially I couldn't really see the point of Tailwind. I mean it really just looked to me like writing inline-style rules, but in the class attribute instead of the style attribute. But since the project was already using it, I had to at least understand the basics.

Well, after using it for a while, and reading through some of the Tailwind docs, I can now see the benefits, and I'm actually starting to really like it. So when I started bootstrapping a new project a few weeks ago, I thought "Hey, why not use Tailwind?"!

So after bootstrapping my app, and since I'm building the app using Next.JS, I started by installing TailwindCSS following the Tailwind docs for a Next JS installation.

The Problem

After getting Tailwind installed, I checked out a few of the files, and I noticed an issue that had been bothering me in my last project ... Visual Studio Code's IntelliSense wasn't working for the @tailwind and @apply directives in my global styles file! 😡

So while the directives should have looked something like this, with no errors:

@tailwind base;
@tailwind components;
@tailwind utilities;

Visual Studio Code was underlining them with the yellow squiggly line, indicating a problem:

Specifically, Visual Studio Code was throwing the errors "Unknown at rule @tailwind" or "Unknown at rule @apply", depending on which one(s) I was using.

On the last project, laziness got the better of me and I just ignored it, and it didn't seem to be causing any issues. But this time, starting a new project, I had to do something about it or I knew it would just drive me nuts! 😒

So after some quick digging, I found a few stackoverflow posts that addressed the issue a few different ways, but this more recent one was the most up to date, and to the point.

However, like the other answers I found, it was missing a crucial step I needed to get it working. So after doing some more digging, and a bit of trial and error, I was finally able to get things working.

Here's what I did to fix the issue:

Fix VS Code's IntelliSense for TailwindCSS

First off, if you haven't already, start by installing the TailwindCSS package in your project:

# Using npm
npm install tailwindcss

# Using Yarn
yarn add tailwindcss

Or, for a Next.JS project, like I'm doing:

# Using npm
npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

# Using Yarn
yarn add -D tailwindcss postcss autoprefixer
yarn dlx tailwindcss init -p

Next, in your tailwind.config.css, which was just created with the tailwindcss init -p command, add the following to the module.exports content key:

content: [
  "./app/**/*.{js,ts,jsx,tsx,mdx}",
  "./pages/**/*.{js,ts,jsx,tsx,mdx}",
  "./components/**/*.{js,ts,jsx,tsx,mdx}",
],

Or, if you're using the 'src' folder in your project:

content: [
  "./src/**/*.{js,ts,jsx,tsx,mdx}",
],

Once that's done, and this was the crucial missing step in the answers I found online:
1. Go into your extensions in Visual Studio Code, and
2. Install the Tailwind CSS IntelliSense extension.
This is what will allow Visual Studio Code to actually recognize the directives.
And then finally, after the TailwindCSS IntelliSense extension is installed, you'll need to add a file association. To do this:
1. Go into your Visual Studio Code settings:
  - On a Mac, you can do this by going to Code > Settings... > Settings, or by using the keyboard shortcut ⌘ + ,.
  - On a PC, you can do this by going to File > Preferences > Settings, or by using the keyboard shortcut Ctrl + ,.
2. Then, in the search bar, type in "files associations", and click on the Add Item button under the 'Files: Associations' section.
3. Under the Item column, add "*.css" (without the quotes), and under the Value column, add "tailwindcss" (again, without the quotes). Click the Ok button to save the changes.

And that's all there is to it!

Simple eh? 😁

Now, when you use the @tailwind and @apply directives in your CSS files, Visual Studio Code will no longer throw the "Unknown at rule @tailwind" or "Unknown at rule @apply" errors, and you'll get the IntelliSense you're used to with CSS!

Notes

If you've followed posts online that miss the installation of the TailwindCSS IntelliSense extension, you'll end up with broken IntelliSense for CSS, and your CSS files will look like regular text files without any highlighting:

So if you've followed other instructions online that left you with non-highlighted CSS files and broken IntelliSense, you're just missing the TailwindCSS IntelliSense extension to fix things up!

Hope this post was able to help if you were in the same boat as me!

Build a Simple Contact Form with Next.JS and Netlify

Michael La Posta — Fri, 29 Dec 2023 12:10:25 +0000

Adding forms to a website can be a simple matter, or a complex one, depending on the requirements and environment the website is running on.

In the dev and production environments I've worked in professionally, I've simply built-up any forms I needed using React and JavaScript, and then sent the form data to one of my ExpressJS API endpoints, which would either spit the data into a database, or shoot off an email using corporate SMTP servers.

On the other hand, if you're hosting a site in the cloud, you might not have access to a backend API, or SMTP server, or you might not want to have to deal with the hassle of setting up and maintaining one. That's where something like Netlify's serverless form handling can come in really handy!

Netlify Forms

Netlify’s serverless form handling allows you to manage forms without extra API calls or additional JavaScript. Once enabled, the built-in form detection feature allows our build system to automatically parse your HTML at deploy time, so there’s no need for you to make an API call or include extra JavaScript on your site.
docs.netlify.com

So with Netlify form handling, you can create HTML-only forms, and Netlify will handle the rest for you. Simple as that.

You do however have the option to use JavaScript, or a library like React, or even a system that will statically render the form for you, like Next JS, which is what I'll be using in this post.

Now a lot of the examples I found online gave some basic info on how to set things up, but generally using plain old HTML. Even the ones using Next JS, as I was doing, didn't include examples of how to do custom success or error fetching or omitted important details. So I figured I'd write this post to help others out who might be looking for a more complete example.

Bootstrapping the Next JS App

You can bootstrap your app anyway you like, but for simplicity, I'm using the next-app template. I'm also calling my project (and folder) nextjs-netlify-form, but you can call it whatever you like.

Using yarn:

yarn create next-app nextjs-netlify-form

Or, if you're using npx, you can use the following:

npx create-next-app nextjs-netlify-form

After the project initialized, I used the following settings:

✔ What is your project named? … nextjs-netlify-form
✔ Would you like to use TypeScript? … No
✔ Would you like to use ESLint? … Yes
✔ Would you like to use Tailwind CSS? … Yes
✔ Would you like to use `src/` directory? … No
✔ Would you like to use App Router? (recommended) … No
✔ Would you like to customize the default import alias? … No

Once that's all done, change into the project directory:

cd nextjs-netlify-form

And then open up your code editor.

Setting up the Form

Now, for this example form, I don't really care too much about styling, as the main focus here is on the form handling. I'll use some minimal Tailwind CSS styling for the form, but won't be discussing it here as that's beyond the scope of this post.

So in your code editor, open the pages/index.js file, remove everything, and then add the following:

import { useState } from "react";

export default function Home() {
  return (
    <div className="container mx-auto">
      <h1 className="text-3xl font-bold text-center">Contact Form</h1>
    </div>
  );
}

Next, open the styles/globals.css file, and remove the body styling, so it now looks like this:

@tailwind base;
@tailwind components;
@tailwind utilities;

:root {
  --foreground-rgb: 0, 0, 0;
  --background-start-rgb: 214, 219, 220;
  --background-end-rgb: 255, 255, 255;
}

@media (prefers-color-scheme: dark) {
  :root {
    --foreground-rgb: 255, 255, 255;
    --background-start-rgb: 0, 0, 0;
    --background-end-rgb: 0, 0, 0;
  }
}

Now we'll need to add the three basic contact form elements, which will be:

Name
Email
Message

So back in the pages/index.js file, modify it as follows:

import { useState } from "react";

export default function Home() {
  return (
    <div className="container mx-auto max-w-lg">
      <h1 className="text-3xl font-bold text-center">Contact Form</h1>

      <form className="flex flex-col space-y-4">
        <label className="flex flex-col">
          <span className="text-lg font-bold">Name</span>
          <input
            className="border border-gray-300 rounded-md"
            type="text"
            name="name"
            placeholder="Name (required)"
            required
          />
        </label>

        <label className="flex flex-col">
          <span className="text-lg font-bold">Email</span>
          <input
            className="border border-gray-300 rounded-md"
            type="email"
            name="email"
            placeholder="Email address"
          />
        </label>

        <label className="flex flex-col">
          <span className="text-lg font-bold">Message</span>
          <textarea
            className="border border-gray-300 rounded-md"
            name="message"
            placeholder="Message (required)"
            required
          />
        </label>

        <button className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
          Submit
        </button>
      </form>
    </div>
  );
}

Notice in the above code, for the name and message fields, I've added the required attribute. This will make sure that the user has to fill in those fields before the form can be submitted. I've left the email as optional for a few reasons:

Email validation is a tricky business, and even expert developers disagree on the one true way to validate an email address. There's also the argument that no matter what client-side validation you do, the only real way to test the validity of an email address is to send an email to it, and see if it bounces. And that's way beyond the scope of this post.

The end-user might not want to supply their email address for any number of reasons, especially in this day and age of privacy concerns. They might also just want to drop a simple "Hey, your site sucks and you can't code for sh!t!" message, and not want to be contacted back. So forcing them to supply an email address would be a bad user experience. 🤪

Now, if you run the app from the command shell using yarn dev or npm run dev, you should see the following in your browser:

Ok, so we've got a basic form with the fields we need, but it currently doesn't do anything! So we'll now add the Netlify form handling data.

Adding the Netlify Form Handling Data

Still in the pages/index.js file, in the <form> tag, we'll add the following attributes:

<form
  className="flex flex-col space-y-4"
  name="contact"
  method="POST"
  action="/"
  data-netlify="true"
  data-netlify-honeypot="bot-sniffer"
>

The important things to note here are:

The name attribute, which Netlify will use to identify the form.
The action attribute, which will allow us to remain on the same page after the form is submitted. You can omit the action attribute if you want, but that will cause Netlify to redirect to their success page after the form is submitted successfully, which isn't something I want. Note that I've used the single forward-slash ('/'), because in this example, we are running from the root of the site. If you were running from a sub-directory, you'd need to add that route to the action attribute after the '/'.
The data-netlify="true" attribute, which is the "hook" that tells Netlify to handle the form submission.
And the data-netlify-honeypot="bot-sniffer" attribute, which is a "honeypot" field that will help prevent spam submissions. We'll go into this next ...

Under the <form> tag we just added, we'll now add a hidden <input> tag, followed by our honeypot field as follows:

<form
  className="flex flex-col space-y-4"
  name="contact"
  method="POST"
  action="/"
  data-netlify="true"
  data-netlify-honeypot="bot-sniffer"
>
  <input type="hidden" name="form-name" value="contact" />
  <label className='hidden'>
    <input name='bot-sniffer' />
  </label>

The 1st <input> tag is the one that Netlify needs to use to identify the form, without which Netlify's hook won't run. Note that the value attribute of this <input> tag must match the name attribute of the <form> tag.

The 2nd <input> tag is our honeypot field. The honeypot <input>'s name attribute must match the data-netlify-honeypot attribute in the <form> tag for the honeypot to work. The hidden class will hide the field from the user, as we don't want the actual user filling it out.

The idea behind the honeypot field is that bots will fill out all the fields in a form, including the hidden ones, whereas humans won't. So if the honeypot field is filled out, we know it's most likely a bot, and Netlify's workflow will automatically flag the submission as spam.

Adding Some JavaScript for Validation and Posting

Now, as the form is currently, we're almost ready to call it a day. But if we want to do some custom error handling, or success handling, we'll need to add some JavaScript to the mix.

Additionally, while the form will require the name and message fields to have some text in them due to our use of the required attribute on the inputs, it won't actually check to see if a valid name or message was entered.

What's a valid name and message you ask? Well, I suppose that's debatable. But for this example, I'll say that a valid name is one that has at least 3 letters, and a valid message is one that has at least 10 non-special characters.

So, in the pages/index.js file, we'll make the following changes to the top of the file:

import { useState } from "react";

const MIN_NAME_LENGTH = 3;
const MIN_MESSAGE_LENGTH = 10;

const formDefaults = {
  'form-name': 'contact',
  name: '',
  email: '',
  message: '',
};

const validatedDefault = {
  name: true,
  message: true,
};

The MIN_NAME_LENGTH and MIN_MESSAGE_LENGTH constants will be used to validate the name and message fields, the formDefaults constant will be used to set/reset the form fields, and the validatedDefault constant will be used to set the initial state of the form validation.

In the formDefaults constant above, the form-name key will be mirroring the role of the crucial <input type="hidden" name="form-name" value="contact" /> tag we added at the beginning of our form, that's required by Netlify. Because we're using React / Next JS, and submitting the data in a state variable, I'm adding that key to the state variable, as it needs to be POST'ed when the form is submitted. The value of the form-name key must match the name attribute of the form or Netlify won't be able to identify the form.

Next, we'll add the following code to the top of the Home component, right above our return statement:

export default function Home() {
  const [formContents, setFormContents] = useState(formDefaults);
  const [validated, setValidated] = useState(validatedDefault);
  const [errorMessage, setErrorMessage] = useState('');

  const handleChange = (e) => {
    setFormContents((prev) => ({ ...prev, [e.target.name]: e.target.value }));
    setErrorMessage('');

    if (validated[e.target.name] === false) {
      validateFields();
    }
  };

  const handleSubmit = (e) => {
    e.preventDefault();

    if (validateFields()) {
      fetch('/', {
        method: 'POST',
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
        body: new URLSearchParams(formContents).toString(),
      })
        .then((res) => {
          if (res.status === 200) {
            alert('Message sent!');

            setFormContents(formDefaults);
            setErrorMessage('');
          } else throw new Error(`${res.status} - ${res.statusText}`);
        })
        .catch((error) => {
          setErrorMessage(
            `Oops, looks like there was an error while sending your message: ${error.message}`
          );
        });
    }
  };

  const validateFields = () => {
    let tempValidated = true;

    if (formContents.name.replace(/[^A-Z]/gi, '').length < MIN_NAME_LENGTH) {
      setValidated((prev) => ({ ...prev, name: false }));
      tempValidated = false;
    } else setValidated((prev) => ({ ...prev, name: true }));

    if (
      formContents.message.replace(/[^A-Z0-9]/gi, '').length <
      MIN_MESSAGE_LENGTH
    ) {
      setValidated((prev) => ({ ...prev, message: false }));
      tempValidated = false;
    } else setValidated((prev) => ({ ...prev, message: true }));

    return tempValidated;
  };

In the above code, the handleChange function will simply update the state object keys, clear any existing error message, and then call the validateFields function if the field that was changed was previously invalid.

The handleSubmit function will prevent the default form submission, call the validateFields function, and if the fields are valid, it will POST the form data to Netlify using a fetch() promise, and then reset the form fields and clear any existing error message. If there was an error while submitting the form, it will set the error message to display the error, otherwise it will display a simple success alert.

Update the JSX to Work with the JavaScript

Now that our JavaScript code is in place, we'll need to update the JSX to work with it.

First, we'll add a submit handler (onSubmit={handleSubmit}) below the data-netlify-honeypot attribute to the <form> tag as such:

<form
  className='flex flex-col space-y-4'
  name='contact'
  method='POST'
  action='/'
  data-netlify='true'
  data-netlify-honeypot='bot-sniffer'
  onSubmit={handleSubmit}
>

Next, add an onChange={handleChange} attribute to each of the <input> and <textarea> tags. This will allow us to update the state variables as the user types in the form fields. Then we'll modify the code to add error display <div>'s below the name and message fields, as such:

For the name input field, modify it as follows:

<label className='flex flex-col'>
  <span className='text-lg font-bold'>Name</span>
  <input
    className='border border-gray-300 rounded-md'
    type='text'
    name='name'
    placeholder='Name (required)'
    value={formContents.name}
    onChange={handleChange}
    required
  />
  {validated.name === false && (
    <div className='text-red-500 text-sm'>
      Please enter a name at least
      {' ' + MIN_NAME_LENGTH + ' '}
      characters long.
    </div>
  )}
</label>

and for the message textarea field, modify it as follows:

<label className='flex flex-col'>
  <span className='text-lg font-bold'>Message</span>
  <textarea
    className='border border-gray-300 rounded-md'
    name='message'
    placeholder='Message (required)'
    value={formContents.message}
    onChange={handleChange}
    required
  />
  {validated.message === false && (
    <div className='text-red-500 text-sm'>
      Please enter a message at least
      {' ' + MIN_MESSAGE_LENGTH + ' '}
      characters long.
    </div>
  )}
</label>

And then finally, we'll add one last error display <div> above the submit button, as such:

{errorMessage !== '' && (
  <div className='flex justify-center'>
    <div className='text-red-500 text-sm'>{errorMessage}</div>
  </div>
)}

The 1st two error display <div>'s will only show if the user has entered an invalid name or message, whereas the last one will only show if there was an error while submitting the form.

Whew, that was a lot of changes to make! Hopefully I didn't make any typos or confuse you too much along the way, but if I did, you can always check out the GitHub repo for this post. You can also go straight to the pages/index.js file here to check out the final code.

Enabling Netlify Form Handling

Ok, so now that we've got the form all set up, we need to enable Netlify form handling.

Now, I'm going to assume you have a Netlify account already, which is why you're reading this post in the first place. If you don't, you can sign up for a free account on netlify.com.

I'm not going to go over the steps to create a new site on Netlify, as that's pretty straight forward. But once you've created your site, you'll need to enable Netlify form handling, which is what we'll be doing next.

Now if you want to get the details straight from the horses mouth, you can check out Netlify's docs on form handling, which goes over the steps in detail, and also gives HTML and JavaScript setup examples. They don't however give any examples using React or Next JS, which is why I wrote this post.

So, in order to enable Netlify form handling:

Log into your Netlify account and go to your site's dashboard.
Select the Site configuration option from the left-hand menu.
To the right of the main menu, click on Forms to expand the Forms sub-menu, and then either select the Configuration item, or simply scroll down to the bottom of the page.
In the Form detection card, click on the "Enable form detection" button.

Once that's done, you'll simply need to deploy (or redeploy) your site, and Netlify will take care of the rest!

Note that if you enabled the form detection after you deployed your site, you'll need to redeploy your site for the form detection to work. That's a mistake I made at first, and was confused when the form wasn't working! 🤣

Testing the Form

Now that we've got the form all set up, we'll want to test it out to make sure it's working as expected.

Unfortunately, one of the major drawbacks with this system is that you can't fully test it locally. You can test for simple things like the length of the name and message fields, but you can't test the actual submission of the form.

To do that, you'll need to deploy your site to a live environment in order to properly test it. This is because Netlify needs to be able to parse the HTML at deploy time, and then inject the necessary JavaScript into the page.

So after deploying it to my Netlify site, I submitted a basic test message, and then checked the Forms menu item in my Netlify dashboard.

After expanding the contact submission in the Active forms card, my message was there ...

Phew, it worked! 🎉

Enabling Email Notifications

You don't need to worry about always checking your Netlify console for new messages, as you can set up email notifications to be sent to you whenever a new message is submitted.

Doing so is a super simple process, which you can read about in Netlify's docs on form notifications.

That wraps it up for this post.

I hope you found it useful, and if you had any issues with your own form, you were able to fix them using this tutorial.

Forem: Michael La Posta

In a World with AI, Where Will the Future of Developers Lie?

The Rise of ChatGPT and Large Language Models

What is a Large Language Model?

Using ChatGPT to be more productive

Are Developers Doomed?

It's not just techies that are at risk

AI and Prompting

Creators - or Prompters?

The Future of Developers

My Prediction

Since when can humans predict the future?

Google's Decision to Effectively Kill-off Small Sites

Forgive me SEO gods, for I Have Sinned

The Start of my Blog

The Google HCU Massacre

"If Your Site Was Affected, You're a Spammer!"

But Who Has Actually Been Affected?

Is This the End for Small Sites?

Google isn't the Only Search Engine in Town

Where to Go From Here

How to Redirect URLs with Netlify

Method 1: Using the _redirects file

Basic Syntax

Wildcards and Placeholders

HTTP Status Codes

Other Options

Method 2: Using the netlify.toml file

Final Thoughts

Is Hosting on Netlify Going to Bankrupt you?

The Concern

The Aftermath

Final Thoughts

Fix Path Name Mismatches in Local & Remote Git Repos

The Problem

Initial (Faulty) Git Update

First Attempt to Search for a Solution

Second Attempt to Search for a Solution

The Actual Working Solution

Explanation

"git rm -r --cached ."

"git add --all ."

Limit the Number of Pre-rendered Pages in Next.js

A little bit of Back in the Day ...

Enter the dynamic web ...

Hello meta-frameworks ...

The Problem

In an ideal world...

The Solution (well ... sort of)

The Gist

The Code

Key Points

The Result

Conclusion

Understanding PostgreSQL RLS, and When to Use it

What is PostgreSQL Row-Level Security?

Why is PostgreSQL Row-Level Security such a big deal?

Some RLS Examples

Example 1: Bypassing RLS on a table when RLS is enabled

Example 2: Restricting access to a table based on user ID

Example 3: Restricting access to a table based on logged in status

When should you use PostgreSQL Row-Level Security?

In a nutshell

Build a Weather Widget Using Next.js

Why use Next.js?

Bootstrap the Project (optional)

1. Create the Project

2. Delete Unnecessary Files

3. Delete Unnecessary Code

Setup your OpenWeatherMap API Key

Create the Weather Data API

Define the Widget Styling

Create the Weather Widget Component

Update the Index Page

The Final Result

Additional Thoughts

5 Ways to Redirect URLs in Next.JS

Method 1: Using next.config.js

Method 2: Using getStaticProps

Method 3: Using getServerSideProps

Method 1: Using the `_redirects` file

Method 2: Using the `netlify.toml` file