Anfangsdaten werden geladen ReactJS

Question

Ich mag würde einige Anfangsdaten werden geladen, wenn meine erste Route wird gerendert auszuführen (zum Beispiel möchte ich eine Liste von Nachrichtenartikeln laden)

ich eine Komponente aus News.js genannt, der rendert die Artikel. Das Problem, das ich mit dem FLUX-Modell habe, ist, wo diese Anfangsdaten geladen werden.

Der Service, den ich gemacht habe, um die Daten zu laden, ist der folgende: Importanforderung von 'superagent';

class NewsService { 

    fetchArticles(callback) { 
    request 
     .get('http://localhost/articles') 
     .accept('json') 
     .end(function(err, res){ 
     console.log(err); 
     var result = JSON.parse(res.text); 
     callback(result); 
     }) 
    } 

} 

export default new NewsService(); 

Dieser Dienst muss irgendwo aufgerufen werden. Nach Angaben der ReactJS Dokumentation würde ich diesen Vorgang wie folgt durchführen:

export default class News extends React.Component { 

    constructor() { 
    super(); 
    this.state = { 
     _articles: [] 
    } 
    } 

    componentDidMount() { 
    NewsService.fetchProjects(function(articles){ 
     // load articles in the state 
     this.setState({_articles: _articles}) 
    }); 
    } 

    render() { 

     return (
      <section> 
       <h1>Articles</h1> 
       <ul> 
       {this.state.articles.map((article) => { 
        <li>{article.title}</li> 
       })} 
       </ul> 
      </section> 
    ) 
    } 
} 

Nun meine Frage ist, ist das nicht gegen den Fluss Prinzip? Sollten die Daten nicht als Aktion aufgerufen werden, die dann ihre Daten in einem Geschäft wie NewsStore speichert?

Sollte eine Aktion wie folgt aus:

var NewsActions = { 

    load: function() { 
    NewsService.fetchProjects(function(articles){ 
     // store the articles in the NewsStore and dispatch afterwards   
    }); 
    }, 

    create: function(project) { 
    AppDispatcher.dispatch({ 
     actionType: NewsConstants.ARTICLE_CREATE, 
     project: project 
    }); 
    }, 

    update: function(id, project) { 
    AppDispatcher.dispatch({ 
     actionType: NewsConstants.ARTICLE_UPDATE, 
     id: id, 
     project: project 
    }) 
    }, 

    destroy: function() { 
    AppDispatcher.dispatch({ 
     actionType: NewsConstants.ARTICLE_DESTROY, 
     id: id 
    }) 
    } 
}; 

export default NewsActions; 

Im Chat-app example von reactjs sie bieten ein Beispiel API-Aufruf. Allerdings wird dieser API-Aufruf beim Start der Anwendung (in app.js) aufgerufen, was in meinem Szenario nicht anwendbar ist, da ich Routings verwenden möchte. Würde ich die Daten dann in den Router laden? (Ich benutze react-router)

Jede Rückmeldung zu diesem Thema oder Verbesserungen dieses Codes ist mehr als willkommen.

Answer 1

EDIT

ist das nicht gegen den Fluss Prinzip?

Vielleicht, vielleicht nicht. Sieht so aus, als wäre Flux ziemlich flexibel. Soweit ich weiß, handelt es sich eher um einen Rahmen von Prinzipien als um ein strenges "Protokoll". Es ist schwer zu sagen, aber es scheint, dass beide Beispiele, die Sie gegeben haben, funktionieren. Wie Sie schon sagten, nach the docs empfehlen holen sie die Daten in componentDidMount:

componentDidMount: function() { 
    $.get(this.props.source, function(result) { 
    // ... 

jedoch in Ihrem Beispiel sind das Bewegen Sie einfach diesen API-Aufruf in einen Dienst, der mit dem Laden/Disponent dann in Wechselwirkung treten können usw., um über die gesamte Anwendung verwendet zu werden.

Also, was Sie getan haben, ist ein schöner Teil Ihrer Anwendungslogik auf im Wesentlichen ein eigenes Modul (naja, ein Modul, das ein Teil Ihrer Dispatcher ist) verschoben. Es scheint, dass es Ihren Bedürfnissen entspricht: es kann in Ihrer App verwendet werden und es kann herausgezogen oder wieder eingesteckt werden, wie Sie es für richtig halten. Ich sehe nichts falsch daran. Könnte es gegen einen Grundsatz des Flux sein? Vielleicht, vielleicht nicht. Ich bezweifle aber, dass es wichtig ist.

ORIGINAL

Ich bin nicht sehr versiert in Flux-Architektur, aber an einem der Facebook-Beispiele in ihren GitHub Repo (insbesondere Line 24 of TodoMVC) suchen:

function getTodoState() { 
    return { 
    allTodos: TodoStore.getAll(), 
    areAllComplete: TodoStore.areAllComplete() 
    }; 
} 

Ihr Beispiel zeigt nicht Wie TodoStore interagiert mit dem Server, aber es sieht aus wie für ihren Ausgangszustand, sie einfach die Todos im Speicher abfragen, und dann für Änderungen, deren Abhören und Ausstrahlen von Ereignissen.

So weit wie das Erhalten des Ausgangszustandes, es sieht aus wie ihr Beispiel zeigt, den Speicher direkt abfragend. Offensichtlich seit der Zeit, als sie dieses Beispiel und jetzt gemacht haben, gab es möglicherweise Änderungen, aber es könnte sich lohnen, einige Beispiele in der Flux repo zu untersuchen, um eine Vorstellung davon zu bekommen, wie es entworfen wurde.