Explain /why/ for the the 4 instance queues on the main page

[JaneOri]

Add overview explaining WHY the 4 instance queues are set up the way they are.

After this is merged: https://github.com/canjs/can-queues/pull/8

docs/can-queues.md will be the file that needs to present context/reasoning for the relations between the 4 instance queues.

(the relationships are detailed in docs/instances.queues.md of that same PR but don't say why)

[JaneOri]

Notes from our conversation about this:

Assurances of state Lets see how this plays out in a small example

var o1 = new Observation(() => { p.first + p.last })

var o2 = new Observation(() => { p.first + p.last })

What happens if o1 and o2 read each other in handlers as follows when the state changes

o1.on(function(){
   o2() //-> "Ramiya Meyer"
   p.last = "Foobart"
})

o2.on(function(newValue){
   o1() //->  "Ramiya Meyer"
})
p.first = "Ramiya"

.combine(s1,s2).onValue(function(){

}).toProperty()

var o1 = new Observation(() => { p.first + p.last })

var o2 = new Observation(() => { p.first + p.last })

[NOTIFY, DERIVE, DomUI, Mutate]

function(){
    this.state = "newState";
    domModify()
},
function(){
    doSomethingElse()
}

[JaneOri]

I tried thinking over the weekend how best to describe it and couldn't land on anything solid because I don't fully understand what specifically each layer is used for.

Some notes on how I was picturing it that may help write about it:

• Think about it as layers
• "User" layer (mutate) is patient and ordered
  • if we make a change, it expects everything to be settled before we make another change
• ...
• deepest layer (notify) is busy and "high maintenance"
  • as soon as something is enqueued it wants to tell everything
  • everything flushes when notify flushes

I think just coming up with a practical/real example of each of the layers in action would be a good starting point. The example from our convo, for example, doesn't make sense so it's a hurdle in understanding the why of the queue relationships. I had an idea for what might make a good example though:

• A simple adding app with a number input and a button to add whatever's in the input to the current total.

Maybe a mini guide of what queues are involved in that ^ as you walk through each step of using the app would be a solid/easy way to grasp the reason for it all?

[justinbmeyer]

Why doesn’t what we talked about make sense? I’m not sure why an adding app would make more sense (it needs a compute, why it doesn’t seem to need).

Sent from my iPhone

On Nov 12, 2017, at 7:49 PM, James Atherton notifications@github.com wrote:

I tried thinking over the weekend how best to describe it and couldn't land on anything solid because I don't fully understand what specifically each layer is used for.

Some notes on how I was picturing it that may help write about it:

Think about it as layers "User" layer (mutate) is patient and ordered if we make a change, it expects everything to be settled before we make another change ... deepest layer (notify) is busy and "high maintenance" as soon as something is enqueued it wants to tell everything everything flushes when notify flushes I think just coming up with a practical/real example of each of the layers in action would be a good starting point. The example from our convo, for example, doesn't make sense so it's a hurdle in understanding the why of the queue relationships. I had an idea for what might make a good example though:

A simple adding app with a number input and a button to add whatever's in the input to the current total. Maybe a mini guide of what queues are involved in that ^ as you walk through each step of using the app would be a solid/easy way to grasp the reason for it all?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.