Day 5 - Finding errors
Rule 1: Things will always go wrong
Things will always go wrong. If you aren’t regularly making mistakes, then you are doing something that is too easy for you. And if you’re going to make mistakes, you need
- A good system for preventing those mistakes from impacting your users
- An easy way to find and fix what went wrong
- Errors highlighted as early as possible
What went wrong
All I changed was some copy, that is to say, the text. How could that possibly go wrong? Well, in the last post I mentioned using an apostrophe without encoding it. And then I said how you should never ignore VSCode’s errors. Well, I ignored VSCode’s error and I committed the change before fixing. So this error was highlighted as soon as it was created, but unfortunately, I wasn’t forced to do anything about it.
Did it get to production?
No! It’s actually really cool that I haven’t done anything special to protect against this, but the default set up means that Vercel and GitHub protected me. When I pushed my code changes to the branch on GitHub, Vercel found the changes, and tried to build the code and deploy it on a branch deployment - more about these in the next blog. It checked the code as it was building it to be deployed. When it found the error, it told GitHub, which shows on the GitHub pull request that one of the checks hasn’t passed. So no, we can’t merge it to the main branch to go to production.
How did I find the error?
Opening up the failed check on GitHub and clicking "details" there is some logging that you can read around the error that was found.
Failed to compile.
./app/page.js
9:33 Error: '’' can be escaped with ''', '‘', ''', '’'. react/no-unescaped-entities
info - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rulesSo it has told us that it failed to compile the code, which means turn it from human readable code to computer readable code. Then it has told us the file that the error came from. It even tells us that it is line 9, the 33rd character in. Then it tells us what the error is and ways to fix it. Then it tells us where we can look to learn about this error. This is so much help in identifying and fixing errors.
Was this all just a waste of time?
The rule is protecting me as a developer, it’s a sensible but annoying rule. Characters like ’ are the kind of characters that are used to define code so React looks out to see if you’ve used them somewhere that it’s going to display to the user, and this error is its way of getting you to check that you really wanted that or you made a mistake and accidentally leaked some of you code onto the display that your users see.
However, Writing html encoding is super annoying. It’s so much slower. It either interrupts your writing flow or you have to tidy up after writing everything. Having had to do it for a few articles now, I’m so bored of it. But in an application where you want a lot of text, it’s probably best not to type all the copy, i.e. text, into the code. Large blog applications will usually use a content management system (CMS) where the copy is stored in a database. Because it’s not actually in the code, there’s no risk that it was a typo in the code and the React linting won’t complain about it.