L’ineluttabile React Eject: lo temi, lo eviti. Il destino arriva comunque.

Create React App e l’ineluttabile Eject: come e perché evitarlo

L’ineluttabile Eject di React (Infinity Gauntlet Edition)

Cos’è CRA?

CRA, acronimo di “Create React App”, è uno strumento ideato dagli sviluppatori di Facebook per fornire una serie di strumenti “pronti all’uso”, ovvero già configurati per poter essere utilizzati al fine di creare nuove applicazioni React.

Non è necessario, infatti, installare e configurare strumenti come Webpack o Babel dato che sono già preconfigurati e nascosti all’interno del progetto.

Lo sviluppatore, in questo modo, deve solo concentrarsi sul “produrre” codice e non deve o può modificare le configurazioni prestabilite dal tool CRA, a meno che non effettui l’eject del progetto.

Cosa significa fare l’eject di un progetto?

Fare l’eject di un progetto significa “tirare fuori” tutte le configurazioni che fino a quel momento erano nascoste allo sviluppatore. Questa operazione, eseguibile soltanto una volta, non è reversibile. Il comando per eseguire l’eject di un progetto è:

npm run eject

Perché fare l’eject di un progetto?

Fare l’eject di un progetto è utile quando è necessario modificare ed estendere le configurazioni di default come Webpack, Babel, ESLint, etc. Tuttavia, da un po’ di tempo a questa parte, è possibile sovrascrivere le configurazioni di default senza l’esigenza di fare l’eject di un progetto. Per questo motivo, mi sento di sconsigliarti questa operazione.

Perché NON fare l’eject di un progetto?

Fare l’eject di un progetto porta con sé una serie di benefici come il “completo controllo”, ma questo è un’arma a doppio taglio.

Il “completo controllo” porterà con sé una serie di “responsabilità”, ossia tutte le dipendenze, le configurazioni, e gli aggiornamenti di essi, che precedentemente erano gestite dal tool CRA, diventeranno una tua responsabilità.

È possibile ovviare a questo problema utilizzando il pacchetto npm react-app-rewired.

Cos’è il pacchetto npm “react-app-rewired”?

Il pacchetto npm react-app-rewired permette di sovrascrivere le configurazioni di Webpack, aggiungendo plugin, loaders e altro senza il bisogno di fare l’eject del progetto, e beneficiare dunque della possibilità di aggiornare tranquillamente il pacchetto “react-scripts” senza problemi.

Come utilizzare “react-app-rewired”?

È possibile utilizzare le funzionalità di “react-app-rewired” in poche e “semplici” mosse. In primis è necessario installarlo, eseguendo il comando npm:

npm install react-app-rewired --save-dev

Dopodiché definire un file chiamato “config-overrides.js”, nella root del progetto, che conterrà le istruzioni per sovrascrivere la configurazione di default, ovvero:

/* config-overrides.js */
module.exports = function override(config, env) {
  //do stuff with the webpack config...
  return config;
}

Ed infine sostituire nel “package.json” gli attuali scripts di “start”, “build” e “test” che utilizzano “react-scripts”, con i nuovi che si avvalgono degli scripts di “react-app-rewired”.

In questo modo, eseguendo lo “start” o la “build” del server (se avremo definito delle logiche nel config-overrides.js) vedremo (si fa per dire) la nostra configurazione sovrascritta.

Cosa posso scrivere nel “config-overrides.js”?

Nel file di override è possibile definire molteplici cose, che non sto qui a raccontarti ma che troverai nel *fantastico* repository GitHub https://github.com/timarney/react-app-rewired (di Tim Arney¹, per un ulteriore approfondimento vedi link).

Per comprendere meglio le potenzialità di questo pacchetto, parleremo di un caso d’uso reale.

Una delle cose con cui uno sviluppatore può scontrarsi, come del resto io stesso, (qualora non si facesse l’eject del progetto CRA) é la definizione degli alias da adoperare quando si indicano gli import e/o i require di moduli o componenti. Ad esempio, nel mio progetto con struttura:

+-- project
|   +-- config-overrides.js
|   +-- node_modules
|   +-- package.json
|   +-- public
|   +-- README.md
|   +-- src
|   |   +-- constants
|   |   |   +-- config.js
|   |   +-- components
|   |   |   +-- Grid.js
|   |   +-- containers
|   |   |   +-- App.js

Se nel file “App.js” volessimo importare il componente “Grid” dovremmo specificare il path relativo, vale a dire importarlo in questa maniera:

import Grid from '../components/Grid';
import config from '../constants/config';
import Componente1 from '../../cartella/Componente1';
import Componente2 from '../../cartella/sottocart/Componente2';

Possiamo immaginare, dunque, che se avessimo avuto altre sottocartelle avremmo dovuto scrivere path relativi più “complessi”, mentre se avessimo dovuto spostare un file saremmo stati obbligati a riscrivere tutti i path relativi dei componenti importati.

Per ovviare a questa cosa è possibile definire degli alias con “react-app-rewired” e “react-app-rewire-aliases”. Nel file “config-overrides.js”, infatti, scrivendo alcune righe è possibile risolvere il problema:

/* config-overrides.js */
const rewireAliases = require('react-app-rewire-aliases');
const {paths} = require('react-app-rewired');
const path = require('path');
module.exports = function override(config, env) {
    config = rewireAliases.aliasesOptions({
        '@src': path.resolve(__dirname, `${paths.appSrc}/`),
        '@containers': path.resolve(__dirname, `${paths.appSrc}/containers/`),
        '@components': path.resolve(__dirname, `${paths.appSrc}/components/`),
        '@constants': path.resolve(__dirname, `${paths.appSrc}/constants/`),
    })(config, env);
    return config;
};

In questo frammento di codice possiamo vedere un oggetto JSON che contiene come chiave l’alias (ad esempio, “@containers”) e come valore il path.

Adesso se volessimo importare di nuovo, all’interno del nostro file “App.js”, i componenti precedenti, dovremmo riscriverli in questa maniera:

import Grid from '@components/Grid';
import config from '@constants/config';
import Componente1 from '@cartella/Componente1';
import Componente2 from '@sottocart/Componente2';

Ora i problemi di path sono risolti (solo quelli però)! Ovviamente questo è un semplice esempio, ma serve per cogliere le potenzialità di una implementazione del genere.

Conclusione

Il consiglio spassionato che sento di darti, in un progetto di grandi dimensioni (ma anche piccolo se vogliamo dirla tutta eh!) che è in continua trasformazione -e dunque oggetto di un ineluttabile refactoring- è che questo “bit” può non salvarci la vita ma almeno aiutarci a sopravvivere.

Ah, quasi dimenticavo! Sicuramente risparmierai tempo.

«Perfettamente bilanciato… come tutto dovrebbe essere.» — Thanos, Avengers Infinity War

Fonti

¹Create React App — But I don’t wanna Eject, Tim Arney, 2016