Albert Einstein era un genio assoluto, ma c'era un fenomeno della meccanica quantistica che proprio non riusciva a digerire, tanto da definirlo "spettrale azione a distanza".

Parliamo dell'Entanglement Quantistico. Se due particelle sono "entangled" (intrecciate), tutto ciò che accade a una di esse si riflette istantaneamente sull'altra, anche se si trovano ai lati opposti della galassia. Modifichi lo spin della Particella A, e la Particella B muta nello stesso istante, senza alcun canale di comunicazione visibile.

Sembra magia nera da film di fantascienza, eppure è scienza. Ed è esattamente la stessa sensazione di impotenza che si prova quando si gestisce male lo stato globale in React. Muti una variabile nel componente Footer e, improvvisamente, il componente Header esplode e l'intera applicazione va in re-render. Azione spettrale a distanza.

L'Illusione della Comodità

Agli albori dello sviluppo con React, il problema principale era passare i dati dal componente padre ai figli (il prop-drilling). Poi scopri la Context API (o Redux, o Zustand) e ti sembra di aver trovato il Santo Graal.

Pensi: "Fantastico! Butto tutte le variabili dell'app in un unico enorme Global State, così qualsiasi componente può accedere a qualsiasi dato da ovunque!".

Hai appena entanglato la tua intera base di codice.

Il Fango: L'Oggetto Divino

In un progetto per un cliente, ho creato un unico AppContext che conteneva letteralmente tutto: i dati dell'utente, i prodotti nel carrello, il tema chiaro/scuro e persino lo stato di apertura di un singolo modale.

// Bad Code: L'Entanglement Globale
const AppContext = createContext();

function AppProvider({ children }) {
  const [state, setState] = useState({
    user: null,
    cart: [],
    isModalOpen: false, // <-- Attenzione qui
  });

  return (
    <AppContext.Provider value={{ state, setState }}>
      {children}
    </AppContext.Provider>
  );
}

Il disastro? Ogni volta che l'utente cliccava un bottone per aprire un banale popup (modificando isModalOpen), il reference dell'intero oggetto state cambiava.

Siccome la Navbar leggeva lo state per mostrare il nome utente, e la pagina Prodotti lo leggeva per mostrare il carrello, l'atto di aprire un popup scatenava il re-rendering spettrale di tutta l'applicazione. L'app andava a scatti, le ventole del PC decollavano.

L'Ingegneria: Rompere il Legame

In fisica non puoi spezzare facilmente l'entanglement. In Ingegneria del Software, per fortuna, sì. La soluzione si chiama Separation of Concerns (Separazione delle Responsabilità).

Non mettere in un Context globale dati che cambiano frequentemente e dati statici. Isola gli stati in base al loro dominio di competenza.

// Good Code: Atomi isolati
// 1. Context solo per roba che cambia raramente
const UserProvider = ({ children }) => {
  const [user, setUser] = useState(null);
  return <UserContext.Provider value={user}>{children}</UserContext.Provider>;
}

// 2. Context specifico per il carrello
const CartProvider = ({ children }) => {
  const [cart, setCart] = useState([]);
  return <CartContext.Provider value={cart}>{children}</CartContext.Provider>;
}

// 3. Gestire lo stato del modale LOCALMENTE, 
// o usare librerie come Zustand con "selectors" per evitare re-render.

Con questo approccio granulare, se il carrello viene modificato, solo i componenti che ascoltano il CartContext reagiscono. La Navbar con i dati dell'utente se ne sta in pace, imperturbabile.

Il Takeaway

L'accesso globale e facile ai dati è una trappola mortale travestita da comodità. Più estendete il raggio d'azione di una variabile, più componenti diventeranno dipendenti (entangled) dalle sue mutazioni.

Mantenete lo stato il più locale possibile. Promuovetelo a globale solo quando è strettamente indispensabile, e frammentatelo per logica di business. L'azione fantasma a distanza lasciatela ai fisici quantistici; il vostro codice deve essere prevedibile, isolato e noioso.