Flux Architecture: Application Store

Joe Maddalone
InstructorJoe Maddalone

Share this video with your friends

Send Tweet

In this lesson we'll create our Flux application's store which will manage the state of our application.

Marcus Stenbeck
Marcus Stenbeck
~ 6 years ago

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

Joe Maddalone
Joe Maddaloneinstructor
~ 6 years ago

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

Stephen Turner
Stephen Turner
~ 5 years ago

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.).

Stephen Turner
Stephen Turner
~ 5 years ago

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.

Joe Maddalone
Joe Maddaloneinstructor
~ 5 years ago

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

Joe Maddalone
Joe Maddaloneinstructor
~ 5 years ago

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.

Stephen Turner
Stephen Turner
~ 5 years ago

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.

Stephen Turner
Stephen Turner
~ 5 years ago

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.

itzikbenh
itzikbenh
~ 5 years ago

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

itzikbenh
itzikbenh
~ 5 years ago

Never mind. Figured it out.

Mallory
Mallory
~ 5 years ago

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