DEV Community: Rafael Leitão

Articles you may have missed last week but it's worth reading 👍

Rafael Leitão — Wed, 26 May 2021 14:49:15 +0000

Hello DEV people! 👋

This is the second post I'm creating in this series I intend to help promote nice articles that I feel they should have got more attention.

This is a way to raise awareness of these content creators so that you could follow them and stay tuned to new articles that could help you learn.

The list aims to help these content creators to have another way to reach more people and have their work appreciated. I tried to get these articles(in no particular order) from the last 7 days so they are relatively new on here.

The list 📝

1. [Storyblok, Gatsby] Programmatically create blog post pages from data

If you're someone who wants to have a super blazing fast blog app with headless CMS integrated in it in the easiest way then Storyblok + Gatsby.js might be for you 😎

In this article, Arisa shows you how to play around with Storyblok and programmatically create blog post pages. Also, this is the first article of her series about working with both so you should check it out :)

[Storyblok, Gatsby] Programmatically create blog post pages from data

Arisa Fukuzaki ・ May 20 '21

#storyblok #gatsby #react #api

2. NextAuth.js Intro [3 of 3]: Adding Access Control

In this series, Mike explores different patterns for using next-auth with Next.js for easy and powerful login and sign up.

In this article, he talks about requiring the user to be logged in to see parts of the app. Great introduction to NextAuth!

NextAuth.js Intro [3 of 3]: Adding Access Control

Mike Cavaliere ・ May 21 '21

#nextjs #jamstack #react #javascript

3. Implementing a Social Share Feature

For all the content creators, having a share button that will help readers spread your content is essencial.

In this article, Daniel shows us how to create a button that shares pre-defined tweet, sms and email. The interaction of the sharing button is awesome as well so check it out and be inspired!

Implementing a Social Share Feature

Daniel Sasse ・ May 20 '21

#react #beginners #codenewbie

4. Remote Onboarding as a Software Engineer

In our current situation, we were forced to work remotely and it's no surprise that after experimenting with it, most of the developers want to work like this even if partially. So companies may keep this way of work and remote onboarding will be more frequent.

In this article, Ben shares some tips for us to have a better experience and give a better impression when remotely joining a team.

Remote Onboarding as a Software Engineer

Ben ・ May 20 '21

#career #beginners #productivity

5. Creating an Accordion Component in React with Typescript and TailwindCSS

If you're like Julia and don't use any external UI library on your project or enjoy building them from scratch + uses TailwindCSS then this is for you.

In this article, she creates it from scratch showing the states logic and TailwindCSS classes she needed. Even if you're not like Julia neither you're creating an accordion, it's worth seeing how TailwindCSS can be used.

Creating an Accordion Component in React with Typescript and TailwindCSS

Bionic Julia ・ May 22 '21

#hooks #react #tailwindcss #typescript

6. Sustainable string enums in Typescript

If you need to have some limited options, to a dropdown, for example, that could also change in the future, using string enums can be the best alternative.

In this article, Alexis shows us how to use it to reduce the possibility of inconsistency and make it easier to change.

Sustainable string enums in Typescript

Alexis Moody ・ May 18 '21

#typescript #webdev #react #javascript

That's it! ✌️

Hope you find it usefull somehow. If you liked it, don't forget to go to these articles and give it a ❤️. It's nice when someone show their love and gratifying for the author to see they've helped people :)

This is just a list I made trying to help these authors, none of them asked for it neither they know about it 😂.

There are many other nice articles out there but I can't put them all here so if you think your article deserves a second chance feel free to drop it in the comments :)

If you liked it, leave it a ❤️. Hopefully we can also connect on Twitter, I also share nice articles I find there :)

Articles you may have missed this week but it's worth reading 👍

Rafael Leitão — Sun, 09 May 2021 14:09:26 +0000

Hello DEV people! 👋

For some time I've had this idea of trying to support those developers who create content sharing things they've learned to help others in the community but for different reasons didn't get many interactions in their articles.

There are many reasons for that to happen, maybe time of posting, article's title, not having many people following them here, etc... for whatever reason the post didn't get many interactions and this can be frustrating.

Frustration is relative since people have different expectations when they share an article here. Nonetheless, deep down, they shared to help others, and when there are few interactions we assume we haven't helped as much as we could've. The feelings involved depend on the writer but as someone who also shares posts sometimes here I know this can be true to some.

Okay okay for introductions, this list aims to help these content creators to have another way to reach more people and have their work appreciated. I tried to get these articles(in no particular order) from the last 7 days so they are relatively new on here.

The list 📝

1. Tips for frontend devs on how to better approach coding designs

When having to implement a new design, it's important for frontend devs to give a fresh new eye and review it from a different angle beyond the designers.

When doing this, having in mind how the user would think while interacting with these new features is essential to sane all the doubts and build them the best way.

To help with it, Joanna shares some questions she tries to answer when getting the design.

How to code designs better - tips for FE devs

Joanna Otmianowska ・ May 2 '21

#webdev #frontend #design

2. On Becoming A Better Junior Developer

Based on his experience, Nicholas created a list of things Junior developers should have in mind for success.

I would add that not only Junior but every developer should have those points in mind to work better in a team and always evolve.

On Becoming A Better Junior Developer

Nicholas Mendez ・ May 6 '21

#career #webdev #promotion

3. App 101: Jamstack vs Traditional Webapps

To start his App 101 series, that will bring discussions to help us make some decisions when building webapps, Zack decided to go down the memory lane.

In this article, he shares a bit of the history and evolution of web development from those old webapps to the modern JAMStack. Nice one to reflect on how things evolved and give food for thought to which approach best suites your need.

App 101: Jamstack vs Traditional Webapps

Zack Sheppard ・ May 4 '21

#beginners #webdev #architecture #learning

4. 7 Approaches I Took While Learning Web Dev From Scratch

Switching from biotechnology to software engineering is not easy task and through this path Michael has learned a lot about the pros and cons of different approach while learning.

In this article, he shares how these approaches helped him and how you could also benefit from them. It's not a guide on how to make your study plan but it is definitely a great starting point based on his experience.

7 Approaches I Took While Learning Web Dev From Scratch

mmiask ・ May 4 '21

#beginners #career #webdev

5. Everything you need to know about Styled Components

The latest libs making waves in the CSS-in-JS paradigm are TailwindCSS and Chakra-Ui but many projects still uses one of the most successful lib when this approach emerged, Styled-Components.

In this article, Paul shares a lot of great tips showing the capabilities of the lib to help you with it. Worth checking out if you work with Styled-Components.

Everything you need to know about Styled Components

Paul Ccari ・ May 4 '21

#react

6. State and setState Explained with Emotion

If you're a beginner in React this is a nice introduction to state with actionable examples on how to deal and pass it between components.

Shaundai nailed it with the funny naming for this example and the explanations :)

State and setState Explained with Emotion

Shaundai Person ・ May 3 '21

#codenewbie #react #javascript #functional

That's it! ✌️

Hope you find it usefull somehow. If you liked it don't forget to go to these articles and give it a ❤️. It's nice when someone show their love and gratifying for the author to see they've helped people :)

This is just a list I made trying to help these bloggers, none of them asked for it neither they know about it 😂.

There are many other nice articles out there but I can't put them all here so if you think your article deserves a second chance feel free to drop it in the comments :)

If you liked it, leave it a ❤️. Hopefully we can also connect on Twitter, I also share nice articles I find there :)

Automate components creation in React project

Rafael Leitão — Mon, 26 Apr 2021 12:34:22 +0000

We write code and create files every day. If you're developing some frontend project most likely you're creating components which start with almost the same folder and file structures. Creating this over and over again is a boring job and one that most of us probably would love to improve.

I was facing that in a React project I'm currently working on and I wanted to automate these initial files every time I wanted to create a component. For that, there is a Javascript called Plop.

What is Plop.js?

As in its website, Plop is a little tool that saves you time and helps your team build new files with consistency. It makes our life easier when creating files because we just need to setup, create some generators and templates and from that every new files created will follow the same structure.

How to use it?

1. Installation



npm install --save-dev plop
yarn add -D plop

2. Create a Plop file

A Plop file is where we create generators for the library to execute when we run plop command in terminal.

It is a file where we basically export a function which receives the plop object. This object exposes the Plop API which then we can create a generator with the setGenerator(name, config) function.

A generator is where we define the prompts, questions to be asked to the user, and the actions, to be performed by Plop for adding, modifying or appending files.

An example taken from the docs for a basic plop file in Javascript:



// plopfile.js
module.exports = function (plop) {
    // controller generator
    plop.setGenerator('controller', {
        description: 'application controller logic',
        prompts: [{
            type: 'input',
            name: 'name',
            message: 'controller name please'
        }],
        actions: [{
            type: 'add',
            path: 'src/{{name}}.js',
            templateFile: 'plop-templates/controller.hbs'
        }]
    });
};

This generator called controller will ask us for the controller name and will perform a creation of file in the specified path with a dynamic file name and this new file will be structured the same way as controller.hbs file.

3. Create a template file with Handlebars

Handlebars is a templating language, it uses a (wait for it) template with an input object to generate HTML or other text formats. It looks like normal text with some Handlebars expressions. We won't cover more than this, this is the basic stuff to get going here, but you can dive deep in the docs.

With this template defined the generator will do its actions and create the files for us. Let's see an example in action.

Real usage example

I hope the steps above were enough to understand the basic follow. In this section we'll see a real example, the way I used Plop for my current project.

1. Creating a Plopfile

For my current project I'm using Atomic Design to structure my components as a way to improve its consistency and reusability.

For each component I create I need to define which folder it is going to be added to, besides its name. These are the prompts my generator has.

Furthermore, I usually create a 3 files for each component: index.tsx for the component itself, stories.tsx for the Storybook stories and test.tsx for the tests. In this example, to simplify, I'm creating only the first two. So, these are my actions for the generator.



import {NodePlopAPI} from 'plop';

export default function (plop: NodePlopAPI) {
    // controller generator
    plop.setGenerator('component', {
        description: 'Atomic Design component creation logic',
        prompts: [
          {
            type: 'input',
            name: 'name',
            message: 'Component name please',
          },
          {
            type: 'input',
            name: 'level',
            message: 'Atomic Design level of the component please',
          },
        ],
        actions: [
          {
            type: 'add',
            path: '../src/components/{{level}}/{{pascalCase name}}/index.tsx',
            templateFile: 'templates/index.tsx.hbs',
          },
          {
            type: 'add',
            path: '../src/components/{{level}}/{{pascalCase name}}/stories.tsx',
            templateFile: 'templates/stories.tsx.hbs',
          }
        ],
      })
}

Bear in mind that the export is a little different from the previous I showed since I'm using Typescript for my project.

So, basically this generator prompts questions for me and according to my answers it creates two files in a dynamically created folder based on the templates.

2. Creating the templates

For the templates I created two Handlebars files, one for stories.tsx and other for index.tsx.

1. `index.tsx`



import { Box } from '@chakra-ui/react'

export type {{pascalCase name}}Props = {

}

const {{pascalCase name}} = ({ }: {{pascalCase name}}Props) => (
  <Box>
    {{pascalCase name}}
  </Box>
)

export default {{pascalCase name}}

2. `stories.tsx`



import {{pascalCase name}}, { {{pascalCase name}}Props } from '.'
import { Story, Meta } from '@storybook/react'

export default {
  title: '{{pascalCase name}}',
  component: {{pascalCase name}},
} as Meta

const Template: Story<{{pascalCase name}}Props> = (args) => <{{pascalCase name}} {...args} />

export const Default = Template.bind({})
Default.args = {

}

In each template file, the {{pascalCase name}} will be replaced by the name, as a pascal case string, I provided when running plop command.

3. Run the plop command in a package.json script

To make it easier for me, I created a script called generate to run the plop command, the --plopfile flag is used to direct the path to my plopfile with the generator.



// package.json
// ...
  "scripts": {
    //...
    "generate": "yarn plop --plopfile ./plop/plopfile.ts"
  },
// ...

When runing yarn generate, Plop will ask me the questions I defined and create the files accordingly as seen below:

Generated index.tsx:



import { Box } from '@chakra-ui/react'

export type UserHeaderProps = {

}

const UserHeader = ({ }: UserHeaderProps) => (

  <Box>

    UserHeader

  </Box>

)

export default UserHeader

Conclusion

That's it! You just need to set up Plop and follow the steps to create its generator in the plop file, the templates files and the script to run it. After that, from a simple script call, Plop will do everything for you to make it smoother when creating new components for you application.

Plop can do much more than this and I encourage you to check its docs. For now, this has already made my life easier and I hope it can also help you.

If it was somehow useful, leave it a ❤️ or if you have more to add drop a comment. Also, I'd love if we connect on Twitter as well :)

What I've learned using Chakra-Ui so far

Rafael Leitão — Sun, 18 Apr 2021 15:36:34 +0000

When I finished playing around with building a Design System(or part of it) for a project, before start coding one important question popped up: Which library should I use to style my components?

Lately, I've been working with styled-components but I wanted to try the trending ones right now: Tailwind CSS or Chakra-Ui.

After watching some videos and seeing how both looked like in code, I decided to go with Chakra-Ui.

So, in this article I'm going to share what my experience have been so far with Chakra-Ui after working with it during these last 2 days. Hopefully it can help people having their first steps with the library.

1. Creating a custom theme is a breeze

By default, Chakra-Ui already comes with a theme but we can customize it to best fit our design. And that was where I started to play with Chakra since I had created a design system.

The theme object is where we define the application's color pallete, type scale, font stacks, border radius values and etc. All Chakra components inherit from this default theme.

From the default theme, we can extend and overide tokens and also add new values to the theme. Customizing the it is as easy as:

1) Extending it with extendTheme:


import { extendTheme } from '@chakra-ui/react'

const customTheme = extendTheme({
    colors: {
        lightGray: {
            default: '#C4C4C4',
            hover: '#EEEEEE',
            disabled: '#9E9E9E'
        }
    },
    // I'm just adding one more fontSize than the default ones
    fontSizes: {
        xxs: '0.625rem'
    },
    // I'm creating a new space tokens since the default is represented with numbers
    space: {
        xs: '0.25rem',
        sm: '0.5rem',
        md: '1rem',
        lg: '1.5rem',
        xl: '2rem',
        xxl: '3rem',
    }
})

export default customTheme

2) Passing to the ChakraProvider:

import customTheme from './theme'

<ChakraProvider theme={customTheme}>
  <App />
</ChakraProvider>

3) Using it:

import customTheme from './theme'

const BoxWithText= ({ text }) => (
  <Box padding='xs' borderRadius='lg'>
    <Text>{text}</Text>
  </Box>
)

2. Creating variants of components makes it easier to implement a design system

Besides customizing theme tokens we can also customize component styles.

Chakra component styles have a specific API that a component style consists of:

baseStyle, the default style of a component
sizes, represents styles for different sizes of a component
variants, represents styles for different visual variants
defaultProps, optional, to define the default size or variant.

From the docs, what the component style looks like:

const ComponentStyle = {
  // style object for base or default style
  baseStyle: {},
  // styles for different sizes ("sm", "md", "lg")
  sizes: {},
  // styles for different visual variants ("outline", "solid")
  variants: {},
  // default values for `size` and `variant`
  defaultProps: {
    size: "",
    variant: "",
  },
}

With the possibility of customizing each component we can create variants for them to match pre-defined styles of a component. For example, in a design system you may have different variations of the typography to show different font sizes, font weights, etc. The same goes with components such as buttons, inputs, etc.

With variants we can create pre-defined styles for those components:

import { extendTheme } from '@chakra-ui/react'

const customTheme = extendTheme({
    components: {
        Heading: {
            variants: {
                h1: {
                    fontSize: '4xl', fontWeight: 'bold'
                },
                h2: {
                    fontSize: '3xl', fontWeight: 'bold'
                }
            }
        },
        Text: {
            variants: {
                subtitle: {
                    fontSize: 'xl', fontWeight: 'medium'
                },
                body: {
                    fontSize: 'md', fontWeight: 'medium'
                }
              }
            }
        }
})

export default customTheme

And use it in our code:


const Badge = ({ text }) => (
  <Box padding='xs' borderRadius='lg' w='max-content'>
    <Text variant='bodyExtraSmall'>{text}</Text>
  </Box>
)

3. Integrating with Storybook is not so smooth currently

One pain point I had with this begining of my journey with Chakra-Ui was trying to use Storybook to show my created components. For my workflow, I always create the components and their corresponding stories to be easier to see the different styles and create a component library.

However, when I created the stories with my Chakra components and checked the Storybook it did not load any styling I made with Chakra. I was frustrated at first but thanks to an issue raised I could get it working.

To fix that you can:

1) Modify the main.js file inside the .storybook folder to match the webpackFinal config that Chakra uses:

const path = require("path");
const toPath = (_path) => path.join(process.cwd(), _path);

module.exports = {
  stories: ["../src/**/*.stories.mdx", "../src/**/*.stories.@(js|jsx|ts|tsx)"],
  addons: [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/preset-create-react-app",
  ],
  webpackFinal: async (config) => {
    return {
      ...config,
      resolve: {
        ...config.resolve,
        alias: {
          ...config.resolve.alias,
          "@emotion/core": toPath("node_modules/@emotion/react"),
          "emotion-theming": toPath("node_modules/@emotion/react"),
        },
      },
    };
  },
};

2) Wrap the story decorator with the ChakraProvider in the preview.js file:

import React from "react"
import { ChakraProvider } from '@chakra-ui/react'
import theme from '../src/theme'

export const parameters = {
  actions: { argTypesRegex: "^on[A-Z].*" },
}

const withChakra = (StoryFn) => {

  return (
    <ChakraProvider theme={theme}>
      <StoryFn />
    </ChakraProvider>
  )
}

export const decorators = [withChakra]

This is a temporary workaround that I believe can be resolved any time soon since they are already working on it :)

4. We can't create variants for Box but we can use Layer Styles or Text Styles

Another "problem" I had was when I tried to create variants for the Box component. I wanted to create different types of Badges that I could simply choose the variant when inserting them on my components. My Badge consisted of a Box with a Text inside, the code I've shown in the previous snippets.

However, after finding this issue I understood that by design Box cannot receive variants in theme since it is a generic component, it represents a div.

To work around that, you could use the useStyleConfig or use the textStyle or layerStyle props, docs here.

Both props are used to avoid repeating specific text and layer properties and help us keep our components organized and consistent. They allow us to save styling attributes to re-use in other components, passing the corresponding prop to the component.

Since I only needed to change the background color and the border depending on the type of Badge I wanted, I used the layer style.

To solve this:
1) Extend the theme with new layerStyles:

const customTheme = extendTheme({
    layerStyles: {
      defaultBadge: { bg:'lightGray.default' },
      outlinedBadge: { bg:'transparent', border: '1px solid #000000' },
      whiteBadge: { bg:'#FFFFFF' }
    }
})

2) Consume it in the component:

const Badge = ({ text }) => (
  <Box layerStyle=`outlinedBadge` padding='xs' borderRadius='lg' w='max-content'>
    <Text variant='bodyExtraSmall'>{text}</Text>
  </Box>
)

Conclusion

That's it for now. I hope you could get some tips when also starting your journey with Chakra-Ui. If I find more interesting points and learnings to share I may create another article as well :)

If it was somehow useful, leave it a ❤️ or if you have more to add drop a comment.
Also, I'd love if we connect on Twitter as well :)

De volta ao básico: Tipos Primitivos e Objetos em Javascript

Rafael Leitão — Thu, 01 Apr 2021 00:03:54 +0000

E aí, galera 👋

Eu estava assistindo um vídeo de Programação Orientada a Objetos em JavaScript e achei que seria bom compartilhar o que estou aprendendo / revisando. É por isso que estou planejando uma série de postagens para cobrir alguns conceitos como uma forma de aprender mais sobre os tópicos e espero que também ajude algumas pessoas.

Neste artigo, abordarei os tipos de Javascript e suas diferenças.

Tipos do Javascript

Existem oito tipos de dados em Javascript:

string
number
bigint
boolean
undefined
null
symbol
Object

Os primeiros 7 deles são comumente chamados de Tipos primitivos e todo o resto são Tipo objeto.

Tipos primitivos

Eles só podem armazenar um único dado, não têm métodos e são imutáveis.

Espera ae, como assim? Eles são mutáveis ... Na verdade, eles não são. Normalmente confundimos o próprio valor primitivo com a variável que atribuímos ao valor primitivo. Dá uma olhada:



// A gente nao pode modificar a string
let car = "car"
console.log(car) // car
car.toUpperCase()
console.log(car) // car
car[0] = "b"
console.log(car) // car


// Mas podemos atribuir um novo valor à mesma variável
car = car.toUpperCase()
console.log(car) // CAR

A variável pode ser reatribuída a um novo valor, mas o valor primitivo existente não pode ser alterado como fazemos com arrays ou objetos.

Portanto, esta é uma das principais diferenças entre os dois tipos:
Tipos primitivos são imutáveis e tipos de objetos são mutáveis.

_Aah, beleza. Entendi! Mas como é que eles não têm métodos, se você acabou de usar um? _

Esse é outro ponto interessante! Tipos primitivos não têm métodos, mas, exceto pelo null e undefined, todos eles têm objetos equivalentes que envolvem os valores primitivos, assim podemos usar métodos.

Para o tipo primitivo string existe o objeto String, para a primitiva number existe Number, e portanto existem Boolean, BigInt e Symbol.

Javascript converte automaticamente os primitivos em seus objetos correspondentes quando um método for invocado. Javascript envolve o primitivo e chama o método.

Veja abaixo como um objeto String é estruturado com seu valor primitivo e __proto__ (que está além do nosso escopo aqui, mas está relacionado ao prototype do seu objeto) com os métodos associados:

É assim que podemos acessar propriedades como length e métodos como indexOf e substring ao trabalhar com tipos primitivos string.

Quando o Javascript os envolve com seus objetos correspondentes, ele chama o método valueOf para converter o objeto de volta ao valor primitivo quando o Javascript encontra um objeto onde um valor primitivo é esperado.

Tipos de objeto

Diferentemente dos tipos primitivos, os objetos podem armazenar coleções de dados, as suas propriedades, e são mutáveis.



// Podemos modificar os objetos sem precisar reatribui-los à variáveis
let cars = ["bmw", "toyota"]
console.log(cars) // ["bmw", "toyota"]
cars.push("tesla")
console.log(cars) // ["bmw", "toyota", "tesla"]

let car = { brand: "tesla" }
car.year = 2021
console.log(car) // { brand: "tesla", year: "2021" };

Exemplos de tipos de Objeto são Array e o próprio Object. Diferente dos Tipos primitivos, eles possuem métodos embutidos. Dá para ver abaixo como um array e um objeto são mostrados aqui no navegador com alguns de seus métodos:

Por mais estranho que pareça, funções são na verdade objetos também, são objetos Function, que podem ser chamados.

Só para ilustrar isso e por curiosidade, veja como as funções também podem ser criadas:

Isso é apenas para fins educacionais, uma vez que não é recomendado usá-lo dessa forma e há problemas com closures, conforme mostrado aqui.

Beleza, aprendemos um pouco mais sobre esses tipos, então vamos ver algumas das diferenças ao trabalhar com eles.

Diferenças entre os tipos

1. Atribuindo a uma variável e copiando o valor

A diferença na forma como os valores são armazenados nas variáveis é o que faz as pessoas geralmente chamarem Tipos de objeto como Tipos de referência.

Tipos primitivos

Quando atribuímos um tipo primitivo a uma variável, podemos pensar nessa variável como contendo aquele valor primitivo.



let car = "tesla"
let year = 2021

// Variável - Valor
// car      - "tesla"
// year     - 2021

Portanto, quando atribuímos essa variável a outra variável, estamos copiando esse valor para a nova variável. Assim, tipos primitivos são "copiados por valor".



let car = "tesla"
let newCar = car

// Variável - Valor
// car      - "tesla"
// newCar   - "tesla"

Uma vez que copiamos os valores primitivos diretamente, ambas as variáveis são separadas e se mudarmos uma não afetamos a outra.



let car = "tesla"
let newCar = car

car = "audi"

// Variável - Valor
// car      - "audi"
// newCar   - "tesla"

Tipos de objeto

Com Tipos de Objeto as coisas são diferentes. Quando atribuímos um objeto a uma variável, a variável recebe uma referência para esse valor. Esta referência armazena o endereço para a localização desse valor na memória (tecnicamente mais do que isso, mas vamos simplificar). Portanto, a variável não tem o valor em si.

Vamos imaginar a variável, o valor que ela armazena, o endereço na memória e o objeto nos trechos abaixo:



let cars = ["tesla"]

// Variável  - Valor                 - Endereço - Objeto
// cars      - <#001> (A referência) - #001      - ["tesla"]

Desta forma, ao atribuirmos esta variável a outra estamos dando a ela a referência do objeto e não copiando o próprio objeto como acontece com o valor primitivo. Assim, tipos de objetos são "copiados por referência".



let cars = ["tesla"]
let newCars = cars

// Variável  - Valor                 - Endereço - Objeto
// cars      - <#001> (A referência) - #001     - ["tesla"]
// newCars   - <#001> (A referência tem o mesmo endereço)

cars = ["tesla", "audi"]

// Variable  - Valor                  - Endereço - Objeto
// cars      - <#001> (A referência) - #001     - ["tesla", "audi"]
// newCars   - <#001> (A referência tem o mesmo endereço)

console.log(cars) // ["tesla", "audi"]
console.log(newCars) // ["tesla", "audi"]

Ambos têm referências ao mesmo objeto array. Então quando modificamos o objeto de uma das variáveis a outra também terá essa mudança.

2. Comparação

Entender as diferenças do que é armazenado nas variáveis ao lidar com tipos primitivos e de objeto é crucial para entender como podemos compará-los.

Tipos primitivos

Usando o operador de comparação estrita ===, se compararmos duas variáveis que armazenam valores primitivos elas serão iguais se tiverem o mesmo valor.



let year = 2021
let newYear = 2021

console.log(year === 2021) // True
console.log(year === newYear) // True

No entanto, se compararmos duas variáveis que foram definidas como Tipos de objeto, estaremos na verdade comparando duas referências em vez de seus objetos. Portanto, eles são iguais apenas se referirem exatamente ao mesmo objeto.



let cars = ["tesla"]
let newCars = ["tesla"]

console.log(cars === newCars) // False
console.log(cars === ["tesla"]) // False

// Agora copiamos a referência de cars para newCars
newCars = cars
console.log(cars === newCars) // True

Mesmo que, no início do trecho de código estivéssemos trabalhando com o mesmo conteúdo nos arrays, as variáveis não tinham as mesmas referências, elas tinham referências a diferentes objetos de array na memória. Porém, após copiarmos a referência para newCars, já que agora eles estão "apontando" para o mesmo objeto, a avaliação é True.

Portanto, para comparar objetos, não podemos simplesmente usar o operador === porque, embora eles possam ter as mesmas propriedades, eles podem não fazer referência ao mesmo objeto. Existem algumas maneiras de fazer isso e, por isso, recomendo a leitura deste artigo (que está em inglês).

3. Passando para funções

Quando passamos tipos primitivos ou de objetos para funções, é como se estivéssemos copiando seus valores/referências para os parâmetros das funções, da mesma maneira que estivéssemos atribuindo a eles com =.

Como vimos que quando os atribuímos a novas variáveis estamos ou copiando seu valor (para tipos primitivos) ou referenciando (para tipos de objeto), é mais fácil entender o que acontece com funções e seu escopo externo.

Tipos primitivos

Quando estamos passando Tipos primitivos para funções, estamos copiando seus valores para os parâmetros das funções, assim isso não afeta a variável inicial no escopo externo.



let year = 2021
function getYearWithoutCovid (freeYear) {
    freeYear = 2022
    return freeYear
}

const newYear = getYearWithoutCovid(year)
console.log(year) // 2021
console.log(newYear) // 2022

Passando ano para a função, estamos copiando seu valor para o parâmetro da função (freeYear será 2021), assim a variável original não seja afetada.

Tipos de objeto

Com Tipos de objeto, estamos copiando suas referências ao passá-los como parâmetros de funções. Portanto, se alterarmos o objeto dentro da função isso também será sentido no escopo externo.



let person = { name: "Paul", status: "unemployeed" }
function getAJob (person) {
    person.status = "employeed"
    return person
}

const newPerson = getAJob(person)
console.log(person) // { name: "Paul", status: "employeed" }
console.log(newPerson) // { name: "Paul", status: "employeed" }

Quando passamos pessoa para a função, estamos copiando sua referência para o parâmetro da função, não seu valor de objeto. Alterá-lo dentro da função afetará o objeto inicial no escopo externo, uma vez que ambas as variáveis têm referências ao mesmo objeto.

É por isso que é recomendado usar Funçoes puras neste caso (que não estão no escopo deste artigo, mas eu encorajo você a pesquisar sobre isso <3). Para isso, criamos uma cópia local dessa pessoa dentro da função e a modificamos ao invés do objeto passado.

Conclusão

Espero que com este artigo você possa entender um pouco mais sobre os tipos de dados em Javascript e também aprender as principais diferenças entre eles.

Eu apenas tentei compartilhar o que aprendi ao revisar esses conceitos, então há mais coisas a acrescentar, mas achei que essa era uma forma didática de explicar. Se você tem coisas a acrescentar e discutir, deixe um comentário :) Se isso te ajudou de alguma forma, deixe um coração <3

Além disso, me segue no Twitter se quiser, talvez compartilhe coisas legais lá também :)

Referências

https://262.ecma-international.org/11.0/#sec-ecmascript-data-types-and-values
https://flaviocopes.com/difference-primitive-types-objects/
https://dmitripavlutin.com/value-vs-reference-javascript
https://codeburst.io/explaining-value-vs-reference-in-javascript-647a975e12a0
https://codeburst.io/javascript-essentials-types-data-structures-3ac039f9877b#01e0
https://mattgreer.dev/blog/javascript-is-a-pass-by-value-language/
https://developer.mozilla.org/en-US/docs/Glossary/Primitive
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/valueOf

Back to the basics: Primitive and Object types in Javascript

Rafael Leitão — Mon, 29 Mar 2021 18:42:21 +0000

Hello everyone 👋

I was watching the video Object-oriented Programming in JavaScript: Made Super Simple | Mosh from Mosh Hamedani and I thought it may be nice to share what I'm learning/reviewing. That's why I'm planning a series of posts to cover some concepts as a way to learn more about the topics and hopefully help some people as well.

In this article I will cover Javascript Types and their differences.

Javascript Types

There are eight data types in Javascript:

string
number
bigint
boolean
undefined
null
symbol
Object

The first 7 of them are commonly called Primitive Types and everything else are Object Types.

Primitive Types

They can only store a single data, have no methods and are immutable.

Wait, How come? They are mutable... Actually, they are not. We usually confuse the primitive value itself with the variable we assign the primitive value. See below:



// We cannot mutate the string
let car = "car"
console.log(car) // car
car.toUpperCase()
console.log(car) // car
car[0] = "b"
console.log(car) // car

// But we can assign a new value to the same variable
car = car.toUpperCase()
console.log(car) // CAR

The variable can be reassigned a new value but the existing value of the primitive cannot be changed like we do with arrays or objects.

So this is one of the main differences between both types:
Primitive Types are immutable and Object Types are mutable.

Aah, okay. Got it! But what about that they don't have methods if you've just used one?

That's another interesting point! Primitive Types have no methods but, except for null and undefined, they all have object equivalents that wrap the primitive values then we're able to use methods.

For string primitive there is String object, for number primitive there is Number, and so there are Boolean, BigInt and Symbol.

Javascript automatically converts the primitives to their corresponding objects when a method is to be invoked. Javascript wraps the primitive and call the method.

See below how a String object is with its primitive value and __proto__(which is beyond our scope here but it's related to its object prototype) with the associated methods:

That's how we can access properties like length and methods like indexOf and substring when working with string primitives.

When Javascript wraps them with their corresponding objects, it calls the valueOf method to convert the object back to the primitive value when Javascript finds an object where a primitive value is expected.

Object Types

Differently from the primitives, Objects can store collections of data, their properties, and are mutable.



// We can mutate objects without needing to reassign the variable
let cars = ["bmw", "toyota"]
console.log(cars) // ["bmw", "toyota"]
cars.push("tesla")
console.log(cars) // ["bmw", "toyota", "tesla"]

let car = { brand: "tesla" }
car.year = 2021
console.log(car) // { brand: "tesla", year: "2021" };

Examples of Object types are Array and Object. Different from Primitive Types they have built-in methods. You can see below how an array and object is shown here on the browser with some of their methods:

As crazy as it seems, functions are actually objects too, they are Function objects, which are callable.

Just to illustrate that and for curiosity, see how functions could also be created:

This is just for educational purpose since it is not recommended to use it like this and there are problems with closures as shown here.

Okay, we learned a bit more about these types so let’s see some of the differences when working with them.

Differences between types

1. Assigning to a variable and copying value

The difference in the way the values are stored in variables is what makes people usually call Object Types as Reference Types.

Primitive Types

When we assign a primitive type to a variable, we can think of that variable as containing that primitive value.



let car = "tesla"
let year = 2021

// Variable - Value
// car      - "tesla"
// year     - 2021

So when we assign this variable to another variable, we are copying that value to the new variable. Thus, primitive types are "copied by value".



let car = "tesla"
let newCar = car

// Variable - Value
// car      - "tesla"
// newCar   - "tesla"

Since we copied the primitive values directly, both variables are separate and if we change one we don't affect the other.



let car = "tesla"
let newCar = car

car = "audi"

// Variable - Value
// car      - "audi"
// newCar   - "tesla"

Object Types

With Object Types things are different. When we assign an object to a variable, the variable is given a reference to that value. This reference stores the address to the location of that value in memory(techically more than that but let's simplify). So the variable doesn't has the value itself.

Let's imagine the variable, the value it stores, the address in memory and the object in the comming snippets:



let cars = ["tesla"]

// Variable - Value                 - Address - Object
// cars      - <#001> (The reference) - #001    - ["tesla"]

This way, when we assign this variable to another one we are giving it the reference for the object and not copying the object itself like it happens with the primitive value. Thus, objects types are "copied by reference".



let cars = ["tesla"]
let newCars = cars

// Variable  - Value                 - Address - Object
// cars      - <#001> (The reference) - #001    - ["tesla"]
// newCars   - <#001> (The reference stores the same address)

cars = ["tesla", "audi"]

// Variable  - Value                 - Address - Object
// cars      - <#001> (The reference) - #001    - ["tesla", "audi"]
// newCars   - <#001> (The reference stores the same address)

console.log(cars) // ["tesla", "audi"]
console.log(newCars) // ["tesla", "audi"]

Both of them have references to the same array object. So when we modify the object from one of the variables the other will also have this change.

2. Comparison

Understanding the differences of what is stored in variables when dealing with primitive and object types is crucial to understand how we can compare them.

Primitive Types

Using the strict comparison operator ===, if we compare two variables storing primitive values they are equal if they have the same value.



let year = 2021
let newYear = 2021

console.log(year === 2021) // True
console.log(year === newYear) // True

However, if we compare two variables which were assined Object Types, we are actually comparin two references instead of their objects. So they are equal only if they reference the exactly same object.



let cars = ["tesla"]
let newCars = ["tesla"]

console.log(cars === newCars) // False
console.log(cars === ["tesla"]) // False

// Now we copy the reference of cars to newCars
newCars = cars
console.log(cars === newCars) // True

Even though, in the beginning of the code snippet we were working with the same content in the arrays the variables didn't have the same references, they had references to different array objects in memory. However, after we copied the reference to newCars, since now they are "pointing" to the same object the evaluation is True.

So, to compare objects we cannot simply use the === operator because even though they might have the same properties they may not reference the same object. There are some ways to do that and so I'd recommend you to read this article.

3. Passing to functions

When we pass primitive or object types to functions it's like we are copying their values/references to the functions parameters as if we were assigning them with =.

Since we have seen that when we assign them to new variables we are either copying their value(for primitive types) or reference(for object types), it's easier to understand what happens with functions and their outside scope.

Primitive Types

When we are passing Primitive Types to functions we're copying their values to the functions parameters so it doesn't affect the initial variable in the outside scope.



let year = 2021
function getYearWithoutCovid (freeYear) {
    freeYear = 2022
    return freeYear
}

const newYear = getYearWithoutCovid(year)
console.log(year) // 2021
console.log(newYear) // 2022

Passing year to the function, we are copying its value to the function parameter(freeYear will be 2021) so the original variable is not affected.

Object Types

With Object Types, we are copyin their references when passing them as functions parameters. So, if we change the object inside the function this will also be seen in the outside scope.



let person = { name: "Paul", status: "unemployeed" }
function getAJob (person) {
    person.status = "employeed"
    return person
}

const newPerson = getAJob(person)
console.log(person) // { name: "Paul", status: "employeed" }
console.log(newPerson) // { name: "Paul", status: "employeed" }

When we pass person to the function, we are copying its reference to the function parameter, not its object value. Changing it inside the function will affect the initial object in the outside scope since both variables have references to the same object.

That's why its recommended to use Pure Functions in this case (which are not in the scope of this article but I encourage you to search about it <3). We then create a local copy of that person inside the function and modify it instead of the object passed.

Conclusion

I hope that with this article you could understand a little bit more about the data types in Javascript and could also learn the key differences between them.

I just tried to share what I learned while reviewing these concepts so there are more things to add but I thought this was an educational way to explain. If you have things to add and discuss leave a comment :) If it helped you somehow leave a heart <3

Also, follow me on Twitter if you want, might share nice things there too :)

References

One practical difference between Component syntax and Component() in React with useState()

Rafael Leitão — Mon, 25 Jan 2021 01:14:53 +0000

Hello, everyone!👋

While coding a small component yesterday, what initially would just be a simple useState() turned into an interesting discover about React components creation.

My intention was just to render a component by calling it as a function, since it seemed easier in my particular case. However, React wanted me to tell otherwise! And I got a Error: Rendered more hooks than during the previous render.

After doing a little research, I found out that I simply needed to change how I created the component to use it with the component syntax <Component /> instead of Component().

So, the TLDR is:

Don’t call Hooks from regular JavaScript functions, only from React function components.
Use the component as <Component /> instead of calling it like a function Component()

Okay, if you were here to grab the tip you are free to go! But if you want to understand a little bit more about why it is like this then keep on reading :)

1. Only Call Hooks from React Functions

This is one of the two rules React advise/requer us to follow when using Hooks. You can read more about the rules in the docs, but this rule states that we can either:

Call Hooks from React function components.
Call Hooks from custom Hooks.

And the tip in this post resolves around this first option. When we create a component not using the <Component /> syntax, we are not calling it as a React function but as a normal Javascript function instead. But, what is the difference?

When we call a component like Component(), we are not creating any React Element and simply returning the JSX.Element from the function call(after doing the whole logic before this).
When we create a component like <Component />, we are calling React.createElement(Component, {}) which actually creates a React Element.

And that is the key. But to understand it we should know about another concept before, the React Fiber. The React Fiber architecture is a reimplementation of React's core algorithm to deal with reconciliation and re-rendering. A fiber represents a unit of work and its structure, in simple terms, is a JavaScript object that contains information about a component, its input, and its output. To learn more about you can check this README.

So when we call Component(), the state/useState is associated with the parent fiber since we're not creating a React Element. However, when we use <Component />, React.createElement will be called creating a new fiber (the component itself) the state/useState will be associated with.

Calling Component() is like directly putting the whole body and return of the function into the parent component, inlining it to the parent. Then its state and useState() is associated with the parent since Component is not being rendered as a component. At least it was how I understood. That alone is not a problem, but let's consider the example below to understand how it can lead to a Rendered more hooks than during the previous render. error.



import React from "react"

const Counter = () => {
  const [counter, setCounter] = React.useState(0)

  return (
    <div>
    <div>This is my counter: {counter}</div>
    <button onClick={() => setCounter(counter+1)}>Increment</button>
    </div>
  )
}

const App = () => {
  return (
    <div className="App">
      <Counter />
    </div>
  )
}

export default App

Just a simple App component with Counter component in it. The Counter has a useState() to handle its own counter value and its update when the user clicks the button. In this simple case, in practice, there would be no difference between using <Counter /> or Counter(). However, if we look into the React Devtools to check what React is doing we see a difference when changing from one way to another.

<Counter />

Counter()

When using <Counter />, React actually creates an Element inside the App component but when we call Counter() it doesn't create. Then, in the first case, the Counter information is associated with its component but in the second it is associated with the App component. Which hasn't been a problem so far... But let's add a button that will show or hide the Counter component:


 javascript

... Same code as before but changing the App component:

export default function App() {
  const [show, setShow] = React.useState(false)
  return (
    <div className="App">
      <button onClick={() => setShow(prevShow => !prevShow)}>Toggle show</button>
      { show && <Counter />}
    </div>
  );
}

If we use it like this it's okay! However, if we create the Counter calling as Counter(), when we click the button to show the component we get:

And looking at the console from the browser:

What does this "order of the Hooks" mean and why its important?

2. Order of the Hook calls

There is another rule when using Hooks: Only Call Hooks at the Top Level. Taken from the docs:

Don’t call Hooks inside loops, conditions, or nested functions. Instead, always use Hooks at the top level of your React function. By following this rule, you ensure that Hooks are called in the same order each time a component renders. That’s what allows React to correctly preserve the state of Hooks between multiple useState and useEffect calls.

So, we need to understand that React only works with multiple State and Effect hooks in a single component because it relies on the fact that the order of the Hook calls should always be the same in every render.

And, as the console error shows, that is NOT what is happening in our example. The order of the hook calls in the App component is changing somehow. From the console, we see that in the previous render the hook called was only one useState, then after turning show to true, in the next render, there were actually two useState hooks being called. The first useState was the one handling the show in the App and the second was the one handling the counter from its child component.

As we didn't create a React Element, calling Counter() it's just like directly putting the whole body of the Counter component inside its parent and associating its state/useState() to the App component. This way, it added a useState call(from the Counter) to App and this changed its order since it didn't have this second hook before. That's why we have this error. Or at least, what I understood what caused this error.

To fix that, we could simply create the Counter component with <Counter />. From that, we take that instead of calling a functional component we'd better use the component syntax to render it. This will prevent us from having unexpected behaviours.

3. Conclusion

Instantiating a functional component either calling the function, Component(), or using the component syntax, <Component />, will produce the same result in the end. However, for some cases, such as using Hooks inside the component, it's important to know the difference to how React generates the JSX.Element the component returns.

Of course, you can call the component like a function but keep in mind that when using Hooks you should use it with the Component syntax to avoid any unexpected behaviours or the Rendered more hooks than during the previous render. error.

Also, remember that this article was written based on what I understood from what I found in the internet but it may not be 100% accurate! Since I didn't find many articles about this, I just wanted to share my understanding in case it helps. So if you know more about this and can add to the discussion feel free to leave a comment. Was the understanding behind this article correct? What are your thoughts? :)

4. References

This article would not be possible without other articles from awesome developers out there. If you want check what helped my learning, click on the links below:

https://kentcdodds.com/blog/dont-call-a-react-function-component
https://stackoverflow.com/questions/46965309/react-functional-component-calling-as-function-vs-as-component
https://medium.com/@jonchurch/how-to-fix-react-error-rendered-fewer-hooks-than-expected-e6a378985d3c
https://reactjs.org/docs/hooks-rules.html

Understanding Tagged Template Literal in JS

Rafael Leitão — Sat, 16 Jan 2021 18:51:41 +0000

Hello everyone! 👋

Recently, I have been building some components around using the styled-component library and I was curious about how it worked behind the curtains, specially because of the use of backticks (``) to create the components. Looking at the library docs, I found a link to this awesome article The magic behind 💅 styled-components,written by Max Stoiber, and learned that Tagged Template Literals are a essencial to it.

So, I decided to understand a bit more about it, to try to mock its behaviour with some components I built and to share what I learned here, in case it will be useful for anyone in the future.

Okay, but first: What is Template Literal?

Template Literals

The ES6 introduced the template literals which are a new way to create strings allowing embedded expressions, string interpolations, multiline strings and HTML templates. To use it, we use backticks (``) instead of single or double quotes as in regular strings.

It can contain placeholders, specified by the ${}, that take any valid Javascript expression inside it to make string substitution with the result.

Comparing to the "old" way, this give us handy benefits like:

// They all produce the same result
const firstName = 'Jonh'
const lastName = 'Doe'

console.log('My name is ' + firstName + ' ' + lastName)
console.log(`My name is ${firstName} ${lastName}`)

const oldMultiline = 'I want the\nold two lines!'
const newMultiline = `I want the
new two lines!`

console.log(oldMultiline)
console.log(newMultiline)

Cool, but what about the Tagged Template Literals?

Tagged Template Literals

They are a more advanced form of template literals which allow us to parse template literals with a function, giving us more control over how we want this string to be parsed.

The Tagged in the name is because the template literal was "tagged" with the function, which is now called the tag function. To have a Tagged Template Literal, we simply call a function with the template literal after the function name but without parentheses.


const tagFunction = (sentence) => console.log(sentence)

// Tagged function call
tagFunction`This template literal has been tagged`

// Normal function call
tagFunction(`This template literal has NOT been tagged`)

But from there, we start seeing the differences from a normal function call. The function itself is just like any other, but what it receives as parameter is different depending on whether we call it as a tagged template literal or not.

When calling as tagged template literal, the tag function will receive an array of strings from the template literal as its first argument instead of the string itself.

Okay, fair enough... but what if we have an ${} with an expression in the template literal?

This is when it gets interesting!

Tagged Template Literals with embedded expressions

When we add embedded expressions in the template literal and pass it to the function as tagged template literal, we get more parameters depending on how many expressions we passed. In this case, the first parameter will be an array of strings spliced based on the expressions positions in the template string and the remaining parameters will be the evaluated expressions.
Hhmm, sounds a bit complicated, right? Let's see how it is not in the snippet below:


const tagFunction = (sentenceParts, firstName, lastName, age) => console.log(sentenceParts, firstName, lastName, age)

const firstName = 'Jonh'
const lastName = 'Doe'
const age = 36

// Tagged function call
tagFunction`My first name is ${firstName} and last name is ${lastName} and I am ${age - 9} years old.`

// Normal function call
tagFunction(`My first name is ${firstName} and last name is ${lastName} and I am ${age - 9} years old.`)

As you can see from the logs, when calling as tagged template literal, the tagFunction receives the first parameter as the array of strings and the other parameters as the ${expression} already evaluated. Also note that, when calling tagFunction as a normal function we only get the first argument, with the embedded expressions evaluated, since we don't pass any other.

Since we may not know how many embedded expressions it's going to be passed to our tagFunction, it's recommended that we use the rest operator to gather all the remaining parameters in an array.


// It produces the same log as the previous tagged template literal call
const tagFunction = (sentenceParts, ...separations) => console.log(sentenceParts, ...separations)

Example

Just to finish with a closer example of a real use we can see the example below. The toUpper function receives the strings array and the embedded expressions and returns the expressions with upper case letters.


const toUpper = (sentenceParts, ...expressions) => {
    const parsed = sentenceParts.reduce((previous, current, i) => {
        return `${previous}${current}${expressions[i] ? expressions[i].toUpperCase() : ''}`
    }, '')
    return parsed
}

const firstName = 'jonh'
const lastName = 'doe'

toUpper`My name is ${firstName} ${lastName}`

// This produces => "My name is JONH DOE"

Conclusion

Tagged Template Literals are a powerful feature that give us another option on how to parse strings in different ways. With them, the tag function receives the parts of the template literal as the first argument and the embedded expressions as subsequent arguments so then you can decide how to determine the final output of your string.

This features is so powerful that some awesome libraries were built on it such as Styled Components and graphql-tag.

That's it! Hopefully this article was helpful for you to undestand a bit more about Tagged Template Literals.

References

This post would not be possible without other articles from awesome developers out there. If you want check what helped my learning, click on the links below:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
https://www.alura.com.br/artigos/tagged-template-literals
https://developers.google.com/web/updates/2015/01/ES6-Template-Strings
https://dev.to/atapas/what-exactly-is-javascript-tagged-template-literal-1h7f
https://dev.to/joelhassan/js-tagged-template-literals-26ff
https://dev.to/kannndev/tagged-template-literals-bii
https://nipher.io/es6-template-literals/
https://css-tricks.com/template-literals/
https://wesbos.com/tagged-template-literals

Using refs in React functional components (part 3) - instance-like variable

Rafael Leitão — Sun, 10 Jan 2021 00:02:45 +0000

Hello everyone! 👋

For this last part of the series I will show another use of useRef which is not so common but can be handy at times.

One such case could be when you want to keep track of whether a component is mounted when using hooks.. However, as when using refs in general, updating a ref is a side effect so it should be done only inside a useEffect (or useLayoutEffect) or inside an event handler.

So, keep in mind that this post only demonstrates another use of the useRef() hook but you should reason if it would be the best approach to solve your problem. Hopefully, it will be another alternative for us to have in our toolbox :)

If you want to check, I also put the code for these examples on github.

Okay okay, let's see this case :)

1. Creating mutable instance-like variables

As the docs states, the ref object is a generic container whose current property is mutable and can hold any value, similar to an instance property on a class.

How is it similar?
In a class component, we can define instance variables in it and when there is a re-render the render method is executed again.

However, a functional component does not have a render function, the component itself, with everything defined in it being the render function which returns a JSX in the end. Thus, when there is a re-render the whole code in the functional component is executed again and if we have variables inside it will be initialized again with the default value.

Consider this example below. When we click on a button, this increments a counter set with useRef and with a local variable in the functional component:



import React, { useState, useRef } from 'react';

const SimpleValueRef = () => {
    const [show, setShow] = useState(false);
    let count = 0;
    let refCount = useRef(0);

    const increment = () => {
        refCount.current++;
        count++;
        console.log('The count: ', count);
        console.log('The refCount: ', refCount);
    };

    const showCounter = () => setShow(true);

    console.log(`Rendering SimpleValueRef with ref ${refCount.current}, without ref ${count}`)
    return (
        <div>
            <button onClick={increment}>Click to increment!</button>
            <button onClick={showCounter}>Show counter</button>
            {show && <p>Times you clicked on button: with ref {refCount.current}, without ref {count}</p>}
        </div>
    )
};

As you can see in the console logs, every time we click on the first button both the count variable and refCount current property are updated and since there is no re-render both have the same value. When we click on the second button, we make a state change with the setShow function and this makes the functional component to re-render. All the code inside is executed again setting count variable to its initial value, 0, but the current property of refCount keeps the value as before.

From the docs:

This works because useRef() creates a plain JavaScript object. The only difference between useRef() and creating a {current: ...} object yourself is that useRef will give you the same ref object on every render.

This way, we see that with useRef we could have a property similar to an instance variable in a class but with a functional component thanks to the ref staying around over the lifetime of the component.

However, keep in mind that this was an example just to illustrate this use of refs in React. We could simply use a state to keep the counter updated and even though it would make the component re-render every time it would not be an issue in this case. There is also an easter egg with a problem related to React’s reconciliation technique( which hopefully I will make an article about to explain it with this example and to understand it more).

2. Conclusion

And that’s it! Hopefully this series was helpful to others always learning React just like me and that it made you understand a bit more about the uses of Refs in functional components.

If you have any questions or want to complement with something, feel free to comment below. Since these are my first posts, I’m looking forward to any feedback as well :)

3. References

This series would not be possible without other articles from awesome developers out there. If you want check what helped my learning, click on the links below:

https://medium.com/trabe/react-useref-hook-b6c9d39e2022
https://www.codementor.io/@dhananjaykumar/useref-hook-as-mutable-ref-object-ykb77fwvk
https://reactjs.org/docs/hooks-faq.html#is-there-something-like-instance-variables
https://www.robinwieruch.de/react-ref
http://naomiajacobs.com/useRef-vs-useState/

Using refs in React functional components (part 2) - forwardRef + useImperativeHandle

Rafael Leitão — Sun, 10 Jan 2021 00:02:34 +0000

Hello everyone! 👋

Continuing the series about refs in functional components, in this article we will cover another case we need refs: when accessing other functional components.

For this article we will understand a bit more about Ref Forwading and useImperativeHandle, an extra hook that lets us customize the ref the parent component will have access.

If you want to check, I also put the code for these examples on github.

So let's jump into that!

1. Accessing functional components with refs

In all the previous examples, in the first part of this series, we needed to access a DOM element in the same component, but what if we need to access an element from a child component, how would we do that?

1.1 Ref forwarding

As stated in the docs, React components hide their implementation details, including their rendered output. Thus, components cannot easily access refs from their children.

Although this is a good thing, preventing us from relying on other component’s DOM structures, there are cases where we need to access a child’s DOM node for managing focus, selection and animation, for example.

To do that, React provides a feature called Ref Forwarding.

Ref forwarding is an opt-in feature that lets some components take a ref they receive, and pass it further down (in other words, “forward” it) to a child.

To understand it, let's consider a simple example where a parent component wants to have a ref to a child’s input to be able to select its text when clicking on a button:

import React from 'react';

type ForwardedInputProps = {
    placeholder?: string
};

const ForwardedInput = React.forwardRef<HTMLInputElement, ForwardedInputProps>(({ placeholder }, ref) => (
    <input ref={ref} placeholder={placeholder} />
));

const SimpleForwardRef = () => {
    const inputRef = React.useRef<HTMLInputElement>(null);

    const selectText = () => {
        inputRef.current?.select();
    }

    return (
        <div>
            <ForwardedInput ref={inputRef} placeholder="Type here"/>
            <button onClick={selectText}>Select text</button>
        </div>
    );
};

As you can see, we created a ref object with useRef in the parent component and passed it to the child component. In the ForwardedInput component we call the React.forwardRef function, which receives props and the ref passed to the functional component and returns the JSX.Element for it.
ForwardedInput uses the React.forwardRef to obtain the ref passed to it, so we can forward the ref down to the DOM input. This way, the parent component can get a ref to the underlying input DOM node and access it through its inputRef current property.

One important point to note is the typing in the React.forwardRef. As a generic function, it receives type parameters for the ref and the props but in the reversed order from its function parameters. Since we attached the forwarded ref to an its type will be HTMLInputElement.

1.2 useImperativeHandle

In some more advanced cases you may need to have more control over the returned ref the parent will have access to. Instead of returning the DOM element itself, you explicitly define what the return value will be, adding new properties for the returned ref, for example.

In such cases you would need to use a special hook, the useImperativeHandle. As stated in the docs:

useImperativeHandle customizes the instance value that is exposed to parent components when using ref. As always, imperative code using refs should be avoided in most cases. useImperativeHandle should be used with forwardRef:

Let’s understand it a bit better. Consider the following example where when the user clicks the button associated with the box it scrolls to the top of the box.

import React, { useRef, forwardRef, useImperativeHandle } from 'react';

type BoxProps = {
    size: string,
    color: string
}

type IncrementedRef = {
    getYLocation: () => number | undefined,
    current: HTMLDivElement | null
}

const Box = forwardRef<IncrementedRef, BoxProps>(({size, color}, ref) => {
    const divRef = useRef<HTMLDivElement>(null);
    useImperativeHandle(ref, () => ({
        getYLocation: () => divRef.current?.getBoundingClientRect().top,
        current: divRef.current
    }));

    return (
        <div style={{
            height: size,
            width: size,
            backgroundColor: color,
            margin: '0 auto'
        }}
        ref={divRef}></div>
    );
});

const ImperativeHandleExample = () => {
    const refs = [useRef<IncrementedRef>(null), useRef<IncrementedRef>(null), useRef<IncrementedRef>(null)];

    const goToBox = (position: number) => {
        console.log('Go to box: ', refs[position].current?.current)
        const boxTop = refs[position].current?.getYLocation();
        window.scrollTo({ top: boxTop, behavior: 'smooth'})
    }

    return (
        <>
        <div>
            <button onClick={() => goToBox(0)}>Go to 1st box</button>
            <button onClick={() => goToBox(1)}>Go to 2nd box</button>
            <button onClick={() => goToBox(2)}>Go to 3rd box</button>
        </div>
        <Box size='500px' color='red' ref={refs[0]} />
        <Box size='500px' color='blue' ref={refs[1]} />
        <Box size='500px' color='green' ref={refs[2]} />
        </>
    );
};

Here, the Box component is wrapped with a forwardRef since we are receiving a ref from the parent. But instead of attaching it to the <div>, we are explicitly changing its return to the parent with the useImperativeHandle and attaching a new internal ref to the <div>.
Why so complex? Because we want to provide the ref to the parent component with the coordinate of the top of this <div>.

Since we want more control over what properties the parent will access from the ref we have the useImperativeHandle to set this new getYLocation function and the <div> as its current property. The getYLocation could simply be the value but I put as function to exemplify another way to a have a property.

Remember that with useImperativeHandle you have to explicitly state what the return of the ref will be. It won't contain any other property so if you didn't set it as the current property you wouldn't have access to the <div> itself in the parent component.

So, in the parent component we create refs and forward it to each Box component. When the user clicks on each button it will call goToBox() and with its position parameter we get the corresponding ref in the array of refs. Then, with the getYLocation function we defined with useImperativeHandle we have the Y coordinate of its top and scroll to it. The console.log prints the <div> from the ref’s current property to show that this way we have access to the element.

One last point is the typing again. The ref type passed to the forwardRef function is not a HTMLDivElement because with the useImperativeHandle we are creating a new return to be the ref and this new ref has only the getYLocation and current properties.

2. Conclusion

As shown in the above examples, you can also access underlying DOM elements from children functional components with the Ref forwarding feature. For more advanced cases, you can even customize what the parent component will have access with the ref passed to its children with the useImperativeHandleeven though, as stated in the docs, imperative code using refs should be avoided in most cases.

If you've came this far, I would really appreciate any feedback or comments pointing any corrections you would suggest. Hopefully this will be helpful to you :)

Also, there is one more article to finish this series where we will see how to use refs in functional components to have something like instance variables. If you want to check that out :)

3. References

This series would not be possible without other articles from awesome developers out there. If you want check what helped my learning, click on the links below:

https://reactjs.org/docs/forwarding-refs.html
https://reactjs.org/docs/hooks-reference.html#useimperativehandle
https://moduscreate.com/blog/everything-you-need-to-know-about-refs-in-react/
https://blog.logrocket.com/how-to-use-react-createref-ea014ad09dba/
https://www.carlrippon.com/react-forwardref-typescript/
https://stackoverflow.com/questions/57005663/when-to-use-useimperativehandle-uselayouteffect-and-usedebugvalue
https://stackoverflow.com/questions/62040069/react-useimperativehandle-how-to-expose-dom-and-inner-methods

Using refs in React functional components (part 1) - useRef + callback ref

Rafael Leitão — Sun, 10 Jan 2021 00:02:25 +0000

Hello everyone! 👋

Lately, I have been working a bit with refs in functional components and decided to go beyond the surface and dig a little deeper into it. Also, I decided to start writting as a way to improve my knowledge since you don't really understand something until you explain it.

That's how the idea of this series came! It won't be any complete guide of the Ref API but rather an overview of it based on what I understood while studying it to be more confident when using it in the future.

Since these are my first articles any feedback will be valuable. Hopefully, it will be helpful to you too.

If you want to check, I also put the code for these examples on github.

Without further ado, let's go!

1. What are refs?

Refs are simply references to anything, like a DOM node, Javascript value, etc. To create a ref in a functional component we use the useRef() hook which returns a mutable object with a .current property set to the initialValue we passed to the hook.



const ref = useRef(null); // ref => { current: null }

This returned object will persist for the full lifetime of the component. Thus, throughout all of its re-rendering and until it unmounts.

There are basically two use cases for refs in React:

Accessing underlying DOM nodes or React Elements
Creating mutable instance-like variables for functional components

In the following sections and next posts I will try to cover some use cases with examples of common scenarios.

2. Accessing DOM nodes in the same React component

To create a reference to a DOM node in a component we can do it either using the useRef() hook, which for most cases is the easier and best approach, or using the callback ref pattern which gives you more control when refs are set and unset.

Let’s see how they compare in an example where there are two buttons, one which sets focus on the input and another which logs the value the user typed in the input.

2.1 useRef()



import React, { useRef } from 'react';

const SimpleRef = () => {
    const inputRef = useRef<HTMLInputElement>(null);

    const onClick = () => {
        console.log('INPUT VALUE: ', inputRef.current?.value);
    }

    const onClickFocus = () => {
        console.log('Focus input');
        inputRef.current?.focus();
    }

    return (
        <div>
            <input ref={inputRef} />
            <button onClick={onClick}>Log value</button>
            <button onClick={onClickFocus}>Focus on input</button>
        </div>
    );
};

The useRef<HTMLInputElement>(null) returns an { current: null } object initially since we provided null as the initialValue. After we associate it to the <input>, with its ref attribute, we can access the HTMLInputElement and its properties through the .current property of the ref.

With that, when the user clicks the first button we log the input value the user typed and when he/she clicks in the second button we call the focus() method from the <input> element.

Since in this project I am using Typescript we have to set the type of the ref we are storing. As we are putting the ref on an <input>, we define it as a HTMLInputElement and use the optional chaining to prevent an error while accessing the properties of the ref.

2.2 Callback Ref

This is another way React supports to set refs. Instead of passing a ref attribute created by useRef(), you pass a function. As stated in the docs, the function receives the React component instance or HTML DOM element as its argument, which can be stored and accessed elsewhere.

There is a small difference when creating the same example with a callback ref .



const SimpleCallbackRef = () => {
    let inputRef: HTMLInputElement | null;

    const onClick = () => {
        console.log('INPUT VALUE: ', inputRef?.value);
    }

    const onFocusClick = () => {
        console.log('Focus input');
        inputRef?.focus();
    }
    console.log('Rendering')
    return (
        <div>
            <input ref={node => { inputRef = node; }} />
            <button onClick={onClick}>Log value</button>
            <button onClick={onFocusClick}>Focus on input</button>
        </div>
    );
};

We simply set the ref attribute in the <input> with a function instead of ref attribute created by useRef(). This function receives the DOM node and assigns it to the inputRef we declared before. Since we didn't create a ref with useRef the inputRef variable stores the DOM element itself then we don't need to access the .current property, as you can see in the onClick and onFocusClick functions.

However, note that we start by setting the type of inputRef as either a HTMLInputElement or null.

Why was that? This is due to a caveat when using callback ref. As stated in the docs: when it’s defined as an inline function, it will be called twice on updates, first with null and then again with the DOM element.

So Typescript warns that the inputRef variable can be null(since the node also can be) then after typing like this Typescript won't complain.
To deal with this caveat, in this example, we can either do this or ensure that we will only assign the node to the inputRef when the node is valid:



let inputRef: HTMLInputElement;
// ... the same code
<input ref={node => { 
    console.log('Attaching node: ', node)
    if (node) { // with this we know node is not null or undefined
        inputRef = node;
    }
}} />

This example was only made to illustrate the difference between how to use the callback ref and useRef. In such a simple case, using callback ref only gives us unnecessary work so I would go with useRef().

2.3 The callback ref pattern caveat

Still on this caveat and how to deal with it. Getting it straight from the docs:

If the ref callback is defined as an inline function, it will get called twice during updates, first with null and then again with the DOM element. This is because a new instance of the function is created with each render, so React needs to clear the old ref and set up the new one. You can avoid this by defining the ref callback as a bound method on the class, but note that it shouldn’t matter in most cases.

To illustrate this callback ref caveat better, see the example below:



import React, { useState } from 'react';

const SimpleCallbackRefRerender = () => {
    let inputRef: HTMLInputElement;
    const [count, setCount] = useState(0);

    const onClick = () => {
        console.log('INPUT VALUE: ', inputRef?.value);
    }

    const onFocusClick = () => {
        console.log('Focus input');
        inputRef?.focus();
    }

    const onRerenderClick = () => {
        console.log('Clicked to re-render');
        setCount(count+1);
    }

    return (
        <div>
            <input ref={node => { 
                console.log('Attached node: ', node)
                if (node) {
                    inputRef = node;
                }
             }} />
            <button onClick={onClick}>Log value</button>
            <button onClick={onFocusClick}>Focus on input</button>
            <button onClick={onRerenderClick}>Re-render count {count}</button>
        </div>
    );
};

As you can see in the logs, when first rendering, the callback ref had the HTMLInputElement node to be passed to the ref attribute of the <input>. However, when clicking on the button to re-render, the node was first null and then it was the actual element again.

This happens because when the component is being re-rendered it first unmounts then React calls the callback ref passing null to it to clear the old ref and when it mounts again then React calls the callback ref with the DOM element. To deal with that, in the callback ref we can check whether the node is not null/undefined and then assign to the inputRef variable, as we did.

3. Accessing dynamically added DOM elements

Cool, I got that! But why am I going to use callback ref?
Well, even though there is the useRef() hook which covers most of the common cases we would need for a ref, the callback ref pattern provides us with a more powerful way to have control for cases when a child is being added or removed dynamically, does not have the same lifetime as the parent or you need to perform any effect when a ref has been mounted.

Let’s consider a simple example where part of a form only appears when the user clicks in the first button and we when it happens we want the newly shown input to be focused.



import React, { useState, useRef } from 'react';

const CallbackRefDynamicChild = () => {
    const inputRef = useRef<HTMLInputElement>(null);
    const [visible, setVisibility] = useState(false);

    const onClick = () => {
        console.log('INPUT VALUE: ', inputRef.current?.value);
        setVisibility(true);
    }

    const onFocusClick = () => {
        console.log('Focus on first input');
        inputRef.current?.focus();
    }

    const callbackRef = (node: HTMLInputElement) => {
        console.log('Attached node: ', node);
        if(node) {
            node.focus();
        }
    }

    console.log('Rendering: ', inputRef);
    return (
        <div>
            <input ref={inputRef} />
            <button onClick={onClick}>Unlock next input</button>
            {visible && (
                <>
                <input ref={callbackRef} />
                <button onClick={onFocusClick}>Focus on first input</button>
                </>
            )}
        </div>
    );
};

Since the second input is added dynamically, when the state changes and the visible variable is set to true, the best approach for this is using the callback ref.

The useRef doesn’t notify you when its content changes. Mutating the .current property doesn’t cause a re-render. Therefore, to run any effect when React attaches or detaches a ref to a DOM node, we would need to use the callback ref.

With callback ref, when the second input shows up and the ref is attached to the <input>, the callbackRef function is called with the HTMLInputElement. Then if the node is not null/undefined we call the focus() method to achieve what we wanted.

4. Conclusion

In this first part of the series, we covered possible ways to use refs in functional components for the case where we want to access DOM nodes in the same component.

In the next posts we will see how to use refs to access other React components and also to have an instance-like variable in functional components.

If you've came this far, I would really appreciate any feedback or comments pointing any corrections you would suggest. Hopefully this will be helpful to you :)

5. References

This series would not be possible without other articles from awesome developers out there. If you want check what helped my learning, click on the links below:

https://moduscreate.com/blog/everything-you-need-to-know-about-refs-in-react/
https://blog.logrocket.com/how-to-use-react-createref-ea014ad09dba/
https://www.robinwieruch.de/react-ref
https://medium.com/trabe/react-useref-hook-b6c9d39e2022
https://elfi-y.medium.com/react-callback-refs-a-4bd2da317269
https://linguinecode.com/post/how-to-use-react-useref-with-typescript
https://reactjs.org/docs/refs-and-the-dom.html

DEV Community: Rafael Leitão

Articles you may have missed last week but it's worth reading 👍

The list 📝

1. [Storyblok, Gatsby] Programmatically create blog post pages from data

[Storyblok, Gatsby] Programmatically create blog post pages from data

Arisa Fukuzaki ・ May 20 '21

2. NextAuth.js Intro [3 of 3]: Adding Access Control

NextAuth.js Intro [3 of 3]: Adding Access Control

Mike Cavaliere ・ May 21 '21

3. Implementing a Social Share Feature

Implementing a Social Share Feature

Daniel Sasse ・ May 20 '21

4. Remote Onboarding as a Software Engineer

Remote Onboarding as a Software Engineer

Ben ・ May 20 '21

5. Creating an Accordion Component in React with Typescript and TailwindCSS

Creating an Accordion Component in React with Typescript and TailwindCSS

Bionic Julia ・ May 22 '21

6. Sustainable string enums in Typescript

Sustainable string enums in Typescript

Alexis Moody ・ May 18 '21

That's it! ✌️

Articles you may have missed this week but it's worth reading 👍

The list 📝

1. Tips for frontend devs on how to better approach coding designs

How to code designs better - tips for FE devs

Joanna Otmianowska ・ May 2 '21

2. On Becoming A Better Junior Developer

On Becoming A Better Junior Developer

Nicholas Mendez ・ May 6 '21

3. App 101: Jamstack vs Traditional Webapps

App 101: Jamstack vs Traditional Webapps

Zack Sheppard ・ May 4 '21

4. 7 Approaches I Took While Learning Web Dev From Scratch

7 Approaches I Took While Learning Web Dev From Scratch

mmiask ・ May 4 '21

5. Everything you need to know about Styled Components

Everything you need to know about Styled Components

Paul Ccari ・ May 4 '21

6. State and setState Explained with Emotion

State and setState Explained with Emotion

Shaundai Person ・ May 3 '21

That's it! ✌️

Automate components creation in React project

What is Plop.js?

How to use it?

1. Installation

2. Create a Plop file

3. Create a template file with Handlebars

Real usage example

1. Creating a Plopfile

2. Creating the templates

1. index.tsx

2. stories.tsx

3. Run the plop command in a package.json script

Conclusion

What I've learned using Chakra-Ui so far

1. Creating a custom theme is a breeze

2. Creating variants of components makes it easier to implement a design system

3. Integrating with Storybook is not so smooth currently

4. We can't create variants for Box but we can use Layer Styles or Text Styles

Conclusion

De volta ao básico: Tipos Primitivos e Objetos em Javascript

Tipos do Javascript

Tipos primitivos

Tipos de objeto

Diferenças entre os tipos

1. Atribuindo a uma variável e copiando o valor

Tipos primitivos

Tipos de objeto

2. Comparação

Tipos primitivos

3. Passando para funções

Tipos primitivos

Tipos de objeto

Conclusão

Referências

Back to the basics: Primitive and Object types in Javascript

Javascript Types

Primitive Types

1. `index.tsx`

2. `stories.tsx`