reading-notes

These are my reading notes for Code Fellows

---

Project maintained by taegorov Hosted on GitHub Pages — Theme by mattgraham

Link Home:

Home

Reading Notes Code 301: Day 5

• Single responsibility principle = components should do one single thing. If they start doing more, break them down into more components

• The reading suggests doing a type of wireframing where you take a mock design of your finished product and break it up into components. Their example looked like the following:

Mock design:

Mock design broken up into components:

The colored boxes around each component represent the following (last part of the bullet is an example component name):

1. Orange - the entire example - productTable
2. Blue - accepts user input - searchBar
3. Green - the data to be filtered by user input - productTable
4. Turquoise - each category’s heading - categoryRow
5. Red - the actual product - productRow

The reading also suggests breaking down/organizing the hierarchy like so:

• productTable (orange)
  • searchBar (blue)
  • productTable (green)
    • categoryRow (turquoise)
    • productRow (red)
• You can use the above to create the actual UI sans interactivity, then implement the interactivity later:

It’s best to decouple these processes because building a static version requires a lot of typing and no thinking, and adding interactivity requires a lot of thinking and not a lot of typing.

(source)

• Start building from the top-down or the bottom-up. Seems obvious, but I’ve fallen in the trap of trying to create something from the ‘middle’ and having my code end up really disorganized

• Cool acronym for DRY code = Don’t Repeat Yourself

• Useful questions to ask yourself while going through each piece of data:

1. Is it passed in from a parent via props? If so, it probably isn’t state.

2. Does it remain unchanged over time? If so, it probably isn’t state.

3. Can you compute it based on any other state or props in your component? If so, it isn’t state.

(source)