Something To Keep In Mind
If you’re going through Flatiron Bootcamp, or just learning how to use Ruby and JavaScript to create dynamic web applications in some other context, this might be a helpful article for you, if you’re not, I hope you enjoy the ride anyways.
As I mentioned above, this blog post will be about JavaScript and Ruby, with a small splash into fetch requests. I recently ran into a bug when I was coding, where the fetch request kept altering my data in strange ways that didn’t seem to make sense.
After running this request my users value in the api would be altered to be the previous length of the array, plus one. After banging my head against the wall, asking a friend, and eventually asking one of our instructors about why it was happening, my instructor asked something that might seem very obvious: “What’s the return value for .push()?”.
Up until I talked to him, I had assumed that .push() would return the array itself with the pushed elements added in. After considering my instructors question I did some tests in the console, and it turns out that in JavaScript the push function returns the length of the array now that another element has been pushed into it. It didn’t take me long to track down where this strange assumption had come from, my time spent with Ruby.
Ruby and JavaScript share so much that it’s easy to forget that they’re unrelated languages, for instance (even the .pop function in JavaScript works the same as the .pop method in Ruby), but it’s very important for us to keep in mind as software engineers who are trying to learn multiple coding languages. Because even something like this small difference between the Ruby .push() method that adds an element onto the end of an array and returns the updated array, and the JavaScript function which adds an element onto the end of an array and returns the new length of said array, can completely break your code. As a side note: if you put a function to the right of the “‘users’:” key in the body section of a fetch request, the function will evaluate completely before the return value is saved as the value for the users key. It has been implied by me earlier in this blog post but I thought I would take this chance to state it clearly.
The nature of the Flatiron program encourages us to grow extremely fast as programmers, but we need to be mindful of these subtle differences, lest we build a shaky foundation. It’s sometimes more important to spend a couple extra minutes looking up the documentation for a feature you think you understand in order to save yourself the time you would need to spend trying to debug if you misremember a detail about the feature. Just something to keep in mind.
Sources:
