DEV Community

loading...
Cover image for Como usar variáveis de ambiente sem biblioteca em React

Como usar variáveis de ambiente sem biblioteca em React

reisdev profile image Matheus dos Reis de Jesus ・3 min read

Capa por FLY:D no Unsplash

Já deixou vazar alguma chave de segurança porque subiu alguma alteração e esqueceu de apagar o conteúdo sensível? Usar variáveis de ambiente evita que coisas assim aconteçam. Mas, como elas funcionam no React? Vem comigo!

Sumário

O que são Variáveis de Ambiente

Variáveis de ambiente são um conjunto de valores que geralmente são definidos para configurações de uma aplicação. Exemplos: Dados de conexão com um banco, a URL de uma API e etc.

O termo "Ambientes" se refere à diferentes cenários em que uma aplicação pode estar sendo executada. Os mais comuns são: desenvolvimento, teste, homologação, e produção. Cada um deles pode exigir diferentes configurações, e por isso é feita essa divisão. Você uma variável na aplicação que, em diferentes ambientes, terá valores específicos para aquele cenário.

Como funcionam

Para configurar variáveis de ambiente em uma aplicação React você precisa criar um arquivo na raiz da aplicação com o nome .env. Primeiro, certifique-se de que está na pasta-raiz do seu projeto, onde ficam os arquivos package.json, .gitignore e etc. Se preferir criar por linha de comando, utilize um dos comandos abaixo, de acordo com seu sistema operacional:

# MacOS ou UNIX
cd pasta-do-projeto
> .env

# Windows
cd pasta-do-projeto
type NUL > .env
Enter fullscreen mode Exit fullscreen mode

Agora, você verá o arquivo vazio na pasta-raiz do seu projeto. Para criar uma variável de ambiente, você deve utilizar o prefixo REACT_APP_. Por exemplo: Se você deseja criar uma variável API_URL, ela deve ser nomeada como REACT_APP_API_URL, pois a react-scripts só faz a leitura das variáveis que usam esse prefixo.

Como utilizar

Vamos supor uma aplicação que precise de variáveis de ambiente para usar uma API para usar com o Axios. Não se preocupe com o que é axios e o que API, foque em entender a parte das variáveis. Será preciso configurar a porta, a url base e a versão de uma API. Logo, nosso arquivo .env ficaria da seguinte forma:

# Arquivo .env
REACT_APP_API_BASEURL=https://mydomain.com
REACT_APP_API_PORT=8888
REACT_APP_API_VERSION=v2
Enter fullscreen mode Exit fullscreen mode

E agora, para configurar nossa instância do Axios, podemos utilizar nossas variáveis de ambiente:

// Arquivo axios.js, apenas um exemplo
const url = process.env.REACT_APP_API_BASEURL
const port = process.env.REACT_APP_API_PORT
const version = process.env.REACT_APP_API_VERSION

const api = axios.create({
    baseURL: `${url}:${port}/${version}/`
})

export default api;
Enter fullscreen mode Exit fullscreen mode

E pronto. Nossas variáveis de ambiente estão configuradas e prontas para serem utilizadas em toda a aplicação. Porém, ainda temos dois pontos importantes:

Para evitar que seu arquivo .env seja enviado para um repositório remoto, é importante adicioná-lo ao .gitignore,dessa forma:

# Arquivo .gitignore
# ... outros valores
.env
Enter fullscreen mode Exit fullscreen mode

E, para garantir que outras pessoas saberão configurar as variáveis de ambiente, crie um arquivo .env.example, com as variáveis sem valor definido, dessa forma:

# Arquivo .env.example
REACT_APP_API_BASEURL=https://mydomain.com
REACT_APP_API_PORT=8888
REACT_APP_API_VERSION=v2
Enter fullscreen mode Exit fullscreen mode

Considerações

É importante lembrar que variáveis de ambiente configuradas em containers e ambientes cloud(Heroku, Vercel, Netlify, etc) também são reconhecidas, em tempo de build. Agora que você já sabe disso, não vai mais precisar se preocupar em apagar valore sensíveis toda vez que for fazer algum commit.

Gostou deste artigo? Me siga para mais conteúdos como esse!

Minhas redes sociais:

Twitter | Instagram | Youtube.

Até o próximo artigo!👋🏽

Discussion (4)

Collapse
eduardoklosowski profile image
Eduardo Klosowski

Em ambientes UNIX, o arquivo pode ser criado executando simplesmente > .env, que é até mais rápido que a versão com touch, uma vez que essa última precisa criar um processo, esperar esse processo ser escalonado, rodar, e então voltar ao process do shell, enquanto com > quem cria o arquivo é o próprio shell. Na prática, essa diferença não é tão perceptível, mas pode fazer diferença em shellscripts.

De fato é importante não versionar o .env, colocando-o no .gitignore, por exemplo. Porém se ele já foi commitado, não adianta colocar no .gitignore que só funciona para novos arquivos, então é necessário fazer um commit removendo esse arquivo, e só então ele não será mais versionado. Isso pode pareceber bobo, mas é o motivo da ideia que alguns tem de fazer uma versão iniciar do arquivo sem os dados sensíveis, commitar, e depois alterá-lo tentando colocar no .gitignore não funcionar tão bem, embora a ideia possa ser interessante, um git add . ou git commit -a commitaria o .env sem o desenvolvedor perceber, além de dificultar qualquer alteração como adicionar um novo parâmetro de configuração.

Aproveitando o assunto, eu gosto da discução sobre configuração apresentada pelo 12 factor app.

Collapse
rattones profile image
Marcelo Ratton

eu gosto de versionar o .env.example com os indicativos de configurações que devem ser seguidos, me ajuda muito na hora de subir um ambiente novo seja em produção, homologação ou em outra máquina dev ...

Collapse
reisdev profile image
Matheus dos Reis de Jesus Author

Obrigado por acrescentar ao artigo! Ainda não conhecia essa abordagem do 12 Factor App, achei muito interessante!

Collapse
feliperli profile image
feliperli

Nice!

Forem Open with the Forem app