If I have learned anything this week about coding javascript and debugging sites using developer tools, it's that I know nothing at all. I have somehow passed the bootcamp phase of the code camp I'm a part of. Week after week for 3 hours a day we sat on meetings learning everything from variables, to loops, to functions. I can tell you why loops are necessary in code. I can tell you that without them, coding would be very meticulous and messy and it would be very difficult to debug anything, however I am now learning loops can be just as messy.
This week we had a few lessons that were very difficult for me in which I could feel myself falling behind. One was the function of the underscore library and the importance of utilizing functions to run instruction specific code. I'm realizing there's something for everything. There is a setTimer function which takes in a parameter of a wait time in ms. There is a way to take the difference of values multiple array's and return the values that are reoccurring in each array all to be returned as a new array. To put it short, there are many different ways to do many different things.
Before I started code and realized what developers meant by it being a language I assumed code was mostly like simplistic math. I assumed it only had one way of solving and one solution. I'm now realizing there is a whole world of code. There are combinations of code I had no idea existed until a few days ago.
Here's an example:
Say you're given a list of people and they all have names and ages and that list goes on for miles. You're told you need to be able to sort this list in numerous ways whether that be from a - z, z - a, or some other way of sorting.
For this example we created a _.sortby function that could take in a collection (that list) and an iterator (whatever key in the list you're sorting). This stumped me for a while because the instructions declared that we have to find a way to figure out if the iterator is a string or whether it is something else. In no world would I have assumed that the iterator would be anything but a string. That's the thing, in coding you have to be able to look ahead in case there is a typo on the part of another developer who potentially forgot to include quotes around a word that we are using for lookup or in the case that there is no string at all. For this problem we sliced the list and used .sort and two parameters to sort the list in ascending order.
_.sortBy function(collection, iterator) {
return collection.slice().sort((a, b) => {
}
}
To specify what we wanted to sort in the list, we included conditions via an if statement. If the iterator itself was a function and already had the sort conditions specified (that being the key and the sort type) then we would invoke the function on the first parameter to the invocation of the second parameter to sort the list in ascending order. Otherwise, if iterator was a string, we would return the first parameter and call the key in the list (Ex: 'name') to sort the list in ascending order using bracket notation instead of function invocation.
_.sortBy function(collection, iterator) {
return collection.slice().sort((a, b) => {
if(typeof iterator === 'function') {
return iterator(a) - iterator(b);
} else if (typeof iterator === 'string') {
return a[iterator] - b[iterator];
}
})
}
This was our final solution. Before Friday I had no idea how to use .sort and I would have had trouble understanding why it needed to be used differently depending on whether a parameter acted a as a function or a string. Now, I can semi-confidently say that a - b is a sort type. It will always sort in ascending order. To invoke the iterator function on the sort type is to simply say what we need to sort in ascending order within the list. To use bracket notation on the sort type is to do the same thing. The syntax is just different depending on the type of value iterator entails, but .sort never really changes.
Looking back, there is not much account for how the code should run in the instance that name is not a string and was entered incorrectly or for many other instances like what would happen if iterator had no value at all and was undefined or null. However, that seems like a lesson for next week. For now I believe we did our best with the information we were given and the code still passed all the provided tests. That's all for now!
Top comments (0)