These are chat archives for orbitjs/orbit.js

21st
Feb 2016
Oliver Searle-Barnes
@opsb
Feb 21 2016 11:09
@dgeb I’ve been taking a look at extracting the settling behaviour from Transformable (queues etc.). orbitjs/orbit.js#262
I considered a few approaches
1) A component that sits between the TransformConnectors and the Sources
2) Queues inside the TransformConnectors with upstream connectors configured as blockers
3) A proxy around the Source
Issues with the first two
1) The blocking behaviour is in the component so Source#transform bypasses it.
2) Means that there’s multiple queues per Source so there’s no way to enforce serial processing
The 3rd option does work, it replicates the existing behaviour without losing anything.
Oliver Searle-Barnes
@opsb
Feb 21 2016 11:32
Thought I’d check the you’re happy with the approach before I finish up, the only thing left to do this is split the existing Transformable tests across BlockingTransformableProxy and Transformable. If you are happy with the approach I’m very open to a better name for BlockingTransformableProxy :)
I did consider using a decorator instead of a proxy but it seems we’d need to introduce an additional class to do that, e.g. BlockingMemorySource (MemorySource with a BlockingDecorator applied)
Dan Gebhardt
@dgeb
Feb 21 2016 15:19
@opsb I take it that this proxy layer won't be used with a coordinator, right?
otherwise, if it's always used, why extract it from Transformable
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:20
yeah, it’s purely there to replicate the existing behaviour
Dan Gebhardt
@dgeb
Feb 21 2016 15:21
I wonder if that's simply misleading folks about using coordinators
couldn't we introduce a blocking coordinator instead?
then we can clearly say: coordinators are in charge of queueing
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:23
yeah, if we go with the strategy we talked about last week, where we manage blocking behaviour in the coordinator then this is redundent
I’m taking baby steps really
Dan Gebhardt
@dgeb
Feb 21 2016 15:24
ok, seems fine to spike on this in a branch to keep tests passing and move to coordinators
but I wouldn't want to release this alongside coordinators
because it's a divergent story
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:25
I’m just aware that this is quite a big change, so I’m walking through the transition without making sudden changes
Want to make sure we’re aware of the implications of each change
Seems like the next thing to do would be to introduce a blocking coordinator that can be used instead
Dan Gebhardt
@dgeb
Feb 21 2016 15:26
yeah
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:26
ok, I’ll continue in this branch then and put that together
Dan Gebhardt
@dgeb
Feb 21 2016 15:27
we can't release coordinators and connectors together or there will be confusion for the 2 reasons you gave above
I guess moving everything to coordinators will make them easier to reason about, which is why we decided to go that way
but it means giving up on the completely ad hoc approach possible with orbit now
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:29
that really depends what we make available as “coordinators"
Dan Gebhardt
@dgeb
Feb 21 2016 15:29
true
we could release a really flexible coordinator
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:29
yeah, I think thinner Transformables gives us more flexibility not less
Dan Gebhardt
@dgeb
Feb 21 2016 15:30
I agree
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:31
ok, so if we’re for the simplest first coordinator, what do we want it to do?
I was thinking an in-memory source and a remote source
Dan Gebhardt
@dgeb
Feb 21 2016 15:32
yes, and blocking
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:32
Yeah, ok, that’s a good one to cover
Which got me wondering about the Store api
How are we going to specify blocking vs non-blocking? Or do you mean it always blocks?
So, replicating what ember-data can currently do
Dan Gebhardt
@dgeb
Feb 21 2016 15:33
yeah, always blocking at first
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:33
ok, fine
Dan Gebhardt
@dgeb
Feb 21 2016 15:34
and then we can filter blocking vs non-blocking by op and data type
as a second step
similar to how the connectors work now
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:35
I’d quite like to make it an option in the store api, to allow choosing blocking/non-blocking on a per call basis
do you have a particular scenario in mind?
Dan Gebhardt
@dgeb
Feb 21 2016 15:36
I suppose that is possible - we could allow imperative or declarative options
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:36
I don’t have a need myself so if declarative is what you need I’ll concentrate on that first
Dan Gebhardt
@dgeb
Feb 21 2016 15:37
the scenario I have in mind is allowing non-blocking behavior for types of data / operations that won't conflict with remote changes
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:37
right
Dan Gebhardt
@dgeb
Feb 21 2016 15:37
for instance, additive comments on an article
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:38
ok, that’s a good example to have in mind
so no comment editing then?
I guess conflicts are pretty unlikely :)
Dan Gebhardt
@dgeb
Feb 21 2016 15:39
well, let's say a simple LWW approach
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:39
sure
Dan Gebhardt
@dgeb
Feb 21 2016 15:40
that will match the level of sophistication of 95% of web apps right now
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:40
what will the JSONAPI source emit after a Transform? Presumably JSONAPI returns the whole resource?
Dan Gebhardt
@dgeb
Feb 21 2016 15:40
and seems a good baseline
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:40
yeah
I suppose the JSONAPI source is diffing the returned resource vs the local resource
Dan Gebhardt
@dgeb
Feb 21 2016 15:41
yes
jsonapi returns the whole resource with a 201
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:41
ok, well that all seems fine
Dan Gebhardt
@dgeb
Feb 21 2016 15:42
If a POST request did include a Client-Generated ID and the requested resource has been created successfully, the server MUST return either a 201 Created status code and response document (as described above) or a 204 No Content status code with no response document.
^ another valid scenario when creating resources
so 201 or 204
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:42
right
Dan Gebhardt
@dgeb
Feb 21 2016 15:43
ok, I'm going to continue to work on translating transforms / queries to higher level types
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:43
so it’s simply an implementation choice whether 201 or 204 is returned?
Dan Gebhardt
@dgeb
Feb 21 2016 15:44
if the server adds anything, like an id, then it must return 201
client-generated ids are the edge case
that can return 204
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:44
ha, at the moment
ok
how’s it going with mapping to the higher level types?
Dan Gebhardt
@dgeb
Feb 21 2016 15:45
I think it's going to work well
it removes a lot of translation layers
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:45
haven’t got my head around where that might end up yet
right, interesting
Dan Gebhardt
@dgeb
Feb 21 2016 15:46
I will try to share very soon
Oliver Searle-Barnes
@opsb
Feb 21 2016 15:46
sure, ok, will crack on with this first coordinator
Dan Gebhardt
@dgeb
Feb 21 2016 15:46
:+1:
Oliver Searle-Barnes
@opsb
Feb 21 2016 18:24
@dgeb how are you expecting the error handling to work with coordinators? With connectors I believe they just keep processing transforms i.e. if there’s a remote error then that transform will fail but the next transform(and the rest of the queue) will continue to be processed.
Dan Gebhardt
@dgeb
Feb 21 2016 18:32
@opsb the plan all along has been to keep the queues mutable and pausable so that errors can be handled
the current queues meet those needs but error handling was never introduced into the connectors
we will definitely need some hooks in the coordinators to help developers decide how to proceed
but I have not yet attempted to map out default behavior that should happen, and which should be overrideable
Oliver Searle-Barnes
@opsb
Feb 21 2016 18:46
@dgeb yes, this is going to require some thought, I’ll mull it over this week. If you have any ideas let me know.
Dan Gebhardt
@dgeb
Feb 21 2016 18:47
sure, helping out with the coordinators will be next for me once I finish this refactor
Oliver Searle-Barnes
@opsb
Feb 21 2016 18:48
ok, great, I’m fairly busy this week but if I get time I’ll try and at least sketch out the happy path for a simple coordinator using rxjs
Dan Gebhardt
@dgeb
Feb 21 2016 18:48
ok, sounds good :)