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
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
but at the higher levels, like ember-orbit, it should be very friendly
Oliver Searle-Barnes
@opsb
yes, I’m keen to make it a pleasurable experience
ember-data falls short there

BTW, the previous line of thought was partly what led me to Observables, we could represent

source.on('transform', t => queue.add(t));
queue.on('transform', t => blocking(target.transform(t)));

as

source.transforms.queue.subscribe(target);
(even simpler)