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
yeah, I think it’s a good idea
right
what makes you say they (can be) expensive?
depending on the listeners?
Dan Gebhardt
@dgeb
if they are in a hot path, they require creating several promises
Oliver Searle-Barnes
@opsb
they currenty use settle right?
I was thinking we could use emit instead
(which I think would make them cheaper in a couple of senses)
Dan Gebhardt
@dgeb
yes, but using settle allows for the interesting composition patterns
Oliver Searle-Barnes
@opsb
I guess it allows the listener to decide whether it should be blocking or not
Dan Gebhardt
@dgeb
right
well, let's leave them for now
Oliver Searle-Barnes
@opsb
yeah, think we need a concrete case to make that call
Dan Gebhardt
@dgeb
yes
we should simply make sure that they are consistent across Fetchable, Queryable, and Transformable for now
Oliver Searle-Barnes
@opsb
yeah, I think that would be useful, I did consider using those events instead of the promise returned from source.transform() for instance
Dan Gebhardt
@dgeb
ok
I've always thought they have potential - will be interesting to see how they are used
I think I should probably move away from the mixin approach, so we can move to straight es classes
maybe follow the Evented.extend pattern instead
within sources
so they will call Transformable.extend(this) for instance
in the constructor
would be great to remove Orbit.Class
Oliver Searle-Barnes
@opsb
yeah, that would be nice now we have bonefide ES classes
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)