(react.js) quando è appropriato chiamare negozi da componenti non container

Question

(react.js) quando è appropriato chiamare negozi da componenti non container

#1 da (1 voti)

1

I credo la maggior parte delle persone concorda sul fatto che l'uso dei componenti del contenitore è una buona pratica - descritta in questo popolare post: link

L'ho comprato, tuttavia, penso che lo stavo facendo un po 'troppo rigorosamente.

Un commento in quell'articolo indica che non usare i componenti del contenitore ostacola la riusabilità di quei componenti:

CommentList can’t be reused unless under the exact same circumstances.

Sebbene la riusabilità sia ottima, ci saranno sempre alcuni componenti che non sono destinati ad essere riutilizzati, hanno un lavoro molto specifico che è unico per un determinato aspetto della tua app. Quindi se non ho intenzione di riutilizzare questo componente, c'è qualche danno nel recuperare i dati dall'interno del componente che lo esegue?

Caso d'uso:

Mi sono trovato solo in questa situazione perché sto generando dinamicamente una manciata di componenti che condividono determinati comportamenti (ad esempio il salvataggio delle modifiche dell'utente agli input nel componente), ma altrimenti richiedono dati di archivio diversi. Quindi eseguo il rendering dei miei componenti tramite un loop con questo componente condiviso come genitore, tuttavia non voglio dover passare i dati del negozio in ognuno di questi componenti quando solo alcuni ne hanno bisogno.

Ecco la descrizione:

Container Component -> Shared Component ->  Unique Components

Dove il componente contenitore in questo momento sta recuperando tutti i dati del negozio, ogni componente univoco viene generato da un loop all'interno del componente contenitore incluso nel componente condiviso come genitore. Con questa configurazione corrente, ho bisogno di passare tutti i dati a ogni componente, tramite il componente condiviso, in modo che possa farlo ai miei componenti univoci

javascript reactjs

posta Ben 27.04.2016 - 15:33

fonte

1 risposta

Leggi altre domande sui tag javascript reactjs

Ridisegnare un builder per renderlo riutilizzabile Qual è l'architettura riutilizzabile corretta utilizzando Entity Framework per tabelle e servizi di database comuni?

score 1 · Accepted Answer

So if I don't plan on reusing this component, is there any harm to fetching the data from within the component that renders it?

Il design del software riguarda i trade-off. Separare i componenti del contenitore dai componenti di presentazione offre diversi vantaggi: separazione delle preoccupazioni , riusabilità, testabilità, ecc. Questi vantaggi sono probabilmente troppo facilmente trascurati o persi, motivo per cui articoli come quello che hai linkato ne fanno un grande affare. Ma, se perseguire questi vantaggi crea troppi svantaggi (di un design più complicato o più brutto, più lavoro di sviluppo, o qualsiasi altra cosa), non è "sbagliato" scendere a compromessi su di loro, purché comprendiate i compromessi che state facendo .

Un paio di considerazioni aggiuntive sui componenti del contenitore in particolare:

Se stai usando Redux, puoi [collegare] (https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) componenti a il negozio in punti arbitrari nella tua gerarchia. Il dilemma contenitore-contro-presentazione di dover passare lo stato dai componenti di livello superiore diventa un punto controverso se i componenti univoci di livello inferiore possono connettersi al negozio stesso.
Dan Abramov, il creatore di React Hot Loader e Redux, ha fornito questo esempio nella documentazione di Redux :

Sometimes it’s hard to tell if some component should be a presentational component or a container. For example, sometimes form and function are really coupled together, such as in case of this tiny component:

AddTodo is an input field with an “Add” button

Technically we could split it into two components but it might be too early at this stage. It’s fine to mix presentation and logic in a component that is very small. As it grows, it will be more obvious how to split it, so we’ll leave it mixed.

Se anche il creatore di Redux dice che non è sempre una linea dura e veloce, questo sta dicendo qualcosa.

Anche se decidi di sfocare la linea, dovresti prendere in considerazione le idee per tenere i concetti separati il più possibile. Ad esempio:

Il tuo componente condiviso potrebbe essere separato in modo che i suoi bit di presentazione condivisi si trovino in un componente e il resto della logica sia in un componente contenitore (che mostra il componente di presentazione condiviso e collega i bambini unici).
Forse il componente condiviso potrebbe prendere i bambini unici come bambini React, in modo che non abbia bisogno di alcuna logica di stato univoca. Reagire i bambini può essere abbastanza flessibile, grazie a tecniche come i vari React.Children metodi, utilizzando cloneElement per iniettare proprietà figlio e frammenti con chiave.
Forse la logica condivisa può essere in un componente di presentazione e un componente di ordine superiore aggiunge la logica per iniettare lo stato per i bambini unici.