React Router: How a dumb mistake slowed me down for two days!

Chinomnso Awazie
Coffee & Software
Published in
4 min readMar 9, 2020
When the biggest problem is seeing where the problem is coming from!

I wasted a couple of days, too many cups of coffee, considered getting a haircut to let in more air into my head because in addition to other things, I suspected some brain overheating is making a contribution to the problem I was encountering; a component that becomes inaccessible after it is accessed once — as it appeared to be at the time.

A Little Background

React router is a life saver when working with Single Page Applications (SPA). Team it up with Redux and you become so powerful and invincible. Throw in hooks and boy you are on a roll. And if you code like me, meaning writing the least number of lines of codes possible, you start wondering why people say so little with too much lines of code. I am a fan of separation of concerns and single responsibility paradigm, however…

….my code gotta be clean! Very readably clean. I think it is common courtesy for the next cookie-cutter programmer that comes along 48 minutes after you have left a position/role to not have to lose their mind trying to read your code, then figure out what on earth each procedure, variable, object, component etc is doing. Actually, the first beneficiary of that courtesy would be you, when for some reason they pull you back to a project you left for dead 2 years ago, which in software engineering time could as well been from the last millenium. I have caught myself re-writing my codes if I go back to them few months later and it takes me more than 3 mins to place everything.

Now let’s get back to topic. React router. I use the withRouter functionality so much. I cannot remember the last time I used NavLink or even redirect. I am a pusher, and have been know to drop routing pushes in places that make people say three letter words that rhyme with ‘what the rock’, and then add, ‘I didn’t know that was even possible’. Also, in trying to keep the lines of code to a minimum, I usually tack on push as a callback on eventListeners, and that is what got me in trouble recently.

A push goes something like this push('path-name'). Depending how you got the push function into the component, it’s either just like you have it above or you add the history part of that function, something to the effect props.history.push('path-name') for function components, or this.props.history.push('path-name') for class components. In the case of an eventListener, say on a button, it goes something like this;

<button onClick={() => push('/candyland')} > Go to candyland </button>

A couple of things are going on here.

  1. This is obviously a callback.
  2. It is an arrow function. Another obvious fact.
  3. It is a function invocation - the part that got me.

Remove () =>, and you got yourself a function invocation as a callback, something I found out the hard way can be a bummer.

What Happened To Me?

So, after about over 8,000 lines of code (biggest contributor coming from me refusing to use npm packages for selection of countries, states and cities, and instead deciding to build out the function myself!), and a redux actions file that got over 1,000 lines at some point despite me trying to keep things as condensed as possible without sacrificing readability, a single line of code trounced the whole purpose of my app. It was supposed to be something to the effect of a job search result is displayed by cards with minimal info >> you click on a card and see detailed info on that job listing, then when you are in an individual job listing, you should be able to go back to the job search results and look at other options. Instead of this;

<button onClick={() => push('/candyland')} > Go to candyland </button>

I had this;

<button onClick={push('/candyland')} > Go to candyland </button>

The problem is not immediately obvious, especially when this button is buried in a component with over 160 lines of code, but what was happening was in subsequent attempts to access that component, the app sped through rendering it and went back to the search results page. It was not obvious.

How I Got My Groove Back.

So after a couple of days that involved rewriting the entire codes of the app, going for long walks and hitting the gym just to clear my head in between coding stretches, I decided to take a day off from the app. I just watched American Idol and The Voice music contestants and an inordinate amount of Steve Harvey’s Family Feud clips on youtube, made me some good traditional dishes and basically just tried to hit a reset in my mind. Then before I came back to the problem, I layed on my bed and replayed the scenarios that lead to that point of problem, formulated a couple of theories, wrote them down on paper, and proceeded to test the app to see which scenario is applicable, and in watching the address bar, I saw flickerings each time I clicked a job card tile, and it clicked — the app was actually getting to that component. I started some sort of fishbone analysis and probable cause elimination method. I commenting out codes to see when it will stop breaking. That was how I found out that all other back buttons work fine until a certain back button is clicked. And upon closer examination that involved zooming and other shenanigans, I felt dumb to not have spotted this in 5 mins! App development progressed from that point onwards, but I now knew to not mess with the arrow function when I push.

So basically, I learnt the old trick of taking a step back to gain perspective.

--

--

Chinomnso Awazie
Coffee & Software

Software engineer, Electrical Electronics engineer, Environmental engineer, humanist, sustainability enthusiast. Reporting from NYC