Refactoring and Documenting code in components/tags/tagsList
WHEN I document and alter the code in components/tags/tagsList
THEN I alter and document the code in the following way:
I used .map and filter to iterate over the recipes and obtain only the categories.
We want to display the categories as <option> elements as part of a dropdown.
I could achieve this with a for loop or using reduce as well.
Using a for loop might be faster, but it is harder to read and follow the logic. Using reduce would be more expressive/concise, but given that everyone on the project is relatively junior, it might make it harder for the rest of the team to make changes to it.
WHILE keeping the following points from Schalk in mind:
Rule of thumb: Things that change together can be grouped together
Consider WHAT something will be doing before implementing it
Design for the current use-case. Don't worry about possible future implementations
DOCUMENT parameters. WHAT are they, what are they USEed for, WHY are they necessary
DOCUMENT HOW to use a function and what its PURPOSE is
DOCUMENT the USE and REASON for every file (ask yourself what will happen if the file gets deleted to help determine this or look at the exports)
Break code up into encapsulated units with its own helper functions
EACH member of the team should be able to know what is happening in the code from reading the documentation
Documenting WHY code does what it does is more useful than documenting what it does
If you don't want to have many imports put all your functions into an object and import the object
Work from Interface => Implementation and not Implementation => Interface. Aka Think about how something is supposed to work and what it's supposed to do before you build the functionality of it.
Refactoring and Documenting code in components/tags/tagsList
WHEN I document and alter the code in components/tags/tagsList
THEN I alter and document the code in the following way:
.mapandfilterto iterate over the recipes and obtain only the categories.<option>elements as part of a dropdown.forloop or usingreduceas well.forloop might be faster, but it is harder to read and follow the logic. Usingreducewould be more expressive/concise, but given that everyone on the project is relatively junior, it might make it harder for the rest of the team to make changes to it.WHILE keeping the following points from Schalk in mind: