@barriehadfield reading through the docs again... how pleasant! I thought on the stores example... why not just keep using the discounter store, but divide the display into two separate components, or maybe add some other functionality like DisplayTotals (that takes a subtotal, and displays it followed by the discount value) something like that? maybe easier to follow?
also I still feel (but not super strongly just want you to consider it) that it might be better to go component -> stores -> operations -> policies -> models
A couple of reasons, 1) models are built on top of everything else, 2) models are optional, but any realistic app is going to have C/S & O, 3) in the above order the policy document can deal with channels (which is what operations are based on) and then in the model section the model specific policies can be introduced.
You could also break operations in to 2 sections operations, and isomorphic operations.
Mitch VanDuyn @catmando 17:43
I like you Operations are the Engine Rooms of Hyperloop. NICE.
Barrie Hadfield @barriehadfield 17:45
thanks @catmando - good suggestions
Mitch VanDuyn @catmando 17:46
Actually you could split it like this:
Operations, followed by Isomorphic Execution (?) which would contain the ServerOps class AND the channel policies since they go hand in hand.
that sets the foundation for understanding (and by the way implementing) models
since models are nothing more than stores with state associated to active record model data, and operations which keep the data synced
Barrie Hadfield @barriehadfield 17:51
I think though there is a step change in complexity, channels and policy are complex whereas Models are really simple to understand, so I quite like them early in the reading experience
Mitch VanDuyn @catmando 17:52
I think from a "sales" perspective its very cool.
Barrie Hadfield @barriehadfield 17:52
Operations could come earlier though as you suggest
Mitch VanDuyn @catmando 17:53
This is why I am advocating "local" operations, first, which obviously are quite simple, and solve obvious problems presented by Components and Stores.
Barrie Hadfield @barriehadfield 17:54
umm - let me chew on that
Mitch VanDuyn @catmando 17:55
Once you have gotten through that, then introducing the magic of an isomorphic operation is the next step, and that is conceptually very simple: I want this operation while invoked on the client to actually run on the server.
This introduces really just one new concept: The idea of an acting_user.
Barrie Hadfield @barriehadfield 17:56
have to go now, but I will take that on and respond tomorrow morning (hope to get up early)
Mitch VanDuyn @catmando 17:56
Then you can introduce the dispatches_to method, which is where channels come in.
its all about controlling which clients get the dispatches
again a nice simple concept.
anyway... have a good evening!
@barriehadfield reading through the docs again... how pleasant! I thought on the stores example... why not just keep using the discounter store, but divide the display into two separate components, or maybe add some other functionality like DisplayTotals (that takes a subtotal, and displays it followed by the discount value) something like that? maybe easier to follow? also I still feel (but not super strongly just want you to consider it) that it might be better to go component -> stores -> operations -> policies -> models A couple of reasons, 1) models are built on top of everything else, 2) models are optional, but any realistic app is going to have C/S & O, 3) in the above order the policy document can deal with channels (which is what operations are based on) and then in the model section the model specific policies can be introduced. You could also break operations in to 2 sections operations, and isomorphic operations.
Mitch VanDuyn @catmando 17:43 I like you Operations are the Engine Rooms of Hyperloop. NICE.
Barrie Hadfield @barriehadfield 17:45 thanks @catmando - good suggestions
Mitch VanDuyn @catmando 17:46 Actually you could split it like this: Operations, followed by Isomorphic Execution (?) which would contain the ServerOps class AND the channel policies since they go hand in hand. that sets the foundation for understanding (and by the way implementing) models since models are nothing more than stores with state associated to active record model data, and operations which keep the data synced
Barrie Hadfield @barriehadfield 17:51 I think though there is a step change in complexity, channels and policy are complex whereas Models are really simple to understand, so I quite like them early in the reading experience
Mitch VanDuyn @catmando 17:52 I think from a "sales" perspective its very cool.
Barrie Hadfield @barriehadfield 17:52 Operations could come earlier though as you suggest
Mitch VanDuyn @catmando 17:53 This is why I am advocating "local" operations, first, which obviously are quite simple, and solve obvious problems presented by Components and Stores.
Barrie Hadfield @barriehadfield 17:54 umm - let me chew on that
Mitch VanDuyn @catmando 17:55 Once you have gotten through that, then introducing the magic of an isomorphic operation is the next step, and that is conceptually very simple: I want this operation while invoked on the client to actually run on the server. This introduces really just one new concept: The idea of an acting_user.
Barrie Hadfield @barriehadfield 17:56 have to go now, but I will take that on and respond tomorrow morning (hope to get up early)
Mitch VanDuyn @catmando 17:56 Then you can introduce the dispatches_to method, which is where channels come in. its all about controlling which clients get the dispatches again a nice simple concept. anyway... have a good evening!