Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:59

    dgeb on master

    Update CHANGELOG (compare)

  • 01:55
    dgeb labeled #215
  • Aug 20 15:47
    Travis orbitjs/ember-orbit (v0.16.1) passed (683)
  • Aug 20 15:42
    cibernox commented #215
  • Aug 20 15:39
    dgeb commented #215
  • Aug 20 15:37

    dgeb on v0.16.1

    (compare)

  • Aug 20 15:37

    dgeb on master

    v0.16.1 (compare)

  • Aug 20 15:22
    dgeb closed #213
  • Aug 20 15:22
    dgeb commented #213
  • Aug 20 15:21

    dgeb on master

    Fix in Ember 3.11+ Merge pull request #215 from ci… (compare)

  • Aug 20 15:21
    dgeb closed #215
  • Aug 20 15:06
    cibernox synchronize #215
  • Aug 20 14:57
    dgeb labeled #192
  • Aug 20 14:56
    dgeb labeled #211
  • Aug 20 14:53
    dgeb synchronize #215
  • Aug 20 14:40
    dgeb commented #215
  • Aug 20 14:01
    cibernox commented #215
  • Aug 20 13:57
  • Aug 20 13:57
    tchak commented #215
  • Aug 20 13:52
    cibernox synchronize #215
Oliver Searle-Barnes
@opsb
ok, merged
Dan Gebhardt
@dgeb
thanks :)
Oliver Searle-Barnes
@opsb
@dgeb I’ve closed the blocking-coordinator PR and opened orbitjs/orbit.js#268
I’ve consolidated things, it’s green up until the final commit which introduces an integration test that includes the JSON API soure and also the blocking behaviour in the Store.
I’m going to take a break now (I’ll still be around if you have any questions). My intention is to pick it up in the evenings this week but if it becomes a blocker then it should be in a form where you can pick it up fairly easily now.
Note I’ve cleared out the blocking connectors etc. as they’re not necessary in the final approach (blocking at the store).
Dan Gebhardt
@dgeb
@opsb ok, thanks for the update
so you're feeling pretty good about the commits up until the last wip?
Oliver Searle-Barnes
@opsb
It’s largely removing the transform-connector and related integration tests (most of them) and then introducing new components that are used by the final wip commit
So perhaps we could merge them in
Dan Gebhardt
@dgeb
are we sure about removing the connectors? they still seem appealing for ad hoc one way connections between sources (i.e. that don't require confirmation)
Oliver Searle-Barnes
@opsb
In their current form they don’t really offer much over
source.on(’transform’, t => target.transform(t));
Dan Gebhardt
@dgeb
I agree - not too much
there is the blocking flag
plus activation / deactivation
and a shouldTransform method that can be overridden
they are very thin
Oliver Searle-Barnes
@opsb
yeah, am I thinking, but they seem like features without a purpose at the moment
and shouldTransform is very easily emulated using the above pattern
Dan Gebhardt
@dgeb
that's true
and so is blocking
Oliver Searle-Barnes
@opsb
yeah
Dan Gebhardt
@dgeb
although that might not be obvious with the t => target.transform(t) form
that that is blocking I mean
Oliver Searle-Barnes
@opsb
true
if we’re moving blocking to the store though, I’m not sure that we should be concerned with that
Dan Gebhardt
@dgeb
we still have promise-aware events like beforeTransform / transform / afterTransform
and those can block
Oliver Searle-Barnes
@opsb
we could introduce helpers
source.on(’transform’, t => blocking(target.transform(t)));
source.on(’transform’, t => nonBlocking(target.transform(t)));
Dan Gebhardt
@dgeb
true
it seems worthwhile to keep the connectors if they can have a queue
because that's kind of critical if queues are off the sources themselves
Oliver Searle-Barnes
@opsb
I quite like that the queue is a standalone component in the scenario I’ve been putting together
Dan Gebhardt
@dgeb
ok
Oliver Searle-Barnes
@opsb
I’ve always thought it would be nice to have a set of small components that we just chain together
more of a DSL I suppose
Dan Gebhardt
@dgeb
yeah, that is appealing
so let's see how cleanly we could simulate blocking connectors with a queue
Oliver Searle-Barnes
@opsb
ok
I think it would be
source.on('transform', t => queue.add(t));
queue.on('transform', t => blocking(target.transform(t)));
Dan Gebhardt
@dgeb
seems good :shipit:
Oliver Searle-Barnes
@opsb
ha
Dan Gebhardt
@dgeb
I think people playing with low-level orbit connections should be able to handle that :P
Oliver Searle-Barnes
@opsb
ha
yeah, I think we can assume a little technical competence ;)
Dan Gebhardt
@dgeb
yeah, I'm afraid that orbit originally looked too approachable and then people fell off a cliff
Oliver Searle-Barnes
@opsb
ha, yeah, I’m just landing ;)
Dan Gebhardt
@dgeb
ha!
same
now we are creating something that is less of a black box at this level