Making My Own Way
Out with the old and in with the new
I finally pulled through with my promises and after a lot of trial and error my pull request for porting the old Gatsby error page to Next is up for review. Needless to say, this was a monster of a challenge to tackle because of the way I approached the task — which is something that I want to talk about as I walk you all through the process.
My Mindset and How It Changed
For a bit of backstory, this issue of porting the error page has been on my plate for a while. After my learning experience of porting the SearchResults.tsx component (see PR here) without too much trouble, I came into this challenge expecting the same results… and boy was I in for a bit of a wake up call. You see, I was able to port the previous component without really changing much of the original code, all that was required of me was to change some parts to support TypeScript and fix bugs here and there. Whereas for the error page, it required me to make some tough decisions about removing parts of the old code.
I really did not want to change parts of the code more than I needed to. If this was my own personal school assignment project where I can do things how I want, then I wouldn’t mind having the mentality of “if it works that’s all that matters, just get it done”. But for an open source project such as Telescope with many moving parts that all sort of connect with each other, the last thing I would want to do is break something because of that “just get it done” mentality. This new idea that everything had to be perfect led me to think that I needed to port this error page changing as little as possible — after all, the less you change the less places you have to break the code, right?…
The Problems That Came
The thing was, the way that the old JavaScript error page displayed the error message just couldn’t stop complaining when I tried porting it to TypeScript. It was this interesting problem of a round chain of complaints where the object that held all the different status codes and error messages couldn’t be indexed without changing the object itself. To add support for indexing would mean that the status code (which is the key) MUST ONLY be a string— however the way we get the status code (through the use of params.get()) can return a string or a null and TypeScript DID NOT like that. This is where I hesitated, doubted myself and believed that there's a solution I’m just not seeing and that I was doing something wrong. I knew that there must be a way to keep the original code. Alas, something had to give, I either needed a way to extract the parameters from the URL that will always return a string, or I had to discard the old object which held all the status codes and error messages. After nights of research, I opted for the latter. Secondly, the old way of getting the querying the URL was outdated, and I had no idea how to do it in Next.js. This is where I reached out for help, to which I was directed to use next/router. Lastly, within the error page was an obsolete component called Pagebase which was needed in the Gatsby frontend to essentially act as a layout for each page. After meeting with chrispinkney, we discovered that the Pagebase component’s functions were no longer needed.
The Solution That Pulled Through
Now back to the porting of the error page. I went to the original PR to see how they did it, and thought to try and implement it alongside the current code. The original author of this issue, hyunjiLeeTech, used a switch statement which would allow for me to define the statusCode as a string or null which I could then cast to a number to be used in said switch statement. This way I solve my original problems: TypeScript no longer has to worry about the ambiguity of the statusCode AND regardless of what the statusCode is (a string or null), I know I can use it to “index” via the switch statement after casting it to a number. This worked exactly as intended and after a day of manual testing I submitted the PR.
What I Learned
Now as you can see I went against my beginning mindset to try and not change anything, but what good does not changing anything (to avoid breaking stuff) bring if nothing gets done? I think there must be a balance of being careful and precise when modifying the code base and also being confident and creative so that you have the courage to make the decisions you need to put something out there.
