DOCUMENTATION - COMMENTING

[keanacobarde]

User Story

I, as the user, will not see this, but I, as the developer, will. Comments ensure the future comprehension and ease of implementation for other systems that you, or any other developer, may wish to implement.

Acceptance Criteria

• Comments should be present wherever the purpose of something is not immediately evident. The structure of your code in certain places wouldn't be easy for someone to discern the logic behind. Change this and document WHY it's this way.
• There should be a bajillion comments everywhere. Keep comments clean, precise, and only in places they are deemed necessary. While you're at it, also clear unwanted console.warns().

Dependencies

N / A

Dev Notes

• What's different about your application from others that you have in your knowledgebase?
• Think about what future you would like to know when she comes back to look at this code.
• Think back to all of the discoveries/important ideas you stumbled on using MUI, passing in components, and dealing with some of the math logic.

[keanacobarde]

You don't need to make a whole book of comments within your components, but you do need to ensure that each component has a consistent and readable structure.

[keanacobarde]

RESTRUCTURING COMPONENTS

Forms

• [x] CategoryForm.js
• [x] ExpenseForm.js
• [x] MonthlyIncome.js

Cards

• [x] ExpenseCards.js
• [x] CategoryCards.js

MISC.

• [x] NavBar.js
• [x] Popup.js
• [x] Footer.js

PAGES

• [x] Index.js
• [x] Timeline.js
• [x] CategoryDetails.js ([firebaseKey].js)
• [x] Month.js (not really a page, as much as it is a snap-in component akin to cards.)

[keanacobarde]

CLOSED PER PR #42 - CLOSING ISSUE