Recently, I was working on a web app project in React and ran into a peculiar problem. I had recently learned about React routing using React-router-dom in my bootcamp course and wanted to try implementing routes to make a more dynamic web app. The issue I ran encountered happened when I tried to generate individual route paths for my individual objects that I had pulled from a JSON database.
In my case the ${this.props.match.url} corresponded to my basic path of ‘/games/’ and whatever value came after ‘/games/’ was assigned to the key of ‘gameId’. This allows me to run a strict equality check between my ‘gameId’ and ‘id’ values of my JSON database objects and as a result, display the correct object in its corresponding url path.
Above is the logic for matching the JSON object (games in my situation) to the url path by comparing the object’s id from the database and the dynamic segment of the extended url that was assigned to the key of ‘gameId’. Once a match is found, I could then assign the matched object to the constant called ‘matchingGame’ and pass it as a prop to my GameDetail component to render the details of that specific game in its own path.
Unfortunately, the .find() function failed to find any matches and thus set the value of the matchingGame constant to undefined. This in itself wouldn’t cause any errors but as seen in the screenshot below, I’m then passing matchingGame.id as a key to the GameDetail component. Since matchingGame is undefined, my page displays the error where it cannot read property ‘id’.
After a long time of checking all of my other components, including triple or quadruple checking my routing syntax since it was my first time trying to implement it, I finally decided to console log the two variables just to see exactly what they were.
After console logging all these values, I finally realized that my routing paths were fine and it was the strict equality operator that was causing my .find() to return undefined. The nature of a strict equality operator ( === ) is to only return values that are equal and the same datatype which meant that while there are matching numbers, they probably weren’t the same datatype.
I then changed the strict equality operator to a loose equality operator ( == ) and sure enough the pages started to render but with a warning in the console asking if I had made a mistake by using the loose equality operator instead of a strict one. It seems that to match these ids, React prefers the use of strict equality. While the loose equality works in the sense that it would allow for the page render to go ahead, I would rather follow convention and work around the issue in another manner altogether.
Another way to get the two values to strictly equal each other would be to change one of the data types so that they would both be the same. I decided to change the game.id values to strings by adding .toString() after game.id but passing match.params.gameId through parseInt() to change that value into a number would achieve the same result.
While it is possible to have ids as strings to start in JSON databases to ignore this issue altogether, when using REST API to route JSON servers, the default id values are created as numbers and thus will always cause this datatype mismatch when creating route paths. Perhaps this isn’t a big issue in the grand scheme of things but for someone like myself who is still relatively new to React in general, I think this is an important enough detail to make a note of so that others who are starting out could more smoothly understand the nuances of React routing.
Another detail I want to mention is the lack of trust I have in my own code due to being new to coding. Had I been a more seasoned programmer, I probably would have started off by console logging the two values and proceeded from there. However, since I am not, I just assumed that the error must have occurred due to me miswriting some code in a different component altogether. The saying goes “Don’t lose sight of the greater picture due to some minor details” but the inverse is also an important lesson where you shouldn’t let the grand scale of a project distract you from the smaller details. After all, a forest makes for a fine place to hide a tree.
