Forem: Diego Silva

🇧🇷 | Hierarquia de imports

Diego Silva — Tue, 29 Jun 2021 13:14:15 +0000

deixando os seus imports mais elegantes e organizados - Parte 02

Hoje continuaremos falando sobre como deixar os nossos imports mais elegantes e organizados. Para isso, precisamos falar sobre hierarquia de importações.

O que é hierarquia de importações?

Como o próprio nome já esclarece, hierarquia de importações é a ordem de prioridade das dependências importadas no nosso código.

É muito comum que os nossos arquivos .js e .jsx importem muitas bibliotecas, componentes, páginas, controllers, services, helpers, estilos, ou seja, uma infinidades de tipos de arquivos e dados distintos.

O exemplo abaixo é muito comum no cotidiano de um desenvolvedor front end:

import React, { useState, useEffect } from 'react';
import Button from '~/components/Button';
import { Container } from './styles.js';
import Card from '~/components/Card';
import PropTypes from 'prop-types';
import { combineReducers } from 'redux';
import Main from '~/pages/Main';
import Dashboard from '~/components/Dashboard';
import Home from '~/pages/Home';
import Routes from '~/routes';

function ExampleComponent() { ...

Olhando para o código acima você pode se questionar: "Não vejo nenhum problema nesse código".

E de fato, não há. As dependências necessárias foram importadas e estão prontas para serem utilizadas.

Mas, se podemos deixar mais organizado, por quê não?

Abaixo eu mostro o mesmo exemplo, só que mais organizado:

import React, { useState, useEffect } from 'react';
import { combineReducers } from 'redux';

import PropTypes from 'prop-types';

import Home from '~/pages/Home';
import Main from '~/pages/Main';

import Button from '~/components/Button';
import Card from '~/components/Card';
import Dashboard from '~/components/Dashboard';

import Routes from '~/routes';

import { Container } from './styles.js';

function ExampleComponent() { ...

No exemplo acima, eu ordenei as importações da seguinte forma:

em primeiro lugar: todas as dependências que eu considero as mais importantes da minha aplicação. Por exemplo, todas as que iniciam com 'react' e 'redux'
em seguida, todas as outras bibliotecas e módulos instalados no package.json. Por exemplo, Prop Types, Storybook, Unform, entre outros
depois, todos os arquivos internos, que iniciam com o alias ~/ ou @. Por exemplo, ~/components, ~/pages, ~/styles, @controllers, @models, entre outros. No post Import paths personalizados e como isso pode te ajudar eu mostro como podemos criar e configurar import paths personalizados para facilitar as importações da nossa aplicação
então, as rotas da minha aplicação
e por último, os meus estilos. Nesse caso, arquivos com o nome .styled.js

// primeiro, tudo que começa com 'react' e 'redux'
import React, { useState, useEffect } from 'react';
import { combineReducers } from 'redux';

// depois, todos os módulos e bibliotecas importadas
import PropTypes from 'prop-types';

// depois, tudo o que inicia com um alias '~/pages' ou '@pages'
import Home from '~/pages/Home';
import Main from '~/pages/Main';

// depois, tudo o que inicia com um alias '~/components' ou '@components'
import Button from '~/components/Button';
import Card from '~/components/Card';
import Dashboard from '~/components/Dashboard';

// então, as minhas rotas
import Routes from '~/routes';

// e por último, os meus estilos
import { Container } from './styles.js';

function ExampleComponent() { ...

É claro que manter essa hierarquia para todo o nosso código gasta muito tempo, atenção e cuidado.

Mas ainda bem que podemos automatizar essa tarefa, não é mesmo?

Conhecendo o eslint-plugin-import-helpers

O eslint-plugin-import-helpers é um pacote que foi criado pelo Will Honey, e tem como objetivo complementar o eslint-plugin-import. Ele trás um caso de uso muito importante que ainda falta no eslint-plugin-import: a ordem das importações.

Sobre o `order-imports` e como ele funciona

O eslint-plugin-import-helpers trás (até a data desse post) apenas o plugin order-imports. Esse plugin permite que seja possível configurar uma hierarquia de importações com apenas uma simples configuração arquivo .eslintrc.js.

Fazendo acontecer

Antes de tudo, você precisará ter no seu projeto o ESLint e o Prettier configurados. Se por acaso você ainda não configurou, sugiro que siga esse turorial:

Após a instalação e configuração do ESLint e Prettier, podemos seguir com os próximos passos.

Instalando e configurando o `eslint-plugin-import-helpers`

Na raiz do nosso projeto react, vamos instalar o puglin:

yarn add -D eslint-plugin-import-helpers

Agora, vamos configurar a regra import-helpers/order-imports no arquivo .eslintrc.js:

// .eslintrc.js
rules: {
  'import-helpers/order-imports': [
    'warn', // exibe um alerta no editor
    {
      newlinesBetween: 'always', // insere uma linha em branco após cada grupo de prioridade
      groups: [
        ['/^react/', '/^redux/'], // primeiro grupo: tudo que inicia com 'react' e 'redux'
        '/styled-components/', // segundo grupo: tudo o que for importado diretamente da biblioteca styled-components. Isso é para garantir que a primeira importação nos arquivos styles.js seja sempre a do styled-components.
        'module', // terceiro grupo: tudo que é um módulo (qualquer biblioteca listada no arquivo package.json)
        '/prop-types/', // quarto grupo: a importação do prop-types
        '/^~/pages/', // quinto grupo: todas as minhas páginas
        '/^~/components/', // sexto grupo: todas os meus componentes
        ['parent', 'sibling', 'index'], // sétimo grupo: qualquer arquivo pai, irmão ou filho do arquivo atual
        '/routes/', // oitavo grupo: as minhas rotas
        '/^~/', // nono grupo: todos os outros arquivos importados pelo alias configurado
        '/styles/', // último grupo: os meus estilos
      ],
      alphabetize: { order: 'asc', ignoreCase: true }, // configura as importações por ordem alfabética (crescente), ignorando maiúsculas e minúsculas
    },
  ],
}

Tudo pronto!

Se você configurou o prettier para corrigir automaticamente sugestões de melhorias do ESLint, sempre que essa hierarquia não for respeitada, o VSCODE irá reorganizar os imports automaticamente assim que o arquivo for salvo.

Se quiser ver esse exemplo na prática, você pode dar uma olhadinha no template que eu criei para projetos React aqui:

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

Lá eu já configurei o ESLint, Prettier e outras coisas para facilitar a estrutura inicial do seu projeto.

Comenta ai o que achou :)

🇧🇷 | Import paths personalizados e como isso pode te ajudar

Diego Silva — Tue, 29 Jun 2021 12:53:20 +0000

deixando os seus imports mais elegantes e organizados - Parte 01

Se existe uma dor que me incomoda quando estou desenvolvendo uma aplicação com muitos arquivos, é quando esses arquivos importam outros arquivos, e isso provoca um excesso de ../ nos imports desses arquivos.

É comum vermos que a medida que a nossa aplicação vai crescendo, as pastas dos arquivos do nosso projeto vão se aninhando cada vez mais dentro de outras pastas, e quando menos esperamos nos deparamos com o seguinte exemplo de import:

import ExampleComponent from '../../../../../../src/components/ExampleComponent/'

O exemplo acima é real e é muito mais comum do que imaginamos. Infelizmente o uso excessivo desses ../ traz algumas dores no momento em que precisamos dar manutenção ao nosso código, dentre elas, o retrabalho de consertar o caminho relativo toda vez que precisamos alterar o local de um arquivo importado ou do arquivo importador.

Uma das formas mais simples de deixarmos esse import mais elegante e organizado é criando um path personalizado e deixando-o como absoluto. Dessa forma, o exemplo acima poderia ficar assim:

import ExampleComponent from '~/components/ExampleComponent/'

No exemplo acima, o prefixo ~ foi configurado como um caminho absoluto de um diretório do nosso projeto, nesse caso o diretório é a pasta src. Dessa forma, não importa em qual pasta o nosso arquivo esteja, quando utilizarmos o prefixo ~/, sempre estaremos importando o path absoluto da pasta src.

Bem louco né?!

Fazendo acontecer

Instalando as dependências necessárias

Antes de tudo, precisaremos instalar e configurar três dependências para que essa mágica funcione. E elas são:

react-app-rewired e customize-cra

Na raiz do nosso projeto, vamos executar o comando abaixo para personalizarmos as configurações do webpack sem a necessidade de utilizar o eject e sem a necessidade de criar um fork do react-scripts.

yarn add -D react-app-rewired customize-cra

babel-plugin-root-import

Agora vamos executar o comando abaixo para importarmos arquivos usando paths personalizados.

yarn add -D babel-plugin-root-import

Criando o 'config-overrides.js'

Também na raiz do nosso projeto, criaremos um arquivo chamado config-overrides.js. Ele será o responsável por estabelecer a pasta raiz do nosso projeto.

Vamos inserir esse código no arquivo:

const { addBabelPlugin, override } = require('customize-cra')

module.exports = override(
  addBabelPlugin([
    'babel-plugin-root-import',
    {
      rootPathSuffix: 'src',
    },
  ])
)

Facilitando a vida do dev editor

Ainda na raiz do nosso projeto, criaremos um arquivo chamado jsconfig.json. Ele será o responsável por fazer com que o VSCODE entenda os paths personalizados.

Vamos inserir esse código no arquivo:

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "~/*": ["*"]
    }
  }
}

Últimos detalhes

Por último, atualizaremos os scripts no arquivo package.json. Deixe-os dessa forma:

{
  "scripts": {
    "start": "react-app-rewired start",
    "build": "react-app-rewired build",
    "test": "react-app-rewired test",
    "eject": "react-scripts eject"
  }
}

Como você pode observar, estamos substituindo todos os scripts react-scripts por react-app-rewired, com exceção do script eject.

Tudo pronto!

Agora podemos utilizar qualquer arquivo dentro da nossa pasta src utilizando o ~/ no momento do import.

import ExampleComponent from '~/components/ExampleComponent/'

E...

Se quiser ver esse exemplo na prática, você pode dar uma olhadinha no template que eu criei para projetos React aqui:

diegosilvatech / boilerplate-cra-typescript

This project is a boilerplate for React project. This template was built with ReactJS and TypeScript.

Lá eu também configurei o ESLint e outras coisas para facilitar a estrutura inicial do seu projeto.

Comenta aí o que você acha dessa abordagem nos nossos imports :)

🇧🇷 | Produtividade com styled-components

Diego Silva — Tue, 29 Jun 2021 00:04:26 +0000

duas boas práticas para melhorar o seu projeto com essa biblioteca fenomenal

O styled-components é uma biblioteca para estilizar a sua aplicação através do JavaScript e é utilizada principalmente na estilização de projetos React e React Native.

Quando pensamos em estilizar algo, também deveríamos estar pensando em como organizar esses estilos, e para quem está começando no mundo do desenvolvimento frontend, essas duas práticas são fundamentais para a escrita e manutenção de um bom código:

Sempre que possível, crie estilos isolados.

Crie estilos isolados

Através dessa prática temos acesso aos estilos do seu componente de forma mais rápida e isso gera mais produtividade e torna a manutenibilidade seus estilos muito mais fácil.

Uma prática muito utilizada no mercado é criar o arquivo de estilos juntamente com o arquivo principal (index.js) do seu componente / página.

Nomear o seu arquivo como styles.js ou styled.js também é uma boa prática. Esses dois nomes são muito utilizados.

Como exemplo, essa é a estrutura dos arquivos de estilo que utilizei em um template para React, no meu GitHub:

Crie estilos semânticos

Apesar do styled-components ser muito conhecido e adotado, é comum vermos muitos componentes de agrupamento e que deveriam possui escopo semântico, sendo criados como uma simples div. É extremamente importante não esquecermos de utilizar as tags de forma correta e consciente.

Esse é um exemplo de como criamos e exportamos um componente estilizado com styled-components:

export const ExampleComponentContainer = styled.div``;

Podemos acessar todas as outras tags como propriedades do styled, como styled.header, styled.nav, styled.section, styled.article, styled.aside, styled.footer, dentre outras.

Você pode acessar o template mencionado acima clicando abaixo:

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

Baixe o projeto e comenta aí o que achou :)

🇧🇷 | Melhorando o seu título no currículo

Diego Silva — Mon, 28 Jun 2021 23:30:46 +0000

afinal, é Front End, Front-End ou Frontend?

Toda vez que preciso preencher o meu cargo em qualquer formulário, fico em dúvida entre Front End, front-End ou Frontend.

Já vi de tudo, inclusive abordagens diferentes dentro do mesmo ~~perfil do LinkedIn~~ currículo.

Mas se existem várias formas diferentes de escrever, qual é a diferença entre elas?

Partindo desse ponto, percebo que existem duas respostas diferentes: a que trata sobre a etimologia dessas palavras e a que trata as diferenças na prática, ou seja, a que mais vai te ajudar a conseguir um trabalho.

E é sobre a segunda opção que eu quero tratar aqui.

Como você já deve ter observado, eu optei pela utilização do termo Front End e foi por um motivo bem simples: é o termo buscado no Google dentre as três opções, na maioria dos países, inclusive o Brasil.

Acredito que usar o termo correto mais buscado traz mais chances de ser encontrado por um recrutador, visto que os mecanismos de buscas ranqueiam melhor os termos mais buscados em comparação aos menos buscados.

Se o seu objetivo é ser achado por recrutadores fora do Brasil, vale a pena checar no Google Trends qual é o termo mais buscado lá.

E você, possui alguma justificativa para não usar dessa forma?

Comenta aí :)

Import hierarchy

Diego Silva — Mon, 28 Jun 2021 20:04:16 +0000

making your imports more elegant and organized | part II

Today we will continue talking about how to make our imports more elegant and organized. For that, we need to talk about import hierarchy.

What is Import Hierarchy?

As the name itself makes clear, import hierarchy is the order of priority of the dependencies imported in our code.

It is very common that our .js and .jsx files import many libraries, components, pages, controllers, services, helpers, styles, that is, a multitude of different file types and data.

The example below is very common in the daily life of a front end developer:

import React, { useState, useEffect } from 'react';
import Button from '~/components/Button';
import { Container } from './styles.js';
import Card from '~/components/Card';
import PropTypes from 'prop-types';
import { combineReducers } from 'redux';
import Main from '~/pages/Main';
import Dashboard from '~/components/Dashboard';
import Home from '~/pages/Home';
import Routes from '~/routes';

function ExampleComponent() { ...

Looking at the code above you may wonder: "I don't see any problem with this code".

And in fact, there isn't. The required dependencies have been imported and are ready to be used.

But if we can make it more organized, why not?

Below I show the same example, only more organized:

import React, { useState, useEffect } from 'react';
import { combineReducers } from 'redux';

import PropTypes from 'prop-types';

import Home from '~/pages/Home';
import Main from '~/pages/Main';

import Button from '~/components/Button';
import Card from '~/components/Card';
import Dashboard from '~/components/Dashboard';

import Routes from '~/routes';

import { Container } from './styles.js';

function ExampleComponent() { ...

In the example above, I ordered the imports as follows:

first: all the dependencies that I consider the most important of my application. For example, all those starting with 'react' and 'redux'
then: all other libraries and modules installed in package.json. For example, Prop Types, Storybook, Unform, among others
then: all internal files, which start with the alias ~/ or @. For example, ~/components, ~/pages, ~/styles, @controllers, @models, and so on. In the post Import custom paths and how this can help you I show you how we can create and configure custom import paths to facilitate the import of our application
so: the routes of my application"
and lastly: my styles. In this case, files named .styled.js

// first, everything that starts with 'react' and 'redux'
import React, { useState, useEffect } from 'react';
import { combineReducers } from 'redux';

// then all imported modules and libraries
import PropTypes from 'prop-types';

// then anything that starts with an alias '~/pages' or '@pages'
import Home from '~/pages/Home';
import Main from '~/pages/Main';

// then anything that starts with an alias '~/components' or '@components'
import Button from '~/components/Button';
import Card from '~/components/Card';
import Dashboard from '~/components/Dashboard';

// so my routes
import Routes from '~/routes';

// and finally, my styles
import { Container } from './styles.js';

function ExampleComponent() { ...

Of course, maintaining this hierarchy for all our code takes a lot of time, attention, and care.

But it's a good thing we can automate this task, isn't it?

Getting to know eslint-plugin-import-helpers

The eslint-plugin-import-helpers is a package that was created by Will Honey, and aims to complement eslint-plugin-import. It brings a very important use case that is still missing from eslint-plugin-import: the order of imports.

About order-imports and how it works

The eslint-plugin-import-helpers brings (as of the date of this post) only the order-imports plugin. This plugin allows you to configure an import hierarchy with just a simple .eslintrc.js configuration file.

Making it happen

First of all, you will need to have ESLint and Prettier configured in your project. If by chance you haven't configured it yet, I suggest you follow this tutorial:

After installing and configuring ESLint and Prettier, we can proceed with the next steps.

Installing and configuring eslint-plugin-import-helpers

At the root of our react project, let's install puglin:

yarn add -D eslint-plugin-import-helpers

Now, let's configure the import-helpers/order-imports rule in the .eslintrc.js file:

// .eslintrc.js
rules: {
  'import-helpers/order-imports': [
    'warn', // displays an alert in the editor
    {
      newlinesBetween: 'always', // inserts a blank line after each priority group
      groups: [
        ['/^react/', '/^redux/'], // first group: everything that starts with 'react' and 'redux'
        '/styled-components/', // second group: everything that is imported directly from the styled-components library. This is to ensure that the first import in styles.js files is always styled-components.
        'module', // third group: everything that is a module (any library listed in the package.json file)
        '/prop-types/', // fourth group: importing prop-types
        '/^~/pages/', // fifth group: all my pages
        '/^~/components/', // sixth group: all my components
        ['parent', 'sibling', 'index'], // seventh group: any parent, sibling, or child file of the current file
        '/routes/', // eighth group: my routes
        '/^~/', // ninth group: all other files imported by the configured alias
        '/styles/', // last group: my styles
      ],
      alphabetize: { order: 'asc', ignoreCase: true }, // configures imports in alphabetical (ascending) order, ignoring case
    },
  ],
}

All ready!

If you have configured prettier to automatically fix ESLint improvement suggestions, whenever this hierarchy is not respected, VSCODE will reorganize the imports automatically as soon as the file is saved.

If you want to see this example in practice, you can take a look at the template I created for React projects here:

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

Comment there what you think about this post :)

Styled Components and their benefits

Diego Silva — Mon, 28 Jun 2021 15:33:56 +0000

the main advantages of using CSS in JavaScript

CSS, the nice guy

CSS is very difficult. If they tell you otherwise, it's because they just want to make you happy

I remember when I saw this phrase in one of Willian Justen's courses. I must have stopped for five minutes while thinking about how real she is.

Do not get me wrong. It's really cool to work with CSS and we're often happy to be able to create our component ~~designs~~ and pages with this technology, but CSS also has a lot of problems.

If we don't worry about minimizing CSS issues and don't do the bad practices prevention work in our code, as the application grows, problems and bad practices grow together.

Maintaining standards is boring, time-consuming and expensive, but only if you do it the wrong way.

It is very difficult for a single programmer to know all the components of an application, especially when they are constantly updated. Now imagine a repository that is maintained by five teams, each team with at least four developers, each developer with different practices and seniority.

Thankfully, there are amazing tools to facilitate code standardization for our projects, such as ESLint, Prettier and EditorConfig. These tools, in line with pre-commit and pre-push routines, greatly facilitate the code standardization and code review process. But that's a topic for another post.

CSS is not ahead of its time

CSS is evolving. We already have some pretty cool features, like the possibility of using variables inside CSS, but even with some new features, we still have some issues.

In the beginning: I'll fix it here, and... ops it broke there..., hummm just fix it here and there... At the end: it feels like I'm at the beginning

Known Issues

Some of the main CSS issues are:

STYLE COLLISION

As CSS is not defined on a per-component or per-page basis, it is loaded onto our website and styling is applied over all visible HTML. When we need to import a library, it can happen that this library has the same classes or has a greater specificity that ends up colliding with our code, generating some problems in the style of our application.

UNUSED CODE

We often write CSS thinking of various ways to represent a component, such as buttons in different shapes. We need to load CSS for all styles, but we don't necessarily need to use all styles in the same page. With that, we ended up loading all the styles of buttons that won't be used there. This brings more problems for the client who ends up spending more bandwidth unnecessarily.

DIFFICULTY IN MAINTENANCE

Many times when we need to update a style, we end up breaking another style in another piece of code that has nothing to do with the first style. This makes maintenance much more costly than it should be and we need to keep "digging" a lot of code so we don't run the risk of breaking something that shouldn't be broken.

Less, Sass, Stylus. How do they live? What do you eat?

The pre-processors are there and they help a lot, especially with the possibility of using variables in CSS (a feature that didn't exist before in css, but now exists) and with the ease of working with style nesting (cascades), but they continued with the classic problems, in addition to making room for bad practices, such as excessive nesting:

/*nested*/
section {
  nav {
    ul {
      li {
        a {
        }
      }
    }
  }
}

/*in line*/
nav ul li a { ... }

Who has never seen an scss code with all this nesting, right?

This nesting is not a good practice, because you end up creating enormous specificity for this component, and therefore if we want to change this style somewhere else, we will need to make this code even more specific, often needing to insert an id or more selector, or even an !important, which isn't cool.

STYLED-COMPONENTS, your little friend

Styled Components is a library that, through a set of practices, solves complex CSS problems.

The main advantages of using styled-components are:

NO BUGS WITH CLASS NAMES

styled-components generates unique class names for each style. Even if elements have the same class, they will not suffer style cohesion. For example:

// button/index.js
  <Button className="primary" />

// public/index.html
  <button class="sc-fznLPX jckqBg primary" />

REMOVAL OF UNUSED CSS

It is the component's responsibility to create or import its style from the styles file. If the component is not used, none of your CSS will be loaded into the page.

Every deleted component of the page will also have its CSS deleted.

DYNAMIC STYLES

It is possible to change the style of the components through the properties and themes received.

Example:

Passing the outlined property to the Button component:

// button/index.js
<Button outlined>Edit profile</Button>

Changing the Button component's style through the passed property:

// button/styles.js
export const Button = styled.button`
  background-color: ${props =>
    props.outlined ? 'transparent' : `${props.theme.colors.primary}`};
`

As we can see, I'm checking if the Button component has the outlined property. If yes, then I apply the background-color as transparent. If not, I apply the value of the colors.primary property, defined in the theme.js file, to the background-color.

I'll still write how to configure a theme using styled-components and put the link here.

VENDOR AUTOMATIC PREFIXING

Properties like -webkit, -moz-, -ms and -o- do not need to be entered anymore, as styled-components does this work automatically.

/* with styled-components */
export const Container = styled.section`
  transition: all 2s linear;
`
/* without styled-components */
.container {
  -moz-transition: all 2s linear;
  -ms-transition: all 2s linear;
  -o-transition: all 2s linear;
  -webkit-transition: all 2s linear;
  transition: all 2s linear;
}

SIMPLIFIED AND PAIN-FREE MAINTENANCE

The style being changed only matches the component that imports it.

Styled Components is awesome, isn't it?

If you want to see this example in practice, you can take a look at the template I created for React projects here:

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

Comment there what you think about this use styled-components :)

Custom import paths and how it can help you

Diego Silva — Mon, 28 Jun 2021 14:56:37 +0000

making your imports more elegant and organized

If there's a pain that bothers me when I'm developing an application with many files, it's when those files import other files, and that causes an excess of ../ in the imports of those files.

It is common to see that as our application grows, the folders of our project files are nested more and more inside other folders, and when we least expect it we come across the following import example:

import ExampleComponent from '../../../../../../src/components/ExampleComponent/'

The example above is real and is much more common than we think. Unfortunately, the excessive use of these ../ brings some pain when we need to maintain our code, among them, the rework of fixing the relative path every time we need to change the location of an imported file or import file.

One of the simplest ways to make this import more elegant and organized is to create a custom path and leave it as an absolute. Thus, the example above could look like this:

import ExampleComponent from '~/components/ExampleComponent/'

In the example above, the ~ prefix was set as an absolute path to a directory in our project, in this case the directory is the src folder. That way, no matter what folder our file is in, when we use the ~/ prefix, we will always be importing the absolute path of the src folder.

Really good right?!

Making it happen

Installing dependencies

First of all, we'll need to install and configure three dependencies for this magic to work. And they are:

react-app-rewired and customize-cra

At the root of our project, let's run the command below to customize the webpack settings without the need to use eject and without the need to create a react-scripts fork.

yarn add -D react-app-rewired customize-cra

babel-plugin-root-import

Now let's run the command below to import files using custom paths.

yarn add -D babel-plugin-root-import

Creating `config-overrides.js`

Also at the root of our project we will create a file called config-overrides.js. He will be responsible for establishing the root folder of our project.

Let's insert this code into the file:

const { addBabelPlugin, override } = require('customize-cra')

module.exports = override(
  addBabelPlugin([
    'babel-plugin-root-import',
    {
      rootPathSuffix: 'src',
    },
  ])
)

Making life easier for the dev editor

Still at the root of our project, we will create a file called jsconfig.json. He will be responsible for making VSCODE understand the custom paths.

Let's insert this code into the file:

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "~/*": ["*"]
    }
  }
}

Last details

Lastly, we will update the scripts in the package.json file. Leave them this way:

{
  "scripts": {
    "start": "react-app-rewired start",
    "build": "react-app-rewired build",
    "test": "react-app-rewired test",
    "eject": "react-scripts eject"
  }
}

As you can see, we are replacing all react-scripts with react-app-rewired with the exception of the eject script.

All ready!

Now we can use any file inside our src folder using ~/ at import time.

import ExampleComponent from '~/components/ExampleComponent/'

And...

If you want to see this example in practice, you can take a look at the template I created for React projects here:

diegosilvatech / boilerplate-cra-typescript

This project is a boilerplate for React project. This template was built with ReactJS and TypeScript.

Comment there what you think about this approach in our imports :)

Productivity with styled-components

Diego Silva — Mon, 28 Jun 2021 14:32:29 +0000

two best practices to improve your project with this phenomenal library

The styled-components is a library for styling your application through JavaScript and is mainly used in the styling of React and React Native projects.

When we think about styling something, we should also be thinking about how to organize these styles, and for those just starting out in the frontend development world, these two practices are fundamental to writing and maintaining good code:

Create isolated styles

Whenever possible, create isolated styles.

Through this practice we have access to your component styles faster and this generates more productivity and makes maintaining your styles much easier.

A widely used practice in the market is to create the styles file together with the main file (index.js) of your component / page.

Naming your file styles.js or styled.js is also good practice. These two names are used a lot.

As an example, this is the structure of the style files I used in a template for React, on my GitHub:

Create semantic styles

Although styled-components is well known and adopted, it is common to see many grouping components that should have semantic scope being created as a simple div. It is extremely important that we do not forget to use tags correctly and consciously.

This is an example of how we create and export a styled component with styled-components:

export const ExampleComponentContainer = styled.div``;

We can access all other tags as styled properties, like: styled.header, styled.nav, styled.section, styled.article, styled.aside, styled.footer,
among others.

You can access the template mentioned above by clicking here:

diegosilvatech / boilerplate-cra-typescript

This project is a boilerplate for React project. This template was built with ReactJS and TypeScript.

Comment there what you think of this file structure :)

Improving your resume title

Diego Silva — Mon, 28 Jun 2021 14:20:54 +0000

which is correct? Front End, Front End or Frontend?

Every time I need to fill out my position on any form, I am in doubt between Front End, Front-End or Frontend.

I've seen it all, including different approaches within the same ~~LinkedIn profile~~ resume.

But if there are several different ways of writing, what's the difference between them?

From this point on, I realize that there are two different answers: the one dealing with the etymology of these words and the one dealing with differences in practice, that is, the one that will help you the most to get a job.

And it's about the second option I want to deal with here.

As you may have already noticed, I chose to use the term Front End and it was for a very simple reason: it is the term searched on Google among the three options, in most countries, including Brazil.

I believe that using the correct most searched term is more likely to be found by a recruiter, as search engines rank the most searched terms better compared to the least searched terms.

If your goal is to be found by recruiters outside Brazil, it's worth checking Google Trends for the most searched term there.

And you, do you have any justification for not using it that way?

Comment there :)

Forem: Diego Silva

🇧🇷 | Hierarquia de imports

O que é hierarquia de importações?

Conhecendo o eslint-plugin-import-helpers

Sobre o order-imports e como ele funciona

Fazendo acontecer

Instalando e configurando o eslint-plugin-import-helpers

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

🇧🇷 | Import paths personalizados e como isso pode te ajudar

Fazendo acontecer

Instalando as dependências necessárias

react-app-rewired e customize-cra

babel-plugin-root-import

Criando o 'config-overrides.js'

Facilitando a vida do dev editor

Últimos detalhes

Tudo pronto!

E...

diegosilvatech / boilerplate-cra-typescript

This project is a boilerplate for React project. This template was built with ReactJS and TypeScript.

🇧🇷 | Produtividade com styled-components

Crie estilos isolados

Crie estilos semânticos

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

🇧🇷 | Melhorando o seu título no currículo

Import hierarchy

What is Import Hierarchy?

Getting to know eslint-plugin-import-helpers

About order-imports and how it works

Making it happen

Installing and configuring eslint-plugin-import-helpers

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

Styled Components and their benefits

CSS, the nice guy

Known Issues

STYLED-COMPONENTS, your little friend

coderamos / template-reactjs

This project contains the basic structure for React projects. It also includes my settings for babel-plugin-root-import, eslint-plugin-import-helpers, prop-types, react-router-dom, styled-components and more...

Custom import paths and how it can help you

Making it happen

Installing dependencies

Creating config-overrides.js

Making life easier for the dev editor

Last details

All ready!

And...

diegosilvatech / boilerplate-cra-typescript

This project is a boilerplate for React project. This template was built with ReactJS and TypeScript.

Productivity with styled-components

Create isolated styles

Create semantic styles

diegosilvatech / boilerplate-cra-typescript

This project is a boilerplate for React project. This template was built with ReactJS and TypeScript.

Improving your resume title

Sobre o `order-imports` e como ele funciona

Instalando e configurando o `eslint-plugin-import-helpers`

Creating `config-overrides.js`