tomchentw · August 29, 2015 14:17
diff --git a/flux_panel.txt b/flux_panel.txt
 1. Q: Relay and flux, flux future?
 A: Relay -> big app & team

 2. Data fetching
 Kyle: do fetching in stores instead of action creators
 1. large app, use getter of stores and do fetching if required, it'll eventually be there
 2. switch api layer, nice to have data fetching logic in one store, the controller code (action creators) dont have to change
 3. when fetch data, usually need info that you'll already know in stores

 Ian: keep usually in action creators,
 1. fecthing still in stores (same way as Kyle),
 2. doing "writes" in action creators, fire SUCCESS or FAIL event. Since differ stores may need to listen to multiple events. No place to mess up.

 3. Dispatcher scaling issues (106 stores)
 interface laggy, two stores fire change event in respond to same action. debounce calls to setState, 237 -> 58 , 87 -> 24 on change

 4. Dependencies of stores
 use component as data passing layer, explicitly ask from storeA and pass it to storeB
 later, create a mixin to declare dependencies.

 5. Keep application maintainable?
 160k LOC, 10 developers. Componentize everything, great for perf and maintainability. 700+ components.

 6. Store singletons vs instances
 Michael, concurrency issue of singleton in node.js. Testibility since no side effect.n

 Andres, dont use store to fetch data.

 7. Spike, incrementally introducing flux. Write new component in React instead of Backbone.View.
 Wrap model/collections in stores. View and Models are coupled in ad-hoc way in Backbone.

 8. Using dispatchers, use global Backbone app instance (also an EE) as flux dispatcher, injects (DI) that into stors and actions. Notice there's no waitFor.

 9. Optimistic update and error handling: solve it at application level in Relay.

 10. Routing,
 Andres, dont do routing on component level. Instead, store level and respond to action

 11. Question of reusability flux coupled component: container & UI components.
diff --git a/slides.md b/slides.md
	1. Q: Relay and flux, flux future?
	A: Relay -> big app & team

	2. Data fetching
	Kyle: do fetching in stores instead of action creators
	1. large app, use getter of stores and do fetching if required, it'll eventually be there
	2. switch api layer, nice to have data fetching logic in one store, the controller code (action creators) dont have to change
	3. when fetch data, usually need info that you'll already know in stores

	Ian: keep usually in action creators,
	1. fecthing still in stores (same way as Kyle),
	2. doing "writes" in action creators, fire SUCCESS or FAIL event. Since differ stores may need to listen to multiple events. No place to mess up.

	3. Dispatcher scaling issues (106 stores)
	interface laggy, two stores fire change event in respond to same action. debounce calls to setState, 237 -> 58 , 87 -> 24 on change

	4. Dependencies of stores
	use component as data passing layer, explicitly ask from storeA and pass it to storeB
	later, create a mixin to declare dependencies.

	5. Keep application maintainable?
	160k LOC, 10 developers. Componentize everything, great for perf and maintainability. 700+ components.

	6. Store singletons vs instances
	Michael, concurrency issue of singleton in node.js. Testibility since no side effect.n

	Andres, dont use store to fetch data.

	7. Spike, incrementally introducing flux. Write new component in React instead of Backbone.View.
	Wrap model/collections in stores. View and Models are coupled in ad-hoc way in Backbone.

	8. Using dispatchers, use global Backbone app instance (also an EE) as flux dispatcher, injects (DI) that into stors and actions. Notice there's no waitFor.

	9. Optimistic update and error handling: solve it at application level in Relay.

	10. Routing,
	Andres, dont do routing on component level. Instead, store level and respond to action

	11. Question of reusability flux coupled component: container & UI components.
No results found