The ability to reply to discussions is limited to PRO members. Want to join in the discussion? Click here to subscribe now.

Flux Architecture: Application Store

Flux Architecture: Application Store

5:56
In this lesson we'll create our Flux application's store which will manage the state of our application.
Watch this lesson now
Avatar
egghead.io

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

Avatar
Marcus

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

Avatar
Joseph

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

In reply to Marcus
Avatar
Stephen

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

Avatar
Stephen

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.

Avatar
Joseph

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

In reply to Stephen
Avatar
Joseph

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.

In reply to Stephen
Avatar
Stephen

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.

In reply to Joseph
Avatar
Stephen

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.

In reply to Joseph
Avatar
itzikbenh

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

Avatar
itzikbenh

Never mind. Figured it out.

In reply to itzikbenh
Avatar
Mallory

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

In reply to Stephen
Avatar
Shawn

@ time 1:04 there's a typo when declaring cartItems instead of _cartItems. In later videos when I was running the application _cartItems errors as undefined.

In reply to egghead.io
HEY, QUICK QUESTION!
Joel's Head
Why are we asking?