paint-brush
The raider of the lost stacks, Day 2by@pedromig

The raider of the lost stacks, Day 2

by Pedro GasparSeptember 14th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Being a dad is the greatest thing in the world and at the same time the most life draining job in the world.

Coin Mentioned

Mention Thumbnail
featured image - The raider of the lost stacks, Day 2
Pedro Gaspar HackerNoon profile picture

Being a dad is the greatest thing in the world and at the same time the most life draining job in the world.

Well, two days have passed and unfortunately, I had no time or mood for continuing my challenge. My daughter has been sick and I’ve been working at Talkdesk by day and doing the night shift taking care of her 😢.

Today on the train I was able to do some work 💪.

The first thing to do when starting a React project, is to do an initial HTML mockup of the final work. Without doing any kind of programming, just plain HTML and CSS. Don’t rush this stage because changes are cheap and easy.

You can check it at https://github.com/pedromig/just-do-it/commit/b9515069e313e67ac40a37edf929f26e031fc32b.

Doing this on the train made me realize something important when you clone a project don’t forget to do a yarn install before going on a trip without internet 🤦‍.

This also revealed that my CSS foo muscle memory is pretty low nowadays.

<a href="https://medium.com/media/f691d9747ed33e2bb40f32aafa136524/href">https://medium.com/media/f691d9747ed33e2bb40f32aafa136524/href</a>

Must do a refresh on Flexbox, and these three resources are pretty amazing:

So a future cheat sheet is in the making 😄

After the initial mockup was done, I moved to the second step which is to break the HTML into React components, at this state without any kind of state, this is will be done later.

The places where we have component repetition will be great candidates where state will exist.

I believe this is a good workflow:

  1. First, start by laying out the UI in HTML and CSS without any kind of programming.
  2. Then break into components
  3. Introduce state on the fewest places possible
  4. Introduce interactivity though events and handle state changes
  5. Receive the state from the server
  6. Refactor
  7. Tests
  8. Profit

You can check the changes at https://github.com/pedromig/just-do-it/commit/83c449d6088263024ecab141905fb95133f0b1b9.

Moved all the components into a components folder and created an assets file for local images.

This is only a very small app that I’m building to practice but I’m trying to go slowly each step and search for best practices.

One action remains, to check if at this stage in 2017 there are best practices guides like the ones that were done by the Angular community, especially Tod Motto and John Papa. Some questions arise:

  • Should we have a components directory, and put all components there?
  • Better break stuff in folders by feature?
  • The initial component App should be at the root or in the components folder?
  • Is naming App for the root component a good practice?
  • Should it be isCompleted or isComplete?
  • Are the specs in the same folder as the component or in a specs/tests folder?

<a href="https://medium.com/media/016c837f6ef9da1a58b1f4f98a54647f/href">https://medium.com/media/016c837f6ef9da1a58b1f4f98a54647f/href</a>

What’s the best way to declare a component?

I really like the stateless functional components, I must use them whenever possible:

import React from "react"

const AwesomeComponent = ({ name }) => (
  <div>Hello {name}</div>
)

<a href="https://medium.com/media/515c645285d7a98cdde964377f0897a2/href">https://medium.com/media/515c645285d7a98cdde964377f0897a2/href</a>

But, what’s the preferred way for “regular” ones?

import React, { Component } from "react"

class AwesomeComponent extends Component {
  render () {
    return (
      <div>Hello {name}</div>
    )
  }
}

or

import React from "react"

class AwesomeComponent extends React.Component {
  render () {
    return (
      <div>Hello {name}</div>
    )
  }
}

Is there any difference since we have to always import React?

Should the components be exported by default without a const?

import React from "react"

export default ({ name }) => (
  <div>Hello {name}</div>
)

Or with continue being exported by default but with a const declaration?

import React from "react"

const AwesomeComponent = ({ name }) => (
  <div>Hello {name}</div>
)

export default AwesomeComponent

Or be done by named exports?

import React from "react"

const AwesomeComponent = ({ name }) => (
  <div>Hello {name}</div>
)

export { AwesomeComponent }

<a href="https://medium.com/media/9cdc09a7d438c6d95b75ee3d576c311e/href">https://medium.com/media/9cdc09a7d438c6d95b75ee3d576c311e/href</a>

Another thing that is popping up is styling, although CSS is a powerful styling language, and it’s best to stick to the Cascading behavior, when complexity grows so does the effort of maintaining a large stylesheet. I’m really curious about the current movement towards styling with javascript, so need to check it in a near future. Glamorous, I’ve got my eyes on you. Having the styling scoped to the component seems natural to me.

Adding a conditional class name like this is ugly.

className={isCompleted ? 'TodoItem isCompleted' : 'TodoItem'}

I remember that a classNames module exists to cover cases like this, but is it the best approach?

Does glamorous help in these situations?

<a href="https://medium.com/media/d6be7faa8228e6abb24b4280bf4373bc/href">https://medium.com/media/d6be7faa8228e6abb24b4280bf4373bc/href</a>

Well that’s it for today, another bad parenting night is in the making 😨.

This is part of my The raiders of the lost stacks challenge.

Today’s numbers: about 90 min writing/hacking and current weight 106.4kg