dailymp

sass/
|
|– base/
|   |– _reset.scss       # Reset/normalize
|   |– _typography.scss  # Typography rules
|   ...                  # Etc…
|
|– components/
|   |– _buttons.scss     # Buttons
|   |– _carousel.scss    # Carousel

dailymp

Usually we organize our javascript apps either by what they are or by what they do. The first is like rails: separate directories like components, containers, reducers, etc. And the second more or less like feature/DDD: user, cart, and so on. Tho both of these options are very mainstream and solid they contain some constraints.

When you structure the code files tree by what they are you tend to keep every component of the same feature so distant that it’s very difficult to connect the pieces. Therefore you dive into some troubles like the path hell; a lot of require('../../../etc') in your code. And everything is extremely coupled to the directory structure.

In the other hand, when you are driven by what they do everything is more isolated and maintainable. But there’s a lot of duplication. And the communication between the features either is based on a weak contract or depends upon some infrastructure. Both of these options are prone to raise some bugs.

Pods it’s an evolution of the last one. You can thin

dailymp

// UNION


// Siguiendo la analogía anterior, la unión de tipos sería entendida como
// el operador OR.
// La unión de tipos es muy util para indicar que una determinada 
// entidad podrá ser de un tipo u otro, ámbos válidos.

// Por ejemplo, sin unión, tendriamos que recurrir al any para admitir
// argumentos de tipo string o númerico:

dailymp

React Alicante 2018 Talks

Conference Day 1

• 2018 - The Year of Web Components, Dominik Kundel
• The Lonely and Dark Road to Styling in React, Sara Vieira
• Next Generation Forms with React Final Form, Erik Rasmussen
• The ABC of Coded Style Guides, Henning Muszynski
• Testing, Testing, 1, 2, NaN, Gant Laborde
• Lambdas, lambdas everywhere..., Flavio Corpa