DEV Community: Adán Carrasco

Testing in production, is that the way to go?

Adán Carrasco — Sun, 21 Mar 2021 22:11:07 +0000

Today I'm not coming with a post but rather with a question on an interesting topic: Testing in production. Is that something you'll do? What are the tradeoffs?

Short story:
This week I worked on releasing a new App interacting with data form existing services.

The App was having some issues and I wanted to debug locally to fix them, whereas other person insisted to deploy and test in production then fix.

We needed to submit the App to AppStore and PlayStore and his argument was to speed up the review process, mine was that fixing it locally would be cheaper, then we would submit and App that we knew was working.

Any experiences on the topic? What would you have done? What would be your take?

Happy debate and thanks for sharing your ideas. :)

The how and why on TDD

Adán Carrasco — Sun, 14 Mar 2021 20:30:26 +0000

One of the crucial aspects of Software Development is the ability that our software is self tested, there are several layers to make this happen.

In today's post we are going to talk about Test Driven Development (TDD), specifically in Unit Testing.

Personally, I have been reading and even taking some courses about TDD, but I have never had the chance to apply it in real life scenarios, mostly because the projects that I have joined so far have already started some development (it's not a valid excuse).

A couple of months ago I heard of a position in a company and one of the pre-requisites was to know and have applied TDD, my CV was not even considered as I didn't have the practical experience of it, even though I knew the concept and (theoretically) I know how it works. Thanks to that I decided to give it a try and start applying some TDD in the project that I'm currently working on, even though it's been already started.

These are the steps on how I did it and manage to start doing it:

How to start?

TDD, as the acronym says: Test Driven Development, which means: "first start writing your tests then your code". Easy to read, not so easy to apply, is it? Well... It's indeed really easy, why? If you start by defining what your feature should do it's only matter of copy-pasting the feature description/acceptance criteria and from there you have your tests already set.

Let's consider the following example:

From the feature description shown above, let's take the first requirement for this post's example:

The API will return relevant data for all the blocks as:

blocks/all

This is already giving us our first test to be written, the API should have a controller with the action to return all the blocks, it's also telling us how the response should be. Let's see how the test would look like:

it('returns all blocks /blocks', async () => {
    const mockResponse = [
      {
        height: 672498,
        hash:
          '00000000000000000007b619218d276894e8768876fd42f81131a98dc000da77',
        time: 1614472371,
      },
      {
        height: 672499,
        hash:
          '0000000000000000000c428a229a3c23d084cc800002faaff801a5c34edcd837',
        time: 1614473696,
      },
    ];
    jest.spyOn(service, 'findAll').mockImplementation(
      () =>
        new Promise((resolve) => {
          resolve(mockResponse);
        }),
    );
    const blocks = await controller.findAll();
    expect(JSON.stringify(blocks)).toBe(JSON.stringify(mockResponse));
  });

From the Acceptance criteria we know that it will return as response an array of objects containing the properties: height, hash, and time. (Don't be so strict with yourself by wanting the body of the test to be full defined, it's ok if you come and update it, with the time and practice it will be simpler).

Now that we have our test, let's go to the implementation of our controller's action:

  // The controller
  @Get()
  findAll() {
    return this.blocksService.findAll();
  }

  // The service
  findAll() {
    return this.httpService
      .get('https://blockchain.info/blocks?format=json')
      .pipe(map((response) => response.data))
      .toPromise();
  }

That's it. Now we have our Test, testing that our API is returning the expected result and the implementation of our controller returning what needs to be returned.

What are the benefits and key aspects?

First, we need to make sure our feature description is clear enough, so we can convert the requirements into Tests.

Second, once we have the tests we can start with the implementation and at the end of development we will have our code self tested. It's also good because we will be writing our code in the sense of accomplishing the acceptance criteria since the beginning, no patch, no violation of anything. As long as we have the requirement well defined our test and code will also be.

We need to make sure our feature description is clear enough

You might be thinking, I've never done a test in my life, this is going to slow me down; indeed, when starting it's going to be complicated, but as soon as you start you will have more material on how to better define your tests and make a faster progress, where you are securing your functionality to work and guarantee that there will not be any regressions.

Remember, practice makes perfect.

I hope you have enjoyed the article.

Thanks for reading!

Let's talk about releases...

Adán Carrasco — Sat, 13 Mar 2021 22:22:10 +0000

Releasing can be considered as the continue exposure of your project to the real world.

What you have been working on is about to be tested and used by people. Therefore it's really important that you have a good process on how you are going to deliver new features and bug fixes to your end users. Let's start by describing from a high level what is a release.

Following the diagram showed above, releasing is simple, right? Well...

There are certain pieces that are not described in the high level diagram, as:

Multiple browsers/OS
Screen sizes
Accessibility
Compatibility with different languages
Different type of users (roles)
Variation in configurations
One module affecting another one
Having some issues in production that block users from using important flows in your App
An assumption that turns out is affecting the performance (A/B Testing?)
Etc

Since any of the previously described scenarios can cause issues while releasing, there's the need of more than 5 bubbles/steps (described before) to act accordingly and prevent or address any disasters in the release process.

When you release your code to production unexpected behaviour can happen, the local simulation/test is never enough.

There are some techniques that have been applied by different companies trough the years. One of the most common is GitFlow. Which has the following high level structure:

GitFlow

High level explanation of GitFlow (here you can see more details)

Process:

Master branch (production ready state)
Release branch (the code to be released)

a. The release happens periodically (it can be every sprint, every X weeks, etc)
Feature branches (each developer creates a branch and merge to develop when ready)
Develop
HotFix (fixes that need to go to production as they are blocking some important functionality)

Keys:

Testing phase - A defined time to test and stabilise the code to be released
Master, release, hotfix, feature and develop branches
Tagging your releases (Git tags)

In this approach the release happens periodically, it's more in control and there's some period of code-freeze where the release candidate gets tested to be released. If something weird happens in the middle or after the release, bugs can be fixed as a hotfix or as part of the testing phase.

Trunk based development

High level explanation of Trunk based development (here you can see more details

Trunk based development will always be release ready

There's only one main branch
All the branches are feature branches and live max 2 days before they get merged into the trunk

Keys:

Continuous Integration (CI) - Is a technique to automate analysis in the code to be released
Continuous Delivery (CD) - After running the CI the new release gets deployed to either Staging or a Sandbox environment
Staging - It serves as a sandbox environment where the code can be tested before promoting it to production
Semantic versioning - Automatically calculate the version depending on the commits
Code Review - It's important that some guidelines and best practices are set in the project, so it can easily get reviewed by the team members, code review includes: reviewing the code to follow the those practices as well as checking it to be maintainable, readable and scalable, as part of a code review a Pull Request Template can help in speeding up the process
Short lived feature branches - Max 2 days living branches as they need to be merged quickly, less code, better reviews less impact/change of regressions
Tagging your releases (Git tags)

Not because there's only one branch that means that you will blindly commit and merge code. There are some principles that need to be followed.

As there's only one main branch it should be production ready state, to guarantee that or to minimise any side effects, more automation is required, where the effort is to verify as much as possible before releasing, to accomplish it there are several levels of automation:

Testing:

a. Unit
b. Integration
c. End to End
d. Load
Code analisys

a. Code quality
b. Security
Bumping version and tagging the release
Deployment

What's your team strategy?

Design System creation, from scratch to npmjs.com - Part 1

Adán Carrasco — Sun, 03 May 2020 21:41:16 +0000

Nowadays having a Design System is pretty common. It offers really good advantages: all your projects share the same components and you have a gallery where everyone can see them, even non technical people.

TLDR; I want my clone! 😬

In part 1, I will show you how to setup the project with React + TypeScript + Rollup.

By the end of this series you will have a Design System (DS) created using React + TypeScript + Rollup, and not only that; you will create a DS following Atomic Design methodology. If you are not familiar with Atomic Design don't worry about it, you'll get it by the end of this series.

Also your DS will be ready to be published to npm, this will allow you to import it in multiple projects and create your products faster than never. 😎

Prerequisites:

Have npm installed
Have a text editor, preferably VSCode
Optional: If you want to publish it, you'll need an npm account

Hands on:

Let's start giving this project some shape! I don't intent to do this series really tedious and containing a lot of things that it shouldn't, for that I will be explaining briefly the sections that are not mandatory to know (deeply) to setup the boilerplate. However, if you have any questions you can always drop a comment and I will reply any doubts you may have. 😃

Let's start! 💪

1. Create the project folder and init npm

Let's start by creating a folder for our Project. In our project's folder we do:

npm init -y

This command initializes an npm project for us with the default settings.

2. Installing the packages we need

Now let's install the packages we need. The following is the list of packages needed to setup the DS boilerplate. It includes packages to work with React + TypeScript (and compatibility with it), integrate testing using Jest + Testing Library, also includes the minimum packages to setup Rollup. As well as the minimum requirements to transpile our code to work with old browsers using Babel. Something we normally use in modern projects is a linter, for this we will use ESlint + Prettier, and to visualize our DS we will use Storybook. The last and optional tool is EmotionJS to do our components in a Styled Components way.

TypeScript: yarn add -D typescript
React: yarn add -D react react-dom @types/react
Rollup: yarn add -D rollup rollup-plugin-copy rollup-plugin-peer-deps-external rollup-plugin-typescript2 @rollup/plugin-commonjs @rollup/plugin-node-resolve
Testing: yarn add -D @testing-library/jest-dom @testing-library/react @types/jest jest ts-jest
For babel (transpiling): yarn add -D @babel/core babel-loader babel-preset-react-app identity-obj-proxy
EmotionJS (Styled Components): yarn add -D @emotion/core @emotion/styled babel-plugin-emotion
For Eslint and Prettier: yarn add -D eslint eslint-config-prettier eslint-plugin-prettier prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin
Storybook: yarn add -D @storybook/react

After installing the packages, we are set to start doing some configuration. ✨

3. Adding some scripts to run our project

Now in our package.json we need to put some scripts to let us build, test and visualize our components.

    "build": "rm -rf ./build && rollup -c",
    "lint": "eslint '*/**/*.{js,ts,tsx}' --quiet --fix",
    "storybook": "start-storybook -p 6006",
    "storybook:export": "build-storybook",
    "test": "jest",
    "test:watch": "jest --watch"

4. Setting up our packages configurations

All of the following need a configuration file to know how they should operate, depending on each project/team rules the config may change. For this example I will leave it as generic as possible, trying to affect the less I can. I will put at the beginning of the section the name of the config file for each of them.

Most of the properties in each config file are explained in the name of the prop, for some that are not obvious I will add a brief description at the end of the section. 😌

TypeScript

tsconfig.json

{
  "compilerOptions": {
    "declaration": true,
    "declarationDir": "build",
    "module": "esnext",
    "target": "es5",
    "lib": ["es6", "dom", "es2016", "es2017"],
    "sourceMap": true,
    "jsx": "react",
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "typeRoots": ["./node_modules/@types", "jest"],
    "types": ["jest"]
  },
  "include": ["src/**/*"],
  "exclude": [
    "node_modules",
    "build",
    "src/**/*.stories.tsx",
    "src/**/*.test.tsx"
  ]
}

In summary this file will transpile our TypeScript into JavaScript using as target: es5, will ignore some folders (exclude), and will configure things for testing (typeRoots), using jsx for React, building everything in build's directory.

Rollup

rollup.config.js

import peerDepsExternal from 'rollup-plugin-peer-deps-external'
import resolve from '@rollup/plugin-node-resolve'
import typescript from 'rollup-plugin-typescript2'
import commonjs from '@rollup/plugin-commonjs'

import packageJson from './package.json'

export default [
  {
    input: 'src/index.ts',
    output: [
      {
        file: packageJson.main,
        format: 'cjs',
        sourcemap: true,
      },
      {
        file: packageJson.module,
        format: 'esm',
        sourcemap: true,
      },
    ],
    plugins: [
      peerDepsExternal(),
      resolve(),
      commonjs(),
      typescript({ useTsconfigDeclarationDir: true }),
    ],
  },
]

This one is a little bit more extended, in this case we are telling rollup to use peerDepsExternal this means that if the project importing this DS already has installed the packages inside peerDepsExternal, they won't be included as part of this package (DS) import. It also setups the output format as CommonJS (csj) and ES modules (esm) (for older and modern browsers respectively). Using some plugins to do the transpilation for us.

Jest

jest.config.js

module.exports = {
  roots: ['./src'],
  setupFilesAfterEnv: ['./jest.setup.ts'],
  moduleFileExtensions: ['ts', 'tsx', 'js'],
  testPathIgnorePatterns: ['node_modules/'],
  transform: {
    '^.+\\.tsx?$': 'ts-jest',
  },
  testMatch: ['**/*.test.(ts|tsx)'],
  moduleNameMapper: {
    // Mocks out all these file formats when tests are run
    '\\.(jpg|ico|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$': 'identity-obj-proxy',
    '\\.(css|less|scss|sass)$': 'identity-obj-proxy',
  },
}

This file is defining the files we are going to test, the format and how we are going to call them (testMath + moduleFileExtensions), how jest should interpret them (transform), also includes the folders that should be ignored (testPathIgnorePatterns) and finally some files/resources that will/can be mocked (moduleNameMapper). It also contains additional setup so we don't need to add it in all of our tests.

jest.setup.ts

import '@testing-library/jest-dom'

ESlint + Prettier

.eslintrc.js

module.exports = {
  parser: '@typescript-eslint/parser',
  parserOptions: {
    ecmaVersion: 2020,
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
    },
  },
  settings: {
    react: {
      version: 'detect',
    },
    extends: [
      'plugin:react/recommended',
      'plugin:@typescript-eslint/recommended',
      'prettier/@typescript-eslint',
      'plugin:prettier/recommended',
    ],
    rules: {},
  },
}

Defines where the VSCode (in this case) will show you some errors, you can mix it up with TS Config to mark them as errors as well. In this file we have some recommended Lint rules for the tools we are using as React + TypeScript + Prettier.

.prettierrc.js

module.exports = {
  semi: false,
  trailingComma: 'all',
  singleQuote: true,
  printWidth: 100,
  tabWidth: 2,
}

This file is just matter of style for your code, if you want to use trailingCommas or not, singleQuotes for strings, your tabWidth, etc.

Storybook

.storybook/main.js

const path = require('path')

module.exports = {
  stories: ['../src/**/*.stories.tsx'],
  // Add any Storybook addons you want here: https://storybook.js.org/addons/
  addons: [],
  webpackFinal: async (config) => {
    config.module.rules.push({
      test: /\.(ts|tsx)$/,
      loader: require.resolve('babel-loader'),
      options: {
        presets: [['react-app', { flow: false, typescript: true }]],
      },
    })
    config.resolve.extensions.push('.ts', '.tsx')

    return config
  },
}

In this case we setup the name we will give to our stories (code where we will demo the usage of our components), the extensions and wether you are using Flow or TypeScript.

EmotionJS (Optional)

.babelrc

{
  "env": {
    "production": {
      "plugins": ["emotion"]
    },
    "development": {
      "plugins": [["emotion", { "sourceMap": true }]]
    }
  }
}

This is a small setup to tell our project how it will transpile our Emotion components.

End of part 1

In general all those config files have pretty much the same structure, it can be tricky at first but once you get familiar with the structure all of them are really alike.

I hope you enjoyed the first part of this series. IMO, the setup of the project is the more tedious, however the funniest parts are coming. 🎉

Thanks for reading, if you have any questions you can @ me in Twitter at @adancarrasco. See you in part 2!

How to implement i18n in your WebApp? Part 1

Adán Carrasco — Sun, 26 Apr 2020 18:20:14 +0000

One common denominator for Software is that it can scale, most of the time scaling comes with i18n (internationalization) and l10n (localization). This time, I'm going to show you a way on how you can implement those in your application. As i18n involves many layers I will split the posts in different parts. This part will cover the database.

What is i18n and l10n?

Internationalization better known as i18n, and localization better known as (l10n), is the part of Software where you handle the representation of your data/content depending on where it's consumed. As we know there are a lot of languages, and even in languages there are many variations.

Depending on your region, you may write: Localization or localisation; and internationalization or internationalisation.

Let's see it in an example:

Language	Region	Word	locale tag
English	United States	Internationalization	en_us
English	England	Internationalisation	en_gb

In the previous example, even tough the language is the same, depending on the region the writing might be different and in some cases the meaning will be different as well.

Or we can just simply support different languages:

Language	Region	Word	locale tag
English	United States	Hello	en_us
Spanish	Mexico	Hola	es_mx
German	Germany	Hallo	de_de

Now that we know the difference let's see how that can apply to Software.

Localizing Software

After reading and doing some research my personal conclusion is that there are two main areas in regards of localizing.

1. Your app's data

The first part is your data, and this is what you have in your database that can dynamically change, it can be the products you sell, the articles you have, jobs you offer, any description, etc.

Before i18n

job
id	uuid PK
posted_date	date
title	varchar(50)
description	varchar(250)

If we had the necessity to add one more language, keeping this structure, all of our data would be duplicated. For this we can extract common fields and create a translation_entity table.

Where our fields that doesn't need localization are:

job
id	uuid PK
posted_date	date

And our fields that need localization are:

job_translation
title	varchar(50)
description	varchar(250)

Then we need to add a couple of columns to link the translations with the localization.

job_translation
job_id	uuid FK
locale_id	uuid FK

After i18n

The final design for our localized database would be as follows:

Entity

job		sample data
id	uuid PK	1111-2222-3333-4444
posted_date	date	2020-26-04 19:52:44

Entity-Translation

job_translation		sample data
job_id	uuid FK	1111-2222-3333-4444
locale_id	uuid FK	4444-3333-2222-1111
title	varchar(50)	English teacher
description	varchar(250)	Teach the english language

Locales

locale		sample data
id	guid PK	4444-3333-2222-1111
ISO	varchar(5)	en-us

With this we will have unique data for each language our application will support.

In this example the columns to be localized are only two but if we had 10, 50, we will be saving a lot of space as well as performance and scalability will be reflected.

2. Your app's presentation

In the other hand, there's the part that is not involved in our data. This comes from the presentation layer, such as labels, texts, alt for images, etc. That part can easily be put in a single table (it can get complex as well depending on the needs, for now, let's keep it simple).

translation		sample data
id	uuid PK	3333-1111-2222-4444
locale_id	varchar(5) FK	4444-3333-2222-1111
locale_key	varchar(100)	homePage.welcomeMessage.h1
value	varchar(250)	Welcome to my awesome App

Ready to persist localized data

Separating your data in those two main layers will give you enough to have your App ready to scale in terms of different languages/regions.

This summarizes all regarding the database so you can translate your App. In the following posts I will be posting how to manage this data in the Application Layer as well as in the Presentation Layer.

How do you localize your apps? Do you know any other ways to do it? Feel free to share.

Thanks for reading!

Setup Firebase in React Native in 2020

Adán Carrasco — Mon, 13 Apr 2020 19:43:39 +0000

A couple of months ago I spent some time configuring a new React Native project to work with Firebase.

What is Firebase?

Firebase is a Google service which provides some services such as:

Hosting
Real Time Database
Authentication
Cloud Functions
AB Testing
Etc

This service is for free with some limitations, after the limitations you pay for what you use. However, this is really good for starting projects and pitch new ideas, one big advantage is that you don't need to write a single line for you BackEnd, unless you want to use the Google Cloud Functions but in this case, this is Serverless.

For the project that I was working on I needed a Database online where I could read some data, in this case I didn't need to update any data (for now), so I decided to use Firebase, I have used it before and the experience that I had was really good. I really enjoyed working with Firebase.

First of all you need to link your Google Account to your Firebase Account. After that you just create a project. You can follow up the steps here

Once you have your account make sure you select the Real Time Database and start creating a dummy JSON, otherwise you won't be able to get the data with the code samples that I will share later.

In this example I have a collection of users, in this case we only need one user to see how the data will be stored.

"users": {
  "hashId": {
    "birthdate": 12343255324,
    "deviceTokens": {
      "hashId": "jfskdl"
    },
    "email": "adan.carrasco@email.com",
    "facebookId": 123423123,
    "name": "Adan",
    "registerDate": 12343245234
  }
}

React Native

Now we have everything setup in the Firebase side, we go to the React Native getting started Site. I recommend you to follow the steps from react-native cli, it's a walk through to setup what you need in an easy way.

Common issues I had (follow this list before going to install Firebase dependencies)

Use npm instead of yarn
Forget to run yarn start before doing react-native run-ios
Forget to run pod install in the ios folder before react-native run-ios
Forget to install all the requirements for Android before running react-native run-android. The requirements are in the getting started page.
Install and go ahead adding packages for iOS when Android hasn't started (making parallel progress makes the life easier :) )
Forget to update my Android Studio before trying anything with Android

Now we are good to go an install the Firebase dependencies.

Installing Firebase dependencies

It's as simple as going to the React Native Firebase package maintained by Invertase.

iOS

For iOS is really easy you just need to follow the steps. Don't forget to copy the package from the project settings.

Android

For Android is a tricky one, you follow the steps described in the Website. However you need to copy the package name from your Android project opening Android Studio to generate the file correctly, otherwise it will throw errors. Now that you have done that you'll have some errors because the Gradle project is version 4.X and you need the 5.X. You can follow this Stackoverflow thread.

Now that you are using Gradle 5 you need to update the gradle.build configuration, following this Stackoverflow thread.

Now you are good to go, your Application should be running in both OSs.

If you have any issues you can ask me directly on Twitter, I will be happy to help!

Thanks for reading!

The one about CSS vs CSS in JS

Adán Carrasco — Mon, 06 Apr 2020 21:50:38 +0000

An interesting topic when doing Web Development and nowadays not only Web Development is choosing how your Application will be styled. In today's post I will be comparing some of the pros and cons in CSS as well as in CSS in JS.

What is CSS?

Cascading Style Sheets, is a technique to change the look and feel of your Web App, you do it using selectors (what rules you want your styled to be applied to), selectors can be via created HTML tags, ids, CSS classes, etc; once you have your selector you can set different props, as font color, background color, font family, etc.

One of the main advantages of CSS is that you can change the look and feel of many elements at once with a selector.

/* This rule will set the font-size and font-color 
as 12 pixels and orange to all the paragraphs in our whole application */
p {
  font-size: 12px;
  color: orange;
}

Now, what is CSS in JS?

Is nothing more that applying styling to your Components using CSS props via JavaScript, how this is possible? There are many ways, one it's adding inline styles (props) to your component.

// This will render a component (build with React) with the same 
// props as we defined in the previous code
const MyComponent = props => (
  <p style={{fontSize: '12px', color: 'orange'}}>hello</p>
)

Another way to do it is using a library as EmotionJS that will generate some CSS classes for you and will inject them into your Components.

// This will render a Styled Component with the same props 
// as the two previous examples

const MyComponent = props => (
  <MyStyledP {...props}>hello</MyStyledP>
)

const MyStyledP = styled.div`
  font-size: 12px;
  color: orange;
`

One of the main advantages of CSS in JS is that you have only the CSS your component needs, preventing any overrides and making it usable as a standalone piece of code.

CSS

Pros

The standard to change the look and feel in Web Development

In the old days was really hard to keep the same color for different components and was really easy to have a lot of duplicated CSS (when multiple developers were working in the same project). This was because there was no variables to persist non changing values and there was no easy way to reuse rules. Then it became the standard with the war of different browsers as Internet Explorer, Mozilla and then Chrome.

Can use preprocessors

Later preprocessors as LESS and SASS came to make the use of variables and reusing code possible, you could easily nest your inner selectors being wrapped by the main CSS class and also add some variables to it.

Good performance

Since it's and became the standard it's really easy for Web browsers to apply the styles, they have been doing it all the time. Also, the output code applied to the HTML elements is only the needed even tough the CSS code can contain non needed and non used code.

Applying a CSS theme/skin is easy

If you follow a good naming for your selectors and the use of namespacing, will be really easy to come with a different theme and apply it to your Web App.

Cons

Naming is hard, unless you follow BEM or similar

As CSS became the standard, patterns to apply a good CSS styling became popular, one of those is BEM (Blocks, Elements and Modifiers), following this out class name generated will be something like:

/* block--element-modifier */
.button--state-success {
  /* here you put your css rules */
}

Easily to commit typos and override props, which leads to use !important in some cases

There's a high possibility that as developers we will have typos in our code, and there's a high possibility that someone will redefine an existing CSS class, and the one at the end will be the winner, unless someone uses !important which is really nasty.

Dead code risk (dead rules) and hard to maintain

If in the Dev Team there's not strict rule on removing unused code more and more CSS will be created, and depending on the way you use to create more CSS files the harder will be to detect where you need to cut/remove the unused code, this also makes it hard to maintain

Need to worry about compatibility with browser's CSS extensions

If you are managing CSS manually you need to worry about different CSS extensions as: -moz, -webkit, -ms

CSS in JS

Pros

Uses CSS which is the standard

So you don't need to learn anything new to style your components since you've been using CSS all the time.

No need to worry about naming or overriding of props

You don't need to worry about overrides because the CSS used in your component lives in your component only.

Using frameworks as EmotionJS generates browser specific extensions as -webkit, -moz, etc

When using pure CSS you need to worry about the specific browser extensions, however when using this pattern, the library does that for you, generating any of them, this is a relief because you know that as long as the library is supported by the browser, the rules will be available.

Easy to maintain

As the CSS is in the component only it's easy to remove the CSS you no longer need. Also if your component needs some specifics you can modify those specifics depending on the use case passing the variants as props. And the best, if the component is no longer needed you only remove it and that's it. NO SIDE EFFECTS!

Cons

Performance may be affected because of the computation to inject the CSS

Since every component has its own CSS rules the JS bundle can easily grow, and in the other hand the JS needs to be processed by the browser to apply the CSS while in the other hand (using CSS only) the CSS is ready almost at the same time as the HTML components.

Hard to reuse rules

The rules applied to your components are only living in your components, this makes it really hard to reuse the rules you apply to your component to other components. However, if you are using this pattern, doesn't necessarily mean that you cannot use CSS, so mixing both approaches can solve this issue. :checkmark:

Applying some themes, skins may be more complicated but can be generated from a JSON which could be as

Applying themes when using this technique at some point could be harder compared to using CSS only, however if you have a good architecture and a good definition on how you want to use your CSS in JS you can easily spread the props from the parent component to the most inner component. Plus you can use some of the CSS variables advantages. 😉

Is it still CSS? Cascading is lost

IMO the most important paint point is that Cascading is lost and this means you cannot have a CSS in JS that will apply to a nested component, well you can, but you will be violating the principle of this technique which is independence in your components. This loss makes a lot of noise when deciding wether to use or not this technique.

Conclusion

As a personal conclusion I don't think there's a best option, it will depend in your project needs. However, nowadays I'm combining the two approaches making one stronger when the other is weak. I can use CSS variables and apply it to my Components and isolate in the Components what needs to be isolated, just as I would do it using namespacing.

When would you use one or the other?

Thanks for reading!

10 chapters in the story of git and a feature implementation

Adán Carrasco — Sun, 29 Mar 2020 17:32:36 +0000

When we talk about version control in Software Development, (in most of the cases) the first concept that pops to our minds is Git.
In Today's post I will share a story that will save you a lot of time and will give you a better understanding on how git works.

One way to go is to use a visual tool that could help you doing what those commands will help you doing, however, in most of the cases you end up clicking a lot to do what could have been done in a single line.

Let's picture the scenario where we want to implement the functionality for the User Service:

1. Creating branch for our feature

The first thing to do when you are about to develop a new feature is to create a new branch to track the changes for your amazing feature/bug.

git checkout -b feature/user-service-implementation

Tip: prepend feature or bug to describe your branch's content :wink_face:

2. Committing your changes (this comes as 2x1)

A good practice when working with git is to commit your changes often and in chunks, in a way that you can easily revert changes.

For one line commit message:

git commit -m "Add User service files and initial setup"

For more than one line commit message:

git commit

But before committing your changes you must add the file changes:

To add all the modified/added files:
git add .

To add specific files or directories (specify the path to the directory or file in case you only want to add a file)
git add user/service/

3. Exploring and reading historically other commits in the current branch

You may have already committed a bunch of things and you want to know wether you included a chunk or not. There's a shortcut to look at the commits have been already done. Some sort of history:

git log

4. Show me the contents of a specific commit

With the previous command you get the list of commits that have been made to your repository, but what you don't see is the content of those commit changes. To see them you just ask for them:

git show desired_commit_hash_goes_here

5. Crap, I want to undo my commit

At this point of time you've already seen the commit that you weren't ready to include. How can you easily revert it? Well, you ask for it. :)

git revert desired_commit_hash_goes_here

6. About changing branches

Let's take a breath and learn a command that will help us in the next set of steps. The breath is about learning how to switch between branches. You simply do:

git checkout my-desired-branch-name

7. How to copy-paste commits

For the cases where you want to move one or more commits to other branch not affecting the git history and workflow you have an option too. Let's say you committed some changes for the UserController but you weren't supposed to do that because your current branch is for the User Service. With cherry-pick command you can move this commit to another branch, let's do it.

First, you need to get the commit hash that you want to move (cherry-pick)
git log

Second, once you have identified that commit or commits you take note of the hashes, because you'll need them to tell git what you want to move.

Third, you now go to the desired branch by doing:
git checkout feature/user-controller-implementation

Fourth, now in this branch we simply do:

git cherry-pick desired_commit_hash_goes_here

You do cherry-pick for every commit you want to move

Then you go back to your working branch by doing git checkout one more time:

git checkout feature/user-service-implementation

8. Call to get remote changes

At this point we are done with the code to implement our feature and we are ready to create a Pull Request. However, there's a possibility that while we were implementing our changes someone else made some changes in our source branch. To verify we do:

git fetch

This will list any changes done in remote; can be any new added branches or changes to our source branch (typically develop).

9. Bring the latest changes on

If there are some changes we need to bring them to our local. To do that we checkout to our desired branch then we do:

git pull

10. I'm ready to merge

This command will merge from any specified branch to your current working branch. You'll see it in action in the Bonus section.

git merge merge_from_this_branch_name

Bonus: getting the latest from develop/master branch into your current working branch IN ONE LINE.

git checkout develop; git pull origin develop; git checkout feature/user-service-implementation; git merge develop;

Those are the most common git commands I use in my day to day life as a Software Engineer. I prefer to know the commands so I don't depend on any visual tools. With this all I need is git installed and that's it. I'm ready to go and to work. And as most of the time my fingers are in the keyboard it saves a lot of time for the most common tasks done when working with git.

What are your most common git commands?

Thanks for reading!

Autogenerate Forms from JSON using React

Adán Carrasco — Sun, 22 Mar 2020 23:21:50 +0000

TLDR; Please take me to the code sample

During the last two years I have been working in different projects and the need of creating different forms has been a common denominator. Today I will share a way to create Forms from a JSON configuration. There are many reasons why you would need a Form generator:

Your application requires a lot of forms
Depending on the user locale you show or not items in the forms
The user data you need to get depends on some configuration such as role, type of user, etc
Yours

For this to be possible, the generation of the forms will be based on a JSON config object that we will pass to our Form component so we create any combination of forms.

In this example I will not get deep into different input types but it should give you the basis, then you could include more types depending on the requirements. For now, this example shows how to generate forms with <input /> in any type.

Would be a good exercise for you to implement the <select> for example. 😎

Let's start by adding the libraries we are going to use:

react
formik

And optionally we can add:

You can create your PoC in https://codesandbox.io

Now that we have added the libraries we start by creating a generic FormField component which will be rendered by every field we want to generate.

Form field



import React from "react"
import { useField, FieldInputProps } from "formik"
import { Grid, TextField } from "@material-ui/core"

export interface FormFieldProps extends FieldInputProps<""> {
  name: string
  type: string
  label: string
}

const FormField: React.FC<FormFieldProps> = ({
  label,
  ...props
}: FormFieldProps) => {
  const [field, meta] = useField(props)
  return (
    <Grid container>
      <TextField label={label} {...field} {...props} />
      {meta.touched && meta.error ? (
        <div className="error">{meta.error}</div>
      ) : null}
    </Grid>
  )
}

export default FormField

This will render something like:

Generic form

Now that we have our first generic component we can create our GenericForm which will render the FormField components depending on the configuration.



import React from "react"
import { Form, FormikProps, Formik } from "formik"
import { Button, Box } from "@material-ui/core"

import FormField from "../FormField"
import { FormFieldProps } from "../FormField/FormField.component"

const GenericForm: React.FC<any> = props => {
  const { fields, submitClickCallback } = props.formDefinition
  return fields ? (
    <Formik
      initialValues={{}}
      onSubmit={(values, actions) => {
        submitClickCallback(values)
        actions.setSubmitting(false)
        actions.resetForm()
      }}
    >
      {(props: FormikProps<any>) => (
        <Form>
          {fields.map(({ name, type = "text", label }: FormFieldProps) => (
            <FormField key={name} name={name} type={type} label={label} />
          ))}
          <Box mt={3}>
            <Button type="submit" variant="contained" color="primary">
              Submit
            </Button>
          </Box>
        </Form>
      )}
    </Formik>
  ) : null
}

export default GenericForm

In this case the button is set by default, but you could also set the number of buttons from your configuration.

JSON data structure

Now that we have our GenericForm and our GenericField let's see how our JSON config structure would look like...



const formDefinition = {
  fields: [
    {
      name: "firstName",
      label: "First name"
    },
    {
      name: "lastName",
      label: "Last name"
    },
    {
      name: "email",
      type: "email",
      label: "E-mail"
    }
  ],
  submitClickCallback: (values) => {
    // our callback
  }
};

At this point we have everything we need to generate forms based on the config file. To generate forms we would only need to render our <Form /> component and pass the JSON object so it generates the form for us.

If we injected this JSON to our <Form /> component the layout would look something like:

Creating an example

Let's start by creating one example:



import React from "react"

import { store } from "../../App"
import Form from "../Form"

interface FormProps {
  firstName: string
  lastName: string
  email: string
}

const formDefinition = {
  fields: [
    {
      name: "firstName",
      label: "First name"
    },
    {
      name: "lastName",
      label: "Last name"
    },
    {
      name: "email",
      type: "email",
      label: "E-mail"
    }
  ],
  submitClickCallback: (values: any) => {
    store.dispatch(userSlice.actions.addUser(values))
  }
};

const UserForm = () => <Form formDefinition={formDefinition} />

export default UserForm

In this example we are creating a <UserForm /> component, however this component is not required, you could have the form rendered in a Page/Screen by doing <Form formDefinition={myJsonDefinition} /> that would be enough for you to render your form.

Then you could have some logic on your backend to return the JSON config based on the user's variables, as mentioned before: locale, different role, etc.

What else would you add to the form generator?

You can play with this project in: Form generator where I added Redux and also used the @reduxjs/toolkit

Thanks for reading!

5 tips to improve your React and JS code

Adán Carrasco — Sun, 15 Mar 2020 21:50:50 +0000

Two weeks ago I started to work in a new project where some code was already written. However, there wasn't any best practices to follow. Something that matter when you start a new project is to get together to define the foundations and best practices/guidelines the team will follow to do the best code: Maintainable, readable, easy to understand.

I'm going to describe 5 scenarios that I saw in the project and how those can be improved.

Keyword for this is: Consistency

1. Order of import modules

Arranging your ES6 modules in an organized way will save you some time while trying to find any missing/not needed modules.

Before

import { DatePicker } from '../../components'
import axios from 'axios'
import { IUser } from '../../models/User'
import React from 'react'
import { toCamelCase } from '../utils'
import { Button } from '@material-ui/core'

After

// node_modules
import React from 'react'
import { Button } from '@material-ui/core'
import axios from 'axios'

// Local modules
import { DatePicker } from '../../components'
import { toCamelCase } from '../utils'

// Types + Interfaces
import { IUser } from '../../models/User'

In the Before we can see that the packages are unordered, probably for one file wouldn't make too much noise, but when you open a ton of files and try to look for a specific package is really hard to do it. Something that the team has agreed on is to group the imports in the After way, separating each module by an empty line. The comments can be removed since the files will be consistent.

2. Using destructuring whenever is possible

Another important thing is to prevent unnecessary nesting and repetition. In most of the cases this will improve readability a lot.

Before

const UserProfile = props => (<div>
    <span>{props.firstName}</span>
    <span>{props.lastName}</span>
    <img src={props.profilePhoto}/>
  </div>)

After

const UserProfile = ({ firstName, lastName, profilePhoto }) =>
  (<div>
    <span>{firstName}</span>
    <span>{lastName}</span>
    <img src={profilePhoto}/>
  </div>)

3. Naming convention for variables and methods

Something important about code is to know what a method will return or also easily read what a variable represents just by its name, for example:

Before

let User = {}
User.car = true
User.admin = true

function NewUser() {
  return User
}

function add_photo(photo) {
  user.photo = photo
}

After

let user = {}
user.hasCar = true
user.isAdmin = true

function getUser() {
  return user
}

function setUserPhoto(photoUrl) {
  user.photoUrl = photoUrl
}

In After we are keeping consistency on how to name variables and methods, being consistent in:

For booleans use: is, has, should prefixes
For methods use get/set prefix if are for props
Overall use camelCase for methods and variables

4. Make your components prepared for common props

Before

const UserProfile = props => {
  const { firstName, lastName, profilePhoto } = props
  return (<div>
    <span>{firstName}</span>
    <span>{lastName}</span>
    <img src={profilePhoto}/>
  </div>)
}

After

const UserProfile = props => {
  const { firstName, lastName, profilePhoto, ...rest} = props
  return (<div {...rest}>
    <span>{firstName}</span>
    <span>{lastName}</span>
    <img src={profilePhoto}/>
  </div>)
}

In the After, the component is prepared to inject common React properties such as: style, className, key, etc. Using the spread operator you are grouping all common props and passing them to the container.

5. Really dumb components will make your life easier

Creating dumb components and following the Single Responsibility Principle allows you to create and contribute in an easily way and keep a clean codebase.

Before:

import axios from 'axios'

const UserProfile = props => {
  const [user, setUser] = React.useState(null);
  React.useEffect(() => {
    getUser();
  }, []);

  async function getUser() {
    try {
      const user = await axios.get('/user/25')
    } catch(error) {
      console.error(error)
    }

    if(user.country === "DE") {
      user.flag = "/de-flag.png"
    } else if(user.country === "MX") {
      user.flag = "/mx-flag.png"
    }
    setUser(user);
  }

  const { firstName, lastName, profilePhoto, userFlag} = user

  return (<div>
    <span>{firstName}</span>
    <span>{lastName}</span>
    <img src={profilePhoto}/>
    <img src={userFlag}>
  </div>)
}

After:

What can cause issues?
Adding Business Logic (BL) inside a component can make it hard to maintain, debug and test. My recommendation is to keep your component as presentational component. In this way you isolate the BL and you can focus on testing that part independent. Previously everything was mixed. Now we have separated each responsibility, which makes it easy to test and debug.

// UserProfilePage.jsx
// Does everything related to the UserProfilePage, adding any additional props or BL
import { fetchUser } from '../api'

const UserProfilePage = props => {
  const [user, setUser] = React.useState(null);
  React.useEffect(() => {
    getUser();
  }, []);

  async function getUser() {
    const user = fetchUser(error => console.error(error))
    if(user.country === "DE") {
      user.flag = "/de-flag.png"
    } else if(user.country === "MX") {
      user.flag = "/mx-flag.png"
    }
    setUser(user);
  }
  return <UserProfile {...user}/>
}

// API.js
// Fetches the data and handles errors on that. That's it
export const fetchUser = async (errorHandler) => {
  try {
    const user = await axios.get('/user/25')
  } catch(error) {
    errorHandler(error)
  }
}

// UserProfile.jsx
// Displays the UserProfile and that's it

const UserProfile = props => {
  const { firstName, lastName, profilePhoto, ...rest} = props
  return (<div {...rest}>
    <span>{firstName}</span>
    <span>{lastName}</span>
    <img src={profilePhoto}/>
  </div>)
}

Bonus: If you are using a type-checker, make it count.

In case your team chooses to use a type-checker it's really important that you become strict and use it to ensure it's covering and serving for the purpose it was decided to use it.

Before:

const UserProfile = (props: any) => {
  const { firstName, lastName, profilePhoto, shouldShowPhoto } = props
  return (<div>
    <span>{firstName}</span>
    <span>{lastName}</span>
    <img src={profilePhoto}/>
  </div>)
}

After:

interface IUserProfile {
  firstName: string
  lastName: string
  profilePhoto: string
  shouldShowPhoto?: boolean
}

const UserProfile = (props: IUserProfile) => {
  const { firstName, lastName, profilePhoto, shouldShowPhoto } = props
  return (<div>
    <span>{firstName}</span>
    <span>{lastName}</span>
    {shouldShowPhoto && <img src={profilePhoto}/>}
  </div>)
}

I'm not saying these rules apply for all the projects but your team should be able to define them and agree on that.

Which best practices/guidelines do you use?

Can you help me to improve my Functional Programming skills?

Adán Carrasco — Sun, 08 Mar 2020 21:21:06 +0000

This weekend I wanted to refresh what I knew about Functional Programming. I read and took some notes about it, (feel free to add your thoughts in the comments section):

The theory:

There are some principles in regards of FP:

FP uses Pure Functions: Functions that its return depends on its input, for example:
- Math.floor(16) --> 4 // This function will always return 4 when it's called with 16
- Math.square(2) --> 4 // Same for this function
To contrast Impure functions:
- function() { return x; } // In this case this function will return the value of X but doesn't depend on any input, and will depend on X mutation
Do one thing well:
- Functions that are divided into smaller functions, that are divided into smaller functions until the smallest function does one thing but does it well
Small testing, since the functions are really small it's easy to keep them tested, rather than trying to test really big functions
Immutable data/state, each function should return a new object. Those object data structures are: [] or {}, Arrays or Maps
- In terms or performance it's not affected because the compiler most likely knows that non changed values will have the same hash (not get to deep into this)
- Using immutable data reduces bugs because the new object is the result of your called function, making easy to have different states across time for your data, for example:
  - emptyCar = createCar();
  - carWithOneBook = addBookToCar(emptyCar, myBook)
  - carWithTwoBooks = addBookToCar(carWithOneBook, myOtherBook)
- In the previous example it's easy to do time travel because your objects are independent one to the other, so you know that if the addBookToCar works well, it'll work well in all the cases, plus testing that function will be easy as well.

The practice

A while ago I was in a phone interview, the interview was split in two sections: Technical questions + Coding Challenge. I solved the challenge applying what I learned from this FP weekend.

Coding Challenge

Part 1:

Given an object with the keys in kebab-case, convert the keys into camelCase.

Part 2:

Do it for nested objects.

Sample object:

const userData = {
  "first-name": "John",
  "last-name": "rough",
  "social-security-number": 9083910,
  "pets-details": {
    "cats-details": {
      "how-many-cats-are": 3,
      "cat-data": [
        {
          name: "Charlie",
          age: "8 months",
          "hair-color": "red"
        },
        {
          name: "Angel",
          age: "2 years",
          "hair-color": "white"
        }
      ]
    }
  }
};

I divided the problem into two. First...

Convert a string from kebab to camelCase, the functions created below are returning a new object, are simple, and do one thing well:

// Create a function to split a word into arrays by a char
const splitStringByChar = (key, char) => key.split(char)

// Create a function to capitalize an array of strings
const capitalizeArray = stringsArray => 
  stringsArray.map(key => key[0].toUpperCase() + key.substring(1, key.length))

// Create a function to join an array
const joinArray = stringArray => stringArray.join("")

// Create a function to lowerCase the first letter of a string
const lowerCaseFirstLetter = key => key[0].toLowerCase() + key.substring(1, key.length)

// Now run it altogether
const camelCaseString = toCamelCase => {
  const splittedKey = splitStringByChar(toCamelCase, "-")
  const capitalizedArray = capitalizeArray(splittedKey)
  const joinedKeys = joinArray(capitalizedArray)
  const lowerCasedFirstLetter = lowerCaseFirstLetter(joinedKeys)
  return lowerCasedFirstLetter
}

And second... a function to convert the object to camelCase:

// Create a function to convert the object to camelCase

const convertToCamelCasedObject = obj => {
  // Create the new object to be returned
  let camelCasedObj = {};
  Object.keys(obj).map(key => {
    const newKey = camelCaseString(key)
    // Checking if the object is an object and needs to be converted as well
    if (typeof obj[key] === "object") {
      camelCasedObj[newKey] = convertToCamelCasedObject(obj[key]);
    } else {
      // Pointing the value to the new object[key]
      camelCasedObj[newKey] = obj[key];
    }
    return camelCasedObj;
  });
  return camelCasedObj;
};

Conclusion

FP is good to change the way that you think or solve problems, by design it's good for Distributed Systems.

What would you change to make it better/simpler? What would you add about FP?

Thanks for reading!

Scaling atomic design with React

Adán Carrasco — Thu, 05 Mar 2020 22:00:29 +0000

Some time ago I heard for the first time about Atomic Design, the name sounded catchy, however I didn't spend too much time on researching about it, months later I joined a Team where was used. Same situation, heard about the concept again, read a little bit and understood the basics.

I'm not going to explain in detail Atomic Design (AD) in this post, however, I recommend you to take a look at this post. It explains in detail how and why AD is a good approach.

If you read the article mentioned above you should recognize the following parts of AD, and you can jump to the Design System section, otherwise, here is a summary of AD concept:

Atoms

The smallest representation of something in your project. For example, a custom anchor <a/>.

Molecules

A set of Atoms, for example: A label and an input tag together.

Organisms

A set of Molecules, for example: A form, which is a set of labels, inputs and buttons

Templates

A set of organisms, molecules and/or atoms, this is the skeleton of our future page, but only as a skeleton, no data should be used here.

Pages

The use of a template but with data, if you are using Redux in can be with data coming from the Redux Store, if you are using GraphQL it can be with data coming from your GraphQL, etc.

Design System

Now that you have a better understanding of AD, let's see how we can use it to create our Design System (DS). We can see a DS as a set of components/framework that we can combine to generate any pages that we need for our application. For example, Bootstrap has a set of components that can be used to create any page. However, we want our DS to be smarter and more scalable than Bootstrap.

Our DS doesn't need to be ready before we start creating our React + Redux application. It can have the basic components and be growing as it needs, of course you need to have all the elements of the page that you want to create. :)

Let's say we are going to create a Twitter App. I'm going to put some samples of each of them so the post doesn't get too big.

Atoms:

Text
Button

Molecules:

Icon + Text
Set of Buttons

Organisms:

Tweet (composed by Text, Icon + Text, Image, Link, IconButton)
Trending List

Template:
Taking as an example the template for the list of posts in a Profile Page in Twitter.

Page:
The Template with data filled.

But, how this looks in code?

Our folder structure will be like:
(This is in our DS so we can re-use it in different projects and keep the same look and feel)

Atoms
Molecules
Organisms

This is our project implementation

Templates
Pages

Templates are defined as a set of Atoms, Molecules and Organisms, mainly dumb components, however there are some cases where the Organisms need to have some state (internal state), as selected in the case of a Checkbox set, shown in the case of a Modal, but the state that they handle is not specific for its implementation.

// Template example
import React from 'react'

// We import from our Design System package the A-M-O elements that we need for our Template
import { ProfileHeader, LinkList } from 'my-design-system'

// We import from our local project the connected components to be used in this specific project
import { ConnectedPost } from './containers/ConnectedPost'

// This is our ProfileTemplate component definition, has nothing more than the skeleton
const ProfileTemplate = props => (
    < {...props} >
      <ProfileHeader {...profileHeaderProps}/>
      <LinkList {...linkListProps}>
      <ConnectedPost {...postProps}>
    </>
)

export default ProfileTemplate

Pages are Templates with data, this means we connect the Redux Store to them (in this use case), we can have connected components inside of the Templates so they can handle its own internal state and update accordingly.

// Page example

import React from 'react'
import { connect } from 'react-redux'

import ProfileTemplate from './Templates/ProfileTemplate'

const ProfilePage = props => (
    <ProfileTemplate {...props}/>
)

const mapStateToProps = {
    // our state to props implementation
}

const mapDispatchToProps = {
    // our dispatch to props implementation
}

export default connect(mapStateToProps, mapDispatchToProps)(ProfilePage)

The big advantage of using AD is that you can make your Apps look and feel the same, and that every change that you make in a component will be spread across your other projects, not needing to update them independently and having to maintain them, if it works in one project it should work in all of them, however, if it's broken it'll be broken in all the pages, luckily we have Unit Testing, E2E and CI/CD as tools to ensure all of this is working before deploying a new version.

Thanks for reading!