A Storyly , abbiamo due progetti React molto diversi; uno è "dashboard" e l'altro è "studio".

Questi due progetti differiscono nello scopo e nelle sfide tecniche. La dashboard è un progetto CMS in cui i nostri utenti gestiscono le loro app, istanze, gruppi di storie, impostazioni e integrazioni e visualizzano le loro analisi. Il progetto Studio, invece, è uno strumento di progettazione; consente ai nostri utenti di progettare le loro storie su una tela vuota utilizzando i nostri elementi predefiniti.

A livello tecnico, come indovinerai anche tu, la dashboard contiene molti dati lato server e lo studio è principalmente dati lato client. Quindi, quando classifico, mi concentro sugli scopi dei progetti piuttosto che solo sugli aspetti tecnici.

Noi, come sviluppatori front-end, non dovremmo prendere decisioni tecniche esclusivamente sugli aspetti tecnici. Ci sono così tanti altri aspetti da considerare, tra cui il team, gli utenti attuali e possibili, il futuro previsto del progetto e la cultura aziendale. Tutto ciò avrà un impatto sulle vostre soluzioni tecniche fondamentalmente durante il processo decisionale.

Supponiamo che il tuo compito sia scegliere una soluzione di gestione dello stato per il tuo progetto. Ce ne sono così tanti là fuori, con diversi contro e pro. È sicuro affermare che l'argomento della gestione dello stato nell'ecosistema frontend viene fornito con il maggior numero di soluzioni accanto all'argomento "framework".

Se consideri solo i pro ei contro tecnici, i numeri delle prestazioni, la facilità d'uso della soluzione e forse il numero di commit, stelle e problemi della soluzione sarà ciò che stai controllando. E questi sono tutti punti validi quando si sceglie una libreria.

Quando guardo le soluzioni di gestione dello stato da utilizzare in entrambe le basi di codice da un punto di vista tecnico, sono propenso a utilizzare Zustand o Jotai. Sono ben tenuti, incredibilmente facili da usare e performanti. È stata una decisione facile, vero?

Bene, stavamo usando l'onnipotente Redux in entrambe le nostre basi di codice per gestirne lo stato, e avevo bisogno di semplificare questa parte del progetto perché è diventata più estesa di quanto avrebbe dovuto essere. Era la fonte primaria di molti dei nostri bug. Ho subito pensato "Oh fantastico, dovremmo usare Zustand per entrambi i progetti perché è fantastico!" ma poi ho fatto un passo indietro e ci ho riflettuto un po' di più.

Processo di migrazione

Come ho spiegato all'inizio, i nostri due codebase sono molto diversi.

La dashboard mostra i dati lato server all'utente con modifiche e aggiornamenti molto sottili ai dati lato server. Ci sono molte pagine con dati analitici, elenchi e statistiche calcolate. Anche il futuro di questo progetto sarà simile; una dashboard simile a un CMS con molte statistiche ed elenchi. Quindi avevo bisogno di considerare la memorizzazione nella cache dei dati, l'invalidazione della cache, le cascate di rete, gli aggiornamenti dei dati in tempo reale, gli aggiornamenti ottimistici, ecc. Con questi argomenti in mente, ho deciso che non avevamo bisogno di cambiare la nostra soluzione di gestione dello stato (Redux ); dovevamo semplicemente rimuoverlo dalla dashboard perché non abbiamo bisogno di "gestire" nessuno stato.

Poi ho esaminato le soluzioni di recupero dei dati come SWR , TanStack Query e RTK Query .

SWR non ha un flusso di mutazione stabile e RTK Query è troppo accoppiato con Redux Toolkit, quindi sono andato avanti con TanStack Query.

TanStack Query rimuove l'overhead della gestione dei dati lato server con i relativi flussi di memorizzazione nella cache, invalidazione e mutazione. C'è sempre uno stato da gestire, ma non è sempre necessario gestirlo da soli. Abbiamo dato questo lavoro pesante a TanStack Query e non ci siamo voltati indietro. Stiamo utilizzando Redux e TanStack Query in parallelo e spostando lo stato Redux pezzo per pezzo nella query TanStack fino a quando non rimane nulla nello stato Redux e possiamo farlo in sicurezza yarn remove.

React Hooks ci consente di usarli in parallelo e spostare la logica tra di loro in modo incrementale:

In studio, tuttavia, vengono generati molti dati puramente lato client da inviare al server. Puoi progettare completamente una storia con elementi predefiniti; puoi spostarli nella tela, ridimensionarli, modificarne il contenuto in base alle tue esigenze, cambiare l'immagine di sfondo della storia o persino mettere un video sullo sfondo. E le possibilità sono infinite prima di inviare i dati finali al server per salvarli. Tutte queste funzionalità sono dati lato client finché non vengono salvate. E dopo averli salvati e tornati per modificarli, sono di nuovo dati lato client derivati ​​dai dati lato server.

Dobbiamo pensare anche alle possibili funzionalità: la possibilità di annullare le modifiche, creare disegni a mano libera, progettare transizioni tra le storie... Le possibilità sono infinite, ma tutte le funzionalità possibili sono dati pesanti lato client. Quindi dobbiamo "gestire" il nostro stato qui per la massima flessibilità.

Per Studio, stavamo già utilizzando una soluzione di gestione dello stato, Redux. Quindi, ho posto ai miei compagni di squadra la domanda: "Cosa dovremmo usare per sistemare la nostra gestione dello stato?"

Dopo tutte le risposte, il percorso era chiaro: useremo Redux Toolkit .

RTK (Redux Toolkit) è un set di strumenti del team Redux per migliorare la qualità della vita degli sviluppatori. Semplifica la configurazione del negozio e la gestione di più negozi utilizzando le sezioni . Quindi abbiamo migrato il nostro vecchio stato Redux alla nuova architettura RTK. Stiamo eseguendo sia la vecchia che la nuova architettura fianco a fianco e spostando parti di stati nella nuova architettura durante il refactoring. Tutto ciò ci consente di muoverci rapidamente e in modo incrementale senza bloccare il flusso di lavoro del prodotto.

Stiamo eseguendo questa vecchia e nuova architettura in parallelo passando un React Context personalizzato ai provider Redux :

Tieni presente che quando passi un contesto personalizzato al provider Redux, devi creare tutti gli hook Redux correlati con i generatori forniti e utilizzarli nel tuo codice invece di importarli direttamente dal pacchetto react-redux:

Il nostro obiettivo a lungo termine è rimuovere completamente Redux dal progetto Dashboard e rimuovere il "vecchio" Redux dal progetto Studio. Ci stiamo muovendo verso questo obiettivo eseguendo il refactoring di ogni file che dobbiamo toccare mentre sviluppiamo nuove funzionalità e correggiamo i bug.

Queste transizioni tecniche significative devono essere fluide e incrementali principalmente per due motivi: in primo luogo, stai rivedendo la vita lavorativa quotidiana del tuo team. Dovrebbero essere felici di lavorare con questi cambiamenti, altrimenti le loro prestazioni diminuiranno notevolmente. D'altra parte, se amano gli strumenti che usano per costruire e tali strumenti li aiutano invece di bloccarli, le loro prestazioni aumenteranno notevolmente. E in secondo luogo, il prodotto deve continuare a essere costruito . Lo spettacolo deve continuare. Ci devono essere nuove funzionalità. Deve andare avanti. Quindi le transizioni tecniche non devono bloccare lo sviluppo del prodotto. Ogni modifica dovrebbe essere incrementale.

Riepilogo

Quando prendiamo decisioni tecniche come sviluppatori, dovremmo considerare ogni aspetto del progetto su cui stiamo lavorando e le esigenze del team con cui lavoriamo. Questo semplicemente perché queste decisioni tecniche influenzano il team e tutti gli altri che lavorano al progetto, non solo gli sviluppatori.

Le modifiche tecniche dovrebbero essere incrementali a tutti i costi. Queste modifiche non dovrebbero bloccare la pipeline del prodotto e quindi il suo successo.

E ricorda sempre che, affinché uno sviluppatore sia produttivo, devi fornirgli gli strumenti che lo rendano felice.