What is dispatcherIndex used for in React TODO example - reactjs

All,
I just start learning React FLUX with Facebook TODO example Here
There is a field in TODO Store called dispatcherIndex, I wonder what that field used for?
Thanks

The dispatcherIndex is never invoked as you normally would expect from a function, i.e., TodoStore.dispatcherIndex().
But since the value of dispatcherIndex is a function call (no just a function, but a function call), that function call happens in the initialization of your object. So when the TodoStore is initialized, this code (the function call) is run:
AppDispatcher.register(function(payload) {
var action = payload.action;
var text;
switch(action.actionType) {
case TodoConstants.TODO_CREATE:
text = action.text.trim();
if (text !== '') {
create(text);
TodoStore.emitChange();
}
break;
case TodoConstants.TODO_DESTROY:
destroy(action.id);
TodoStore.emitChange();
break;
// add more cases for other actionTypes, like TODO_UPDATE, etc.
}
return true; // No errors. Needed by promise in Dispatcher.
})
You're calling AppDispatcher.register and passing it a callback function. This callback you are passing is not executed now, it is registered (added to the _callbacks array) to be called later, whenever you call one of the methods that calls AppDispatcher.handleViewAction, that are TodoActions.create and TodoActions.destroy.

In the code snippet in that page, they have included the tying up of the Dispatcher to the Store within the Store definition and that is what the dispatcherIndex is doing.
However, in the code that has been put on github, this is outside the store definition. In that code, Store definition starts at line 77
var TodoStore = assign({}, EventEmitter.prototype, {
and ends at line 117 after which you are registering the callback
removeChangeListener: function(callback) {
this.removeListener(CHANGE_EVENT, callback);
}
}); //Todo Store definition ends here
// Register callback to handle all updates
AppDispatcher.register(function(action) {
var text;
switch(action.actionType) {
case TodoConstants.TODO_CREATE:
text = action.text.trim();
if (text !== '') {
create(text);
TodoStore.emitChange();
}
break;
Basically, in Flux architecture, flow is unidirectional, so from the React components action is triggered and this action is then dispatched to those stores where the callback has been registered for that action.

Related

React Flux: How do I auto-sort stored array when a new item is added?

I'm trying to figure out the best way of updating a stored array when a new item is added to it.
Right now I'm sorting it with the code below (sortMissions() is called in the AppDispatcher.register code), but it feels inefficient since the array will be sorted every time one of my switch cases is called, even if it's irrelevant to the _missions array (e.g. if _incomplete_missions changes, I'll still be sorting _missions).
//MissionStore.js
// Define initial data points
var _missions = [], _incomplete_missions = [];
// Add a mission to _missions
function addMission(mission){
_missions.push(mission);
}
// Sort _missions as desired
function sortMissions(){
_missions = _(_missions).chain().sortBy('name').sortBy('points').value();
}
...
var MissionStore = _.extend({}, EventEmitter.prototype, {
...
// Return Mission data
getMissions: function() {
return _missions;
},
// emit change event
emitChange: function() {
this.emit('change');
},
// add change listener
addChangeListener: function(callback) {
this.on('change', callback);
},
// remove change listener
removeChangeListener: function(callback) {
this.removeListener('change', callback);
}
});
AppDispatcher.register(function(payload) {
var action = payload.action;
var text;
switch(action.actionType) {
case MissionActionConstants.MISSION_SAVE:
addMission(action.mission);
break;
default:
return true;
}
sortMissions();
MissionStore.emitChange();
return true;
});
I thought about just sorting _missions in MissionStore.getMissions() and no where else, but that will result in sorting it every time getMissions() called, whether anything changed or not.
I also thought about inserting sortMissions() in every dispatcher case that _missions would change, but that seems like I'm duplicating myself.
Ideally I'd like to subscribe to changes just on the _missions array (from within the same store) and sort _missions only when it changes, but I'm not sure how I would do that.
Thanks!
Maybe you should do the sorting in the controller-view, not in the store.
This way, you maintain only one collection of missions, and this could be immutable data. I recommend ImmutableJS for that.
Then, if MissionsStore.getMissions() !== this.state.missions, you do the sort and then pass the sorted collection to this.setState().
Otherwise, I think you're looking at maintaining a separate cached collection for every type of sort, which seems like a lot to maintain. But it's certainly a viable alternative.

Extended event emitter functions across stores are clashing in Flux

I have multiple Flux stores. Now clearly, all of them are extending the same Event emitter singleton. This has led to events across stores clashing with each other (even the most common, emitChange). There seems to be no difference between doing Store1.getID() and Store2.getID(), because stores seem to be one large object extended from every other store. What am I doing wrong?
I have been having this issue for a while now, and its driving me nuts. I am sure this has a simple answer that I am missing. It's one of the reasons I am waiting for relay and GraphQL.
EDIT: What all my stores look like in code.
var Events = require('events'), extend = require('deep_extend'),
EventEmitter = Events.EventEmitter,
CHANGE_EVENT = 'change';
var SomeStore = extend(EventEmitter.prototype, {
someGetter: function(){
return _someVar;
},
dispatchToken: AppDispatcher.register(function(action) {
switch(action.type) {
case 'SOME_ACTION':
_someVar = 'someValue'
break;
default:
return true;
}
SomeStore.emitChange();
return true;
})
});
return SomeStore;
stores seem to be one large object extended from every other store.
There must be some problem with how you extend from EventEmitter otherwise your code should be working fine.
Now that there are a few ways to do the same thing, here is how facebook implemented it in their official examples:
var assign = require('object-assign');
var EventEmitter = require('events').EventEmitter;
var TodoStore = assign({}, EventEmitter.prototype, {
...
UPDATE
Now looking at your code
extend(EventEmitter.prototype, {
is actually writing on the prototype itself, hence the errors you got. Instead you should be extending an empty object:
extend({}, EventEmitter.prototype, {

Re-subscribe to an observable with rx-angular

I'd like to use angular-rx for a simple refresh button for results. If the user clicks the refresh button the results are reloaded. If the user clicks the the refresh button 100times in 1 second, only the latest results are loaded. If the results failed for some reason, that doesn't mean the refresh button should stop working.
To achieve the last point I'd like to keep a subscription (or resubscribe) even if it fails, but I can not work out how to do that?
This doesn't work, but here's a simple example where I try resubscribing on error:
var refreshObs = $scope.$createObservableFunction('refresh');
var doSubscribe = function () {
refreshObs
.select(function (x, idx, obs) {
// get the results.
// in here might throw an exception
})
.switch()
.subscribe(
function (x) { /*show the results*/ }, // on next
function (err) { // on error
doSubscribe(); // re-subscribe
},
function () { } // on complete
);
};
doSubscribe();
I figure this is common enough there should be some standard practice to achieve this?
UPDATE
Using the suggested solution, this is what I've made to test:
// using angularjs and the rx.lite.js library
var testCount = 0;
var obsSubject = new rx.Subject(); // note. rx is injected but is really Rx
$scope.refreshButton = function () { // click runs this
obsSubject.onNext();
};
obsSubject.map(function () {
testCount++;
if (testCount % 2 === 0) {
throw new Error("something to catch");
}
return 1;
})
.catch(function (e) {
return rx.Observable.return(1);
})
.subscribe(
function (x) {
// do something with results
});
And these are my test results:
Refresh button clicked
obsSubject.onNext() called
map function returns 1.
subscribe onNext is fired
Refresh button clicked
obsSubject.onNext() called
map function throw error
enters catch function
subscribe onNext is fired
Refresh button clicked
obsSubject.onNext() called
Nothing. I need to keep subscription
My understanding is that catch should keep the subscription, but my testing indicates it doesn't. Why?
Based on the context given in your comment, you want:
Every refresh button to trigger a 'get results'
Every error to be displayed to the user
You really do not need the resubscribing, it's an anti-pattern because code in Rx never depends on that, and the additional recursive call just confuses a reader. It also reminds us of callback hell.
In this case, you should:
Remove the doSubscribe() calls, because you don't need them. With that code, you already have the behavior that every refresh click will trigger a new 'get results'.
Replace select().switch() with .flatMap() (or .flatMapLatest()). When you do the select(), the result is a metastream (stream of streams), and you are using switch() to flatten the metastream into a stream. That's all what flatMap does, but in one operation only. You can also understand flatMap as .then() of JS Promises.
Include the operator .catch() which will treat your error, as in a catch block. The reason you can't get more results after an error happens, is that an Observable is always terminated on an error or on a 'complete' event. With the catch() operator, we can replace errors with sane events on the Observable, so that it can continue.
To improve your code:
var refreshObs = $scope.$createObservableFunction('refresh');
refreshObs
.flatMapLatest(function (x, idx, obs) {
// get the results.
// in here might throw an exception
// should return an Observable of the results
})
.catch(function(e) {
// do something with the error
return Rx.Observable.empty(); // replace the error with nothing
})
.subscribe(function (x) {
// on next
});
Notice also that I removed onError and onComplete handlers since there isn't anything to do inside them.
Also take a look at more operators. For instance retry() can be used to automatically 'get results' again every time an error happens. See https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/retry.md
Use retry() in combination with do() in order to handle the error (do), and allow the subscriber to automatically resubscribe to the source observable (retry).
refreshObs
.flatMapLatest(function (x, idx, obs) {
// get the results.
// in here might throw an exception
// should return an Observable of the results
})
.do(function(){}, // noop for onNext
function(e) {
// do something with the error
})
.retry()
.subscribe(function (x) {
// on next
});
See a working example here: http://jsfiddle.net/staltz/9wd13gp9/9/

How do you tell when a view is loaded in extjs?

Im working on an extjs application. We're have a page that is for looking at a particular instance of an object and viewing and editing it's fields.
We're using refs to get hold of bits of view in the controller.
This was working fine, but I've been sharding the controller into smaller pieces to make it more managable and realised that we are relying on a race condition in our code.
The logic is as follows:
Initialise the controller
parse the url to extract the id of the object
put in a call to load the model with the given view.
in the load callback call the controller load method...
The controller load method creates some stores which fire off other requests for bits of information using this id. It then uses some of the refs to get hold of the view and then reconfigures them to use the stores when they load.
If you try and call the controller load method immediately (not in the callback) then it will fail - the ref methods return undefined.
Presumably this is because the view doesnt exist... However we aren't checking for that - we're just relying on the view being loaded by the time the server responds which seems like a recipe for disaster.
So how can we avoid this and be sure that a view is loaded before trying to use it.
I haven't tried rewriting the logic here yet but it looks like the afterrender event probably does what I want.
It seems like waiting for both the return of the store load and afterrender events should produce the correct result.
A nice little abstraction here might be something like this:
yourNamespace.createWaitRunner = function (completionCallback) {
var callback = completionCallback;
var completionRecord = [];
var elements = 0;
function maybeFinish() {
var done = completionRecord.every(function (element) {
return element === true
});
if (done)
completionCallback();
}
return {
getNotifier: function (func) {
func = func || function (){};
var index = elements++;
completionRecord[index] = false;
return function () {
func(arguments);
completionRecord[index] = true;
maybeFinish();
}
}
}
};
You'd use it like this:
//during init
//pass in the function to call when others are done
this.waiter = yourNamespace.createWaitRunner(controller.load);
//in controller
this.control({
'SomeView': {
afterrender: this.waiter.getNotifier
}
});
//when loading record(s)
Ext.ModelManager.getModel('SomeModel').load(id, {
success: this.waiter.getNotifier(function (record, request) {
//do some extra stuff if needs be
me.setRecord(record);
})
});
I haven't actually tried this out yet so it might not be 100% but I think the idea is sound

Angularjs promise not binding to template in 1.2

After upgrading to 1.2, promises returned by my services behave differently...
Simple service myDates:
getDates: function () {
var deferred = $q.defer();
$http.get(aGoodURL).
success(function (data, status, headers, config) {
deferred.resolve(data); // we get to here fine.
})......
In earlier version I could just do, in my controller:
$scope.theDates = myDates.getDates();
and the promises returned from getDates could be bound directly to a Select element.
Now this doesn't work and I'm forced to supply a callback on the promise in my controller or the data wont bind:
$scope.theDates = matchDates.getDates();
$scope.theDates.then(function (data) {
$scope.theDates = data; // this wasn't necessary in the past
The docs still say:
$q promises are recognized by the templating engine in angular, which means that in templates you can treat promises attached to a scope as if they were the resulting values.
They (promises) were working in older versions of Angular but in the 1.2 RC3 automatic binding fails in all my simple services.... any ideas on what I might be doing wrong.
There are changes in 1.2.0-rc3, including one you mentioned:
AngularJS 1.2.0-rc3 ferocious-twitch fixes a number of high priority
issues in $compile and $animate and paves the way for 1.2.
This release also introduces some important breaking changes that in some cases could break your directives and templates. Please
be sure to read the changelog to understand these changes and learn
how to migrate your code if needed.
For full details in this release, see the changelog.
There is description in change log:
$parse:
due to 5dc35b52, $parse and templates in general will no longer automatically unwrap promises. This feature has been deprecated and
if absolutely needed, it can be reenabled during transitional period
via $parseProvider.unwrapPromises(true) api.
due to b6a37d11, feature added in rc.2 that unwraps return values from functions if the values are promises (if promise unwrapping is
enabled - see previous point), was reverted due to breaking a popular
usage pattern.
As #Nenad notices, promises are no longer automatically dereferenced. This is one of the most bizarre decisions I've ever seen since it silently removes a function that I relied on (and that was one of the unique selling points of angular for me, less is more). So it took me quite a bit of time to figure this out. Especially since the $resource framework still seems to work fine. On top of this all, this is also a release candidate. If they really had to deprecate this (the arguments sound very feeble) they could at least have given a grace period where there were warnings before they silently shut it off. Though usually very impressed with angular, this is a big minus. I would not be surprised if this actually will be reverted, though there seems to be relatively little outcry so far.
Anyway. What are the solutions?
Always use then(), and assign the $scope in the then method
function Ctrl($scope) {
foo().then( function(d) { $scope.d = d; });
)
call the value through an unwrap function. This function returns a field in the promise and sets this field through the then method. It will therefore be undefined as long as the promise is not resolved.
$rootScope.unwrap = function (v) {
if (v && v.then) {
var p = v;
if (!('$$v' in v)) {
p.$$v = undefined;
p.then(function(val) { p.$$v = val; });
}
v = v.$$v;
}
return v;
};
You can now call it:
Hello {{ unwrap(world) }}.
This is from http://plnkr.co/edit/Fn7z3g?p=preview which does not have a name associated with it.
Set $parseProvider.unwrapPromises(true) and live with the messages, which you could turn off with $parseProvider.logPromiseWarnings(false) but it is better to be aware that they might remove the functionality in a following release.
Sigh, 40 years Smalltalk had the become message that allowed you to switch object references. Promises as they could have been ...
UPDATE:
After changing my application I found a general pattern that worked quite well.
Assuming I need object 'x' and there is some way to get this object remotely. I will then first check a cache for 'x'. If there is an object, I return it. If no such object exists, I create an actual empty object. Unfortunately, this requires you to know if this is will be an Array or a hash/object. I put this object in the cache so future calls can use it. I then start the remote call and on the callback I copy the data obtained from the remote system in the created object. The cache ensures that repeated calls to the get method are not creating lots of remote calls for the same object.
function getX() {
var x = cache.get('x');
if ( x == undefined) {
cache.put('x', x={});
remote.getX().then( function(d) { angular.copy(d,x); } );
}
return x;
}
Yet another alternative is to provide the get method with the destination of the object:
function getX(scope,name) {
remote.getX().then( function(d) {
scope[name] = d;
} );
}
You could always create a Common angular service and put an unwrap method in there that sort of recreates how the old promises worked. Here is an example method:
var shared = angular.module("shared");
shared.service("Common", [
function () {
// [Unwrap] will return a value to the scope which is automatially updated. For example,
// you can pass the second argument an ng-resource call or promise, and when the result comes back
// it will update the first argument. You can also pass a function that returns an ng-resource or
// promise and it will extend the first argument to contain a new "load()" method which can make the
// call again. The first argument should either be an object (like {}) or an array (like []) based on
// the expected return value of the promise.
// Usage: $scope.reminders = Common.unwrap([], Reminders.query().$promise);
// Usage: $scope.reminders = Common.unwrap([], Reminders.query());
// Usage: $scope.reminders = Common.unwrap([], function() { return Reminders.query(); });
// Usage: $scope.reminders.load();
this.unwrap = function(result, func) {
if (!result || !func) return result;
var then = function(promise) {
//see if they sent a resource
if ('$promise' in promise) {
promise.$promise.then(update);
}
//see if they sent a promise directly
else if ('then' in promise) {
promise.then(update);
}
};
var update = function(data) {
if ($.isArray(result)) {
//clear result list
result.length = 0;
//populate result list with data
$.each(data, function(i, item) {
result.push(item);
});
} else {
//clear result object
for (var prop in result) {
if (prop !== 'load') delete result[prop];
}
//deep populate result object from data
$.extend(true, result, data);
}
};
//see if they sent a function that returns a promise, or a promise itself
if ($.isFunction(func)) {
// create load event for reuse
result.load = function() {
then(func());
};
result.load();
} else {
then(func);
}
return result;
};
}
]);
This basically works how the old promises did and auto-resolves. However, if the second argument is a function it has the added benefit of adding a ".load()" method which can reload the value into the scope.
angular.module('site').controller("homeController", function(Common) {
$scope.reminders = Common.unwrap([], Reminders.query().$promise);
$scope.reminders = Common.unwrap([], Reminders.query());
$scope.reminders = Common.unwrap([], function() { return Reminders.query(); });
function refresh() {
$scope.reminders.load();
}
});
These were some good answers, and helped me find my issue when I upgraded angular and my auto-unwrapping of promises stopped working.
At the risk of being redundant with Peter Kriens, I have found this pattern to work for me (this is a simple example of simply putting a number of famous people's quotes onto a page).
My Controller:
angular.module('myModuleName').controller('welcomeController',
function ($scope, myDataServiceUsingResourceOrHttp) {
myDataServiceUsingResourceOrHttp.getQuotes(3).then(function (quotes) { $scope.quotes = quotes; });
}
);
My Page:
...
<div class="main-content" ng-controller="welcomeController">
...
<div class="widget-main">
<div class="row" ng-repeat="quote in quotes">
<div class="col-xs-12">
<blockquote class="pull-right">
<p>{{quote.text}}</p>
<small>{{quote.source}}</small>
</blockquote>
</div>
</div>
</div>
...

Resources