Flux Architecture: Application Store

In app-stores.js, why did you use function instead of an arrow function in dispatcherIndex: register(functi...?

Old habits, good catch. This could easily be updated to: register( action => {

Joe... When you defined AppStore, the first argument to Object.assign (called the target object) should have been “{}”. As it stands, EventEmitter.prototype has now been mutated to include the subsequently defined properties (getCart, etc.).

Joe… When defining “dispatcherIndex”, you placed “AppStore.emitChange()” after the switch block (rather than within each case statement of the switch block). Consequently, AppStore will end up processing call-backs for every action coming through the dispatcher, even though most of these actions will not affect the state of AppStore.

All of the actions in dispatcherIndex have an effect on the state of AppStore.

Thanks for the feedback, Stephen. Extending EventEmitter.prototype presents no ill side effects in this application, but yes, I could have done it the way you've suggested.

All of the actions in dispatcherIndex have an effect on the state of AppStore.

I agree. But as your application grows, you will likely to add another store for a feature which is not core to the shopping cart (e.g. wish lists). This new store will have a new set of action types associated with it. As the Flux dispatcher will route all actions to all stores, the AppStore will receive actions which it will not process. When this happens, the present code will cause AppStore to signal a change (call its subscribers) even though its state has not changed.

Thanks for the feedback, Stephen. Extending EventEmitter.prototype presents no ill side effects in this application, but yes, I could have done it the way you've suggested.

As presently coded, the AppStore object IS EventEmitter.prototype (which has now been modified with extra methods). There has been no inheritance (I use the term loosely) of functionality, they are the same object! My concern is that when you create your next store (e.g. wish lists), you will again extend EventEmitter.prototype. Now both stores will be the same object, will have a single call-back list, and possibly overwritten methods. Not good.

What's the point of the third argument? return Object.assign( {}, item, _cartItems.find( cItem => cItem.id === item.id)) Do we really need it?

Never mind. Figured it out.

When this happens, the present code will cause AppStore to signal a change (call its subscribers) even though its state has not changed.

Yes ! I got the problem today and raged for a few hours before remembering your comment. So thank you, it helped a lot, but we should find a way to make it more visible