2016-03-30 7 views
11

Trascorro molto tempo a pensare a come strutturare al meglio le cose nel modo più pulito possibile in React. Ultimamente mi sono bloccato sul fatto che i contenitori React non dovessero fare altro che collegarsi a Redux (o altri dati - a la Meteor) e rendere/restituire un singolo componente, o se anche i contenitori dovrebbero essere responsabili anche della gestione degli eventi . Così, per esempio, è un lancio-up tra questi due modelli:Posso inserire chiamate AJAX nel componente di presentazione o devo estrarre un contenitore?

Modello 1

// ThingContainer.js 

import Thing from '../components/Thing'; 
export default someHigherOrderFunc(/* map state/data to props */)(Thing) 

// Thing.js 

export default class Thing extends Component { 
    handleClick() { /* ... */ } 
    handleMouseEnter() { /* ... */ } 
    render() { 
    // Other components rendered here, both container or presentational 
    } 
} 

Modello 2

// ThingContainer.js 

class ThingContainer extends Component { 
    handleClick() { /* ... */ } 
    handleMouseEnter() { /* ... */ } 
    render() { 
    // Now Thing can be stateless 
    return <Thing 
     onClick={this.handleClick} 
     onMouseEnter={this.handleMouseEnter} 
    /> 
    } 
} 

export default someHigherOrderFunc()(ThingContainer) 

Ci si sente quasi come nel modello 1, Thing diventa un proprio contenitore in un senso, che non sono sicuro mi piace. Il modello 2 è più naturale, poiché lo ThingContainer non si occupa solo dei dati e di Redux, ma gestisce anche gli eventi, licenzia le richieste Ajax in componentDidMount, ecc. Con il primo modello, se volevo una richiesta Ajax da invocare in componentDidMount, dovrebbe andare in Thing che non sembra giusto.

Mi chiedo se ci sono particolari vantaggi o insidie ​​a uno di questi approcci, o se si tratta solo di stile/preferenza.

risposta

12

Non c'è nulla di intrinsecamente sbagliato nel fare AJAX all'interno del "presentational-ish" Thing quando ci sono solo un paio di metodi, e comunque questo componente non viene mai usato in diversi scenari. Non dividere il comportamento dalla presentazione prima che tu sia sicuro di come il comportamento cambia in diversi contesti.

Questo dilemma significa che il componente non ha ancora bisogno di essere riutilizzato. In questo caso non importa come lo dividi. Entrambe le modalità funzionano bene, quindi opterei per la più semplice (modello 1).

In seguito potresti rendertene conto che volete riutilizzare lo stesso look-n-feel ma attivare diverse chiamate AJAX, o calcolare gli oggetti di scena in modo diverso. A questo punto potresti voler rimuovere la gestione degli eventi da Thing e creare diversi diversi ThingContainer s, ognuno dei quali gestisce eventi e oggetti di calcolo in modo un po 'diverso. Questo è quando separare la presentazione e il comportamento diventa utile.

+9

Sembra quasi che tu abbia qualche esperienza con React + Redux;) – markthethomas

+0

Questo ha molto senso! E poi se voglio avere contenitori diversi che possono racchiudere "Cosa", allora si tratta solo di un problema di convenzioni di denominazione (come nominare diverse varianti di 'ThingContainer'). – ffxsam

+0

Sì. Non trovo che il naming sia un problema con casi d'uso reali. Per esempio. 'List' vs' UserFollowerList', 'UserFollowingList',' UserPostList', ecc. –

Problemi correlati