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 [email protected] or file a JIRA ticket
with INFRA.
---
