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
Dan Gebhardt
@dgeb
i.e. moving the queues
Oliver Searle-Barnes
@opsb
yes, it’s all in the, slightly inappropriately named now, PR orbitjs/orbit.js#265
Dan Gebhardt
@dgeb
gotcha - that's what I figured
:+1:
Oliver Searle-Barnes
@opsb
Think you could do a little PR just for the fetch change first?
Dan Gebhardt
@dgeb
sure thing
Oliver Searle-Barnes
@opsb
great
thanks
Dan Gebhardt
@dgeb
np
Oliver Searle-Barnes
@opsb
just reviewed ember-concurrency, as it’s built on Observable there should be nice some integration opportunities with liveQueries
Dan Gebhardt
@dgeb
yeah, it's got a nice API - looking forward to trying it out
Dan Gebhardt
@dgeb
@opsb what do you think about beforeQuery / query / queryFail, beforeTranform / transform / transformFail, beforeFetch / fetch / fetchFail events?
Oliver Searle-Barnes
@opsb
I have been thinking about that a little
what do we currently have?
just the query ones?
Dan Gebhardt
@dgeb
yes
imo they should be consistent
they can lead to interesting composition patterns
but they can be a little expensive
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 :)