Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 21 09:44
    YoranBrondsema commented #213
  • Aug 21 01:59

    dgeb on master

    Update CHANGELOG (compare)

  • Aug 21 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
Oliver Searle-Barnes
@opsb
If we follow the Evented.extend pattern it should be easy to convert them to decorators once they arrive.
Dan Gebhardt
@dgeb
yeah, that's the right end goal
I'm already refactoring to Queryable.extend
Dan Gebhardt
@dgeb
@opsb orbitjs/orbit.js#267
Oliver Searle-Barnes
@opsb
that was fast! ok, reviewing
Dan Gebhardt
@dgeb
should be pretty uncontroversial :)
Oliver Searle-Barnes
@opsb
yep, I added a couple of code golfing comments but LGTM
Dan Gebhardt
@dgeb
thanks - I'll clean those up and merge
Oliver Searle-Barnes
@opsb
added one more for the golfing
Promise.prototype.tap would be really useful in some of those promise heavy sections. I added a monkey patch for the tests to use, not something I’d do outside of the test env though.
Dan Gebhardt
@dgeb
yeah
ok, just fixed those up - please merge when ready
I'll steer clear of Transformable for now, since that's in your WIP
and I'll get back to jsonapi after some lunch
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