Redux: Docs : Utilisation avec le routeur React

J'avais initialement écrit l'exemple de rendu côté serveur pour utiliser le routeur de réaction dans un contexte universel. Il a été suggéré que l'utilisation avec le routeur de réaction pourrait devenir un document à part entière. Peut-être pourrions-nous ajouter une section à la documentation ?

Aussi, que pensez-vous de l'ajout d'un exemple qui montre que le routeur de réaction est universellement utilisé ?

Je pense que modifier l'exemple real-world pour qu'il soit universel serait une bonne idée. De cette façon, vous n'avez pas à créer quoi que ce soit à partir de zéro.

Si vous souhaitez passer des créateurs d'action, transmettez l'instance de routeur en tant que paramètre aux créateurs d'action

Je voulais juste clarifier, cela ne fonctionne que dans la 0.13 car la 1.0beta n'a pas (encore ?) de concept createRouter , n'est-ce pas ?

Vous pouvez le faire avec 1.0.0-beta3 à partir de vos composants React.

class Thing extends Component {
  static contextTypes = {
    router: PropTypes.object
  }

  handleThing() {
    this.props.actionCreator(this.context.router);
  }
}

@timdorr Est-il sûr d'utiliser this.context ? J'avais l'impression qu'il n'était pas destiné à être utilisé à l'extérieur.

Oui, c'est juste sans papiers, pas dangereux. Il est légèrement modifié en 0.14, mais pas d'une manière qui briserait cela. J'imagine qu'il sera documenté à un moment donné bientôt.

@timdorr Cela signifie-t-il également qu'il est possible de passer à une URL différente à partir d'un créateur d'action dans 1.0.0-beta3 ?

Oui, si vous transmettez l'instance du routeur au créateur de l'action, vous pouvez en faire ce que vous voulez, y compris les transitions.

J'ai regroupé ceci :

const loginProps = {
  handleLogin: ({email, password}) => store.dispatch(userLogin({email, password})),
};



const routes = (
  <Route path="/" handler={App}>
    <Route path="login" handler={wrapper(Login, loginProps)} />
    <Route handler={authSection}>
      <Route path="" handler={Index} />
      <Route path="users" handler={wrapper(Users, (() => store.dispatch(getUsers())))} />
      <Route path="logout" handler={wrapper(Login, (() => store.dispatch(userLogout())))} />
    </Route>
  </Route>
);

const router = createRouter({
  location: HistoryLocation,
  routes,
});

store.dispatch(receiveRouter({router}));

Warning: Failed Context Types: Required context `store` was not specified in `SmartComponent(TodoApp)`. Check the render method of `Router`.

Qu'est-ce qui ne va pas ?

PS : RR 1.0.0-beta3

@gyzerok Assurez-vous d'envelopper l'ensemble () => <Router>stuff</Router> dans <Provider> , tout comme l'exemple real-world le fait.

@gaearon oui, ofc. Je ne l'enveloppe pas dans Provider mais dans mon propre composant qui est principalement un copier-coller de votre Provider. La différence est que je ne lui passe pas de magasin, mais que je crée un magasin à l'intérieur de celui-ci.

@gyzerok Il est difficile de dire ce qui ne va pas sans voir le code. (Et veuillez déposer un problème séparé, react-redux repo est un bon endroit.)

Merci pour l'exemple real-wolrd ! Mais comment gérer AsyncProps ? On dirait que la double manipulation de contexte ne fonctionnera pas ensemble.

import React from 'react';                                                                                                                                                                                         
import {createStore} from 'redux';                                                                                                                                                                                 
import {Provider} from 'react-redux';                                                                                                                                                                              
import {Router, Route} from 'react-router';                                                                                                                                                                        
import BrowserHistory from 'react-router/lib/BrowserHistory';                                                                                                                                                      
import AsyncProps from 'react-router/lib/experimental/AsyncProps';                                                                                                                                                 

import App from './containers/App';                                                                                                                                                                                
import reducers from './reducers';                                                                                                                                                                                 

const store = createStoreWithMiddleware(reducers);                                                                                                                                                                 
const history = new BrowserHistory();                                                                                                                                                                               

React.render(                                                                                                                                                                                                       
    <Provider store={store}>                                                                                                                                                                                        
        {() =>                                                                                                                                                                                                      
            <Router history={history} createElement={AsyncProps.createElement}>                                                                                                                                     
                <Route component={AsyncProps}>                                                                                                                                                                      
                    <Route path="/" component={App} />                                                                                                                                                              
                </Route>                                                                                                                                                                                            
            </Router>                                                                                                                                                                                               
        }                                                                                                                                                                                                           
    </Provider>,                                                                                                                                                                                                    
    document.body                                                                                                                                                                                                  
);

et App.js

import React from 'react';                                                                                                                                                                                         
import {connect} from 'react-redux';                                                                                                                                                                               

let App = React.createClass({                                                                                                                                                                                      
    statics: {                                                                                                                                                                                                     
        loadProps(params, cb) {                                                                                                                                                                                    
            // have to call this with AsyncProps                                                                                                                                                                   
        }                                                                                                                                                                                                          
    },                                                                                                                                                                                                             
    displayName: 'App',                                                                                                                                                                                            

    render() {                                                                                                                                                                                                     
        return <div children="this is app" />                                                                                                                                                                      
    }                                                                                                                                                                                                              
});                                                                                                                                                                                                                

export default connect(state => state)(App); 

Cela fonctionnera sans wrapper connect , mais il n'y aura pas non plus redux . Quelqu'un a-t-il rencontré ce problème ?

Ou peut-être un autre moyen de suspendre la navigation jusqu'à ce que les données soient chargées ?

Les statiques ne sont que des statiques. Vous pouvez les mettre sur n'importe quoi, y compris le résultat connect() .

let App = React.createClass({                                                                                                                                                                                      
    displayName: 'App',                                                                                                                                                                                            

    render() {                                                                                                                                                                                                     
        return <div children="this is app" />                                                                                                                                                                      
    }                                                                                                                                                                                                              
});                                                                                                                                                                                                                

App = connect(state => state)(App); 

App.loadProps = function loadProps(params, cb) {                                                                                                                                                                                    
  // have to call this with AsyncProps                                                                                                                                                                   
}                                                                                                                                                                                                          

export default App; 

@gaearon désolé, l'exemple n'est pas complet. J'ai essayé d'étendre le résultat connect avec des accessoires statiques manquants, mais un vrai problème avec le contexte. Donnez-moi un peu de temps, je vais mettre tout l'exemple dans un dépôt séparé

Une autre chose que j'étudie actuellement est de stocker les paramètres dans un magasin redux de manière claire et discrète. Après avoir essayé quelques approches, j'ai fini par écrire:

<Route
  component={OrderDetails}
  path='/orders/:orderId'
  onEnter={({params}) => store.dispatch(setCurrentOrder(params.orderId))} 
/>

il est donc possible de se référer aux paramètres des sélecteurs, comme ci-dessous :

export const OrderDetails = state => {
  const {order} = state;
  return {
    order: order.details.get(order.currentOrderId),
    orderId: order.currentOrderId,
    isLoading: order.isLoadingDetails,
    error: order.detailsLoadingError
  };
};

Cela changera probablement une fois que react-redux-router plus stable sera publié.

Bonne nouvelle : React Router 1.0 RC expose désormais les crochets dont nous avons besoin.
Consultez https://github.com/acdlite/redux-react-router et faites-nous savoir si vous l'aimez maintenant !

@gaearon j'ai trouvé le problème avec react-router et AsyncProps expérimental. La mise à jour de la réaction résout le problème

@wtfil Bon à savoir !

Lors de l'intégration avec react-router, je comprends de ce fil que nous pouvons transmettre l'instance de routeur à un créateur d'action et appeler des méthodes dessus. Cependant, je comprends également que les créateurs d'action sont destinés à ne pas avoir d'effets secondaires dans leur forme la plus pure. Le seul cas que je vois où les créateurs d'action sont autorisés à avoir des effets secondaires est lorsqu'il s'agit d'actions asynchrones gérées par un middleware. S'attend-on alors à ce que les créateurs d'action qui effectuent des transitions soient asynchrones plutôt que de pures fonctions ?

S'attend-on alors à ce que les créateurs d'action qui effectuent des transitions soient asynchrones plutôt que de pures fonctions ?

Les créateurs d'action sont autorisés à avoir des effets secondaires. Il est préférable de les éviter lorsque cela est possible, mais bien sûr, à un moment donné, vous en avez besoin, et puisque les réducteurs sont purs dans Redux, et que nous n'avons pas de mécanisme d'effet explicite comme dans Elm (voir # 569 pour la discussion), les créateurs d'action sont les place pour les mettre.

Découvrez redux-router . Il fonctionne au-dessus de React Router, mais vous permet de répartir les actions et de synchroniser le routeur.

en attendant React Router et Redux Router ont tous deux atteint 1.0 ...

Ouais. Nous ajouterons une recette après cela.

J'ai donc suivi cette discussion et réfléchi un peu à la façon dont le routage s'intègre dans redux en général (voir https://github.com/rackt/redux/issues/805). Sur la base de certaines discussions dans ce fil et de quelques expériences, j'ai trouvé une approche que je préfère personnellement à la colle react-router/react-redux-router.

Fondamentalement, j'essaie de ne pas donner à react-router ou à redux aucune connaissance les uns des autres et de les connecter à la place via une implémentation d'historique personnalisée. Avec cette approche, le routage est géré comme ceci :

1. Une action, un réducteur et une clé dans le magasin sont créés pour route .
2. Une implémentation d'historique standard (cet exemple utilise le createHistory préféré mais vous pouvez facilement utiliser createHashHistory ou autre) est créée et écoutée. Lorsque l'emplacement actuel dans le navigateur est modifié, une action ROUTE est envoyée, plaçant finalement l'emplacement dans le magasin.
3. Une instance standard de react-router est créée avec une deuxième implémentation d'historique personnalisé qui avertit l'abonné (react-router) lorsque la clé route du magasin est modifiée. Il définit également createHref et pushState , en déléguant les deux à l'historique standard créé à l'étape 2.

C'est ça. Je pense que cela fournit une séparation assez nette des tâches entre redux et react-router et supprime le besoin d'insérer une autre bibliothèque "glue". Je colle mon code ci-dessous, je serais très intéressé à entendre des commentaires:

// please pay attention to library versions, this strategy is only tested with the indicated versions
import React from 'react'; // v0.13.3
import { Provider } from 'react-redux'; // v3.1.0
import { Router, Route, IndexRoute, Link } from 'react-router'; // v1.0.0-rc3
import { createHistory } from 'history'; // v1.12.3
import { createStore } from 'redux'; // v3.0.2

// define some components
class About extends React.Component {
    render () {
        return (
            <div><h1>About</h1></div>
        )
    }
}
class Home extends React.Component {
    render () {
        return (
            <div>
                <h1>Home</h1>
                <Link to="/about">Go to about</Link>
            </div>
        )
    }
}

// create a standard history object
var history = createHistory();

// set up 'route' action and action creator
const ROUTE = 'ROUTE';
function createRouteAction (location) {
    return {
        type: ROUTE,
        payload: location
    };
}

// set up reducer. here we only define behavior for the route action
function reducer (state = {}, action) {
    if (action.type === ROUTE) {
        return Object.assign({}, state, {
            route: action.payload
        });
    }
    else {
        return state;
        // whatever other logic you need
    }
}

// create store
const store = createStore(reducer);

// this factory returns a history implementation which reads the current state
// from the redux store and delegates push state to a different history.
function createStoreHistory () {
    return {
        listen: function (callback) {
            // subscribe to the redux store. when `route` changes, notify the listener
            const unsubscribe = store.subscribe(function () {
                const route = store.getState().route;
                callback(route);
            });

            return unsubscribe;
        },
        createHref: history.createHref,
        pushState: history.pushState
    }
}

React.render(
    <Provider store={store}>
        {() =>
            <Router history={createStoreHistory()}>
                <Route path="/about" component={About} />
                <Route path="/" component={Home} />
            </Router>
        }
    </Provider>,
    document.getElementById('root') // or whatever
);

// when the url changes, dispatch a route action. this is placed at the bottom so that the first route triggers the initial render
const unlisten = history.listen(function (location) {
    store.dispatch(createRouteAction(location));
});

Je le mentionne, soit dit en passant, parce que je pense que cet exemple pourrait aider certaines personnes comme moi qui luttaient avec l'utilisation de react-router avec redux et aider à clarifier votre affirmation selon laquelle redux et react-router peuvent être utilisés ensemble aujourd'hui.

@cappslock J'aime ça, il y a une petite chose cependant. Dans votre implémentation, changer de route est l'action, cela rompt en quelque sorte l'approche "L'action est un événement et non une commande" qui peut éventuellement conduire à des pratiques désagréables. Inversons la pensée, potentiellement toute action peut entraîner un effet secondaire qui modifie la barre d'adresse (qu'il s'agisse d'un composant ou de la barre d'adresse du navigateur réel ....) et l'effet secondaire entraîne l'envoi d'une nouvelle action ( ROUTE_CHANGED ). C'est fondamentalement le même modèle que le déclenchement d'un appel API.

@ Tomkis1 merci pour les commentaires. Si je vous comprends bien, cela fonctionne déjà de cette façon. L'action ROUTE est distribuée comme un effet secondaire du changement d'URL. Peut-être que ROUTE_CHANGED serait un meilleur nom ?

Oh! Je viens de vérifier et tu avais raison. Ouais ROUTE_CHANGED aurait plus de sens.

Je le pense aussi. J'y retournerais et le changerais, mais ces commentaires seraient vraiment déroutants :)

Le flux est comme ceci, pour clarifier:

Changement d'URL -> action ROUTE (ou ROUTE_CHANGED ) -> magasin de mises à jour du réducteur -> historique du magasin (précédemment abonné au magasin) notifie les auditeurs -> mises à jour du routeur de réaction

Je préfère cela parce que je ne veux rien d'autre que le magasin qui pilote l'état de l'interface utilisateur observé par l'utilisateur. Cela semble également préférable pour les tests.

Un inconvénient de cette approche est que l'URL ne se met pas à jour en réponse à l'action ROUTE_CHANGED . Je ne sais même pas si cela est souhaitable si nous disons que nous ne voulons pas que les actions soient traitées comme des commandes, mais j'imagine que cela pourrait être complété soit comme un effet secondaire du créateur d'action ROUTE_CHANGED soit par un abonné de magasin distinct.

BTW, si cette discussion dépasse le cadre de ce problème, faites-le moi savoir et je la déplacerai.

@cappslock j'aime beaucoup ça ! Je ne pense vraiment pas que ce soit un problème que l'envoi ROUTE_CHANGED ne change pas l'itinéraire. Traiter l'action comme un événement et non comme un déclencheur me semble plus propre/plus compréhensible (car elle répond à une interaction de l'utilisateur ; vous ne vous attendriez pas à ce qu'une action BUTTON_CLICKED déclenche réellement un clic sur un bouton). Il y a une partie de votre code que je ne comprends pas. Pouvez-vous m'expliquer ce morceau ?

celui-ci est placé en bas pour que le premier itinéraire déclenche le rendu initial

@elliotdickison Merci ! Je vais essayer de clarifier cela, mais s'il vous plaît, prenez ce que je dis avec un grain de sel car il est basé sur des essais et des erreurs et des hypothèses plutôt que sur une analyse approfondie. Il s'agit plus d'une preuve de concept/d'un croquis à ce stade.

Lorsque j'avais placé ce code au-dessus de l'instanciation de ReactRouter , le composant correspondant à la route / n'était pas rendu. Le routeur fonctionnerait toujours si les actions étaient envoyées manuellement ou si l'état était poussé manuellement, j'ai donc pensé qu'il s'agissait d'un problème de cycle de vie avec l'historique. Le déplacer sous l'instanciation de ReactRouter a résolu ce problème. Je soupçonne que la bibliothèque d'historique diffère la notification de l'itinéraire initial jusqu'à ce qu'il y ait au moins un abonné. Si cet abonné est configuré avant le ReactRouter, aucune des notifications ne l'atteint.

En essayant d'expliquer cela, je me rends compte que ma compréhension fait un peu défaut; Je vais étudier cela plus en détail et essayer de fournir une meilleure réponse.

Un inconvénient de cette approche est que l'URL ne se met pas à jour en réponse à l'action ROUTE_CHANGED. Je ne sais même pas si cela est souhaitable si nous disons que nous ne voulons pas que les actions soient traitées comme des commandes, mais j'imagine que cela pourrait être complété soit comme un effet secondaire du créateur d'action ROUTE_CHANGED, soit par un abonné de magasin séparé.

Je dirais que c'est souhaité, ROUTE_CHANGED devrait certainement être déclenché par une source externe (par exemple onhashchange ...) Le changement d'URL de l'OMI devrait entraîner ROUTE_CHANGED non l'inverse.

Je suis plutôt d'accord. J'ai pensé qu'il serait peut-être bien d'avoir quelque chose qui s'abonne au magasin et de garder l'URL synchronisée au cas où une action ROUTE_CHANGED envoyée proviendrait du code et non d'un événement d'historique réel, mais vous pourriez dire que ce cas représente un erreur de programmation.

@cappslock votre approche est vraiment très bonne. Pourriez-vous faire un article de blog à ce sujet?

@vojtatranta Il suffit de consulter https://github.com/rackt/redux/issues/805 Je suppose que c'était l'inspiration derrière la mise en œuvre.

@vojtatranta Merci ! Je n'ai pas de blog, donc à peu près toutes les informations dont je dispose se trouvent dans ce fil et #805. Quelque chose en particulier sur lequel vous vouliez plus d'informations ?

1.0 est sorti.

Il est temps de:

• Exemple de routage de port pour l'utiliser
• Ajouter la recette "Utilisation avec routeur" basée sur l'exemple real-world

:taper:

@gaearon pouvez-vous faire référence à ce problème lorsque l'exemple _Usage with Router_ est dans un PR ? Beaucoup de gens que je connais (moi y compris) cherchent des éclaircissements sur la façon dont ces deux jouent bien ensemble.

Oui bien sûr. C'est à ce moment que le problème sera clos. :-)

Peut-être que redux-simple-router devrait être envisagé maintenant ?

redux-simple-routeur +1

Je viens de convertir l'exemple universel + react-router (+ redux-simple-router)
https://github.com/eriknyk/redux-universal-app

Salut à tous, quelle est la conclusion de cette discussion ? je vois que les docs ne sont pas mis à jour pour une utilisation avec react-router
cc @gaearon

@gaearon après avoir lié mon application de réaction à redux, j'utilise simplement l'état pour contrôler l'affichage/masqué de mes composants. Donc, je ne pense pas que le rôle de "routeur" d'origine comme RR corresponde à mon application maintenant.
La seule chose que je pense que le "nouveau routeur" doit faire est de mapper l'URL à l'état (via des actions?) Et de remapper l'état à l'url également.
Si nous laissons l'url décider comment le composant d'application (peut-être certains d'entre eux) sera affiché, cela signifie que nous avons deux sources d'état, l'une est l'url, l'autre est le magasin de redux, cela rendra les choses plus difficiles...
Que dites-vous à ce sujet ? devrions-nous simplement laisser la barre d'adresse être un autre composant de notre application.

Merci

Je m'engage officiellement à écrire ce document après l'envoi de https://github.com/rackt/react-router-redux/pull/259. Ce sera la manière bénie de lier React Router et Redux. Dans la documentation, nous allons d'abord montrer comment les utiliser sans ce package, et introduire progressivement deux avantages offerts par le package : le middleware et le déplacement de la source de vérité du routage dans le magasin. Les deux sont facultatifs, nous nous assurerons donc d'expliquer dans quel cas vous souhaitez les utiliser et ce qu'ils vous offrent par rapport à vanilla RR.

Voici une idée à prendre en compte : si quelque chose que vous expliquez sur le middleware lié au routage et à l'historique pourrait également devenir un morceau spécifique d'application réaliste dans l'explication générale de http://rackt.org/redux/docs/advanced/Middleware.html ( par exemple, dans les exemples à la fin)

@gaearon des progrès sur le doc React Router / prochaines étapes ? Je lis la documentation de Redux et je l'adore, mais je suis déçu par ces faux liens :(

Je viens tout juste de commencer à réécrire les documents du routeur de réaction dans mon référentiel personnel et je prévois d'y ajouter également la section redux. Je pourrais faire quelque chose bientôt, cela dépend de mon temps libre. Je vous tiendrai au courant. https://github.com/knowbody/react-router-docs

Pour être juste, vous n'avez besoin de rien du côté Redux pour faire fonctionner le routeur React. Mais oui, nous devons le faire.

Attention : React Router 3.0 fonctionnera mieux avec les optimisations React Redux connect() , et le nouveau withRouter() HOC signifie que vous n'avez pas besoin d'utiliser directement le contexte.

https://twitter.com/dan_abramov/status/729768048417251328

@gaearon , @timdorr pourriez-vous clarifier les compromis entre le passage d'une instance de routeur comme argument aux créateurs d'action et l'importation directe de browserHistory dans les créateurs d'action (comme suggéré ici https://github.com/reactjs/react-router/blob /master/docs/guides/NavigatingOutsideOfComponents.md ?

router enveloppe simplement votre instance d'historique avec quelques bonus supplémentaires, mais ce sont les mêmes méthodes push et replace entre les deux instances.

Merci, @timdorr.

Je suppose que la question devient alors pourquoi avons-nous besoin de la composition withRouter() si router enveloppe essentiellement le singleton d'histoire (c'est un singleton, n'est-ce pas)?

Est-ce pour permettre un couplage plus lâche entre un composant et une instance d'historique (c'est-à-dire pour empêcher le composant d'accéder directement à un objet singleton) ? Si tel est le cas, la même logique ne s'appliquerait-elle pas lors de l'accès à l'instance d'historique à partir d'un créateur d'action ?

Oui, et si vous fournissez votre propre instance d'historique et que vous ne voulez pas (ou ne pouvez pas) créer votre propre module singleton (ce qui peut être déroutant si vous n'êtes pas très familier avec les systèmes de modules JS). Si vous voulez le faire vous-même, vous êtes plus que bienvenu pour suivre notre modèle.

Je ne sais pas s'il serait utile de documenter withRouter sur la façon dont il peut être utilisé pour plusieurs composants d'ordre supérieur. J'essaie toujours de trouver le meilleur moyen d'éviter cela:
connect(mapStateToProps, mapDispatchToProps)(withRouter(withAnalytics(withLanguage(TestForm)))); .

Je pourrais aussi utiliser quelque chose comme compose ?

const enhance = compose(
  connect(mapStateToProps, mapDispatchToProps),
  withRouter,
  withAnalytics,
  withLanguage
);

export default enhance(TestForm);

Cependant, mon cas d'utilisation, le contexte va avoir connecté l'utilisateur, la langue actuelle, les informations sur le thème et les analyses, ce qui rend cela difficile avec beaucoup de contexte et beaucoup de composants connectés.

Une autre idée consiste à dupliquer la logique withRouter et connect sous un espace de noms de contexte : withAppContext() => props.app = { user, lang, theme, analytics, router, connect? } ?

Cela serait-il bénéfique pour la documentation ou un exemple d'utilisation withRouter avec connect ?

@gaearon y a-t-il des mises à jour pour cela maintenant que React Router 3.0.0 et vos nouvelles vidéos Egghead sont sorties depuis un certain temps, et ce fil est ouvert depuis un an ?

Fait en #1929