couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From benkeen <...@git.apache.org>
Subject [GitHub] couchdb-fauxton pull request: GSoC 2015 - 2214 Dashboard as main p...
Date Fri, 05 Jun 2015 23:01:13 GMT
Github user benkeen commented on a diff in the pull request:

    https://github.com/apache/couchdb-fauxton/pull/434#discussion_r31858594
  
    --- Diff: app/addons/dashboard/components.react.jsx ---
    @@ -0,0 +1,190 @@
    +// Licensed under the Apache License, Version 2.0 (the "License"); you may not
    +// use this file except in compliance with the License. You may obtain a copy of
    +// the License at
    +//
    +//   http://www.apache.org/licenses/LICENSE-2.0
    +//
    +// Unless required by applicable law or agreed to in writing, software
    +// distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
    +// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
    +// License for the specific language governing permissions and limitations under
    +// the License.
    +
    +define([
    +  'app',
    +  'api',
    +  'react',
    +  'addons/dashboard/stores'
    +], function (App, FauxtonAPI, React, Store) {
    +
    +  var activeTaskList = Store.dashboardStore;
    +
    +  var DashboardController = React.createClass({
    +
    +    getStoreState: function () {
    +      return {
    +        collection: activeTaskList.getCollection(),
    +
    +        setPolling: activeTaskList.setPolling,
    --- End diff --
    
    Sure! Sorry for the wait in responding. This'll take a bit of explanation, so sorry for
the long message.
    
    One of the ideas in the [flux pattern](https://facebook.github.io/flux/docs/overview.html)
(which we use in Fauxton) is to have one-way communication as shown in the [diagram here](https://github.com/facebook/flux).
Information flows one-way, like so:
    
    1. User clicks on something in a React component,
    2. the component fires an action (in an `actions.js` file),
    3. the action dispatches an event (for us, that's the `FauxtonAPI.dispatch()` call),
    4. stores listen to these events (in their `dispatch()` methods), change the content of
the store, then notify anyone that's interested that the store has changed.
    5. finally, it comes full circle. React components listen for changes in the store by
listening to their change events. That's the purpose of the `storeName.on('change', this.onChange)`
lines.
    
    You're already doing this in your `DashboardController` component, just not for every
item in its state.
    
    So why do all this. The benefit is that it standardizes how data moves around the application,
and keeps things simple - regardless of how much bigger the application gets. This is pretty
cool.
    
    Here's a simple example: imagine if a user shrunk/expanded the main sidebar, and multiple
components in the page needed to know about it to make use of the new space. Maybe one was
a graph and needed to redraw for the extra space, and maybe another component could switch
from "basic" to "advanced" view or something.
    
    With flux, you can just publish the *single* event, then each store could listen for it,
change whatever data was needed internally, then notify any components that was listening:
and they would then have the choice to rerender or not, based on what changed. By setting
content on the store directly like you're doing here, it ties the component to the individual
store and blocks out any other stores which may be interested in the event down the road.
Now true, that may be unimportant in certain cases, but by doing it consistently everywhere,
it makes the whole application super, super easy to follow (albeit a bit verbose at times!).
    
    So what you need to do is replace the `this.state.setPolling();` and `this.state.clearPolling();`
lines with `Actions.setPolling()` and `Actions.clearPolling()` methods (and include your actions.js
file in your `components.react.jsx` file as a dependency). In the `actions.js` file, add those
methods, which just dispatch two new event - just like you're already doing there - defined
in your actiontypes.js file. Then update the store's `dispatch()` method to listen to them,
and do a `this.triggerChange();`. Lastly you can remove `setPolling` and `clearPolling` from
your component's `getStoreState()` method.
    
    It feels a bit weird at first adding in all this extra code for something that works already,
but it'll be better down the road!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message