These are chat archives for orbitjs/orbit.js

4th
Jan 2016
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:09

@dgeb I’ve been laid up in bed for the last week so I’ve postponed my holiday until later in the month.

I think ember-orbit isn’t too far off now, I’m aiming to pull things together over the next week or so and then start integrating it with https://github.com/opsb/chatty-web.

Dan Gebhardt
@dgeb
Jan 04 2016 02:12
@opsb hey, happy new year!
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:12
Ah yes, and happy new year!
Dan Gebhardt
@dgeb
Jan 04 2016 02:12
sorry to hear that you've been sick
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:12
Kind of missed it this year
Dan Gebhardt
@dgeb
Jan 04 2016 02:12
are you feeling any better?
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:12
yeah, antibiotics to the rescue (I caved in the end)
Dan Gebhardt
@dgeb
Jan 04 2016 02:13
phew
sometimes you just have to
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:13
yeah, was glad I did, they definitely do the job
Dan Gebhardt
@dgeb
Jan 04 2016 02:13
nice
so I'll be getting back to business with orbit this week as well
trying to catch up with your work
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:14
ha, yeah, there’s a bit of a code dump for ya ;)
Dan Gebhardt
@dgeb
Jan 04 2016 02:14
no doubt :)
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:14
ember-orbit is definitely looking a lot leaner though
Dan Gebhardt
@dgeb
Jan 04 2016 02:14
really need to merge rethink into master soon
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:14
yeah
Dan Gebhardt
@dgeb
Jan 04 2016 02:14
so you've got a lot of questions in the ember-orbit PR
I need to consider
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:15
yeah, there’s a few things
I’ve tried to keep things fairly aligned with what was there before
Dan Gebhardt
@dgeb
Jan 04 2016 02:15
nice
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:15
It’s fairly loose though as a fair chunk of it was rewritten
but I don’t think there’ll be any major surprises
Only big difference I think is in how it’s bootstrapped
Dan Gebhardt
@dgeb
Jan 04 2016 02:16
how do you mean?
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:16
I’ve used orbit’s Store more as a facade, so it’s the only thing that’s injected now (rather than Store, Sources etc.)
Dan Gebhardt
@dgeb
Jan 04 2016 02:16
ah right
have you integrated Orbit.Transaction as well?
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:17
I think when we convert it to an ember-addon we need to think about the best way to configure it
yeah, that’s working now
Dan Gebhardt
@dgeb
Jan 04 2016 02:17
nice
yeah, it's overdue to be a true addon
we have waited so long many ember folks doubt that orbit is still active
which is my fault
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:18
Dan Gebhardt
@dgeb
Jan 04 2016 02:18
but I think we will surprise them
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:18
yeah, out of the gates for the new year!
Dan Gebhardt
@dgeb
Jan 04 2016 02:18
:)
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:18
I think we can pull a synchronised release together pretty quickly now
Dan Gebhardt
@dgeb
Jan 04 2016 02:19
I agree
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:19
I think the only thing that’s conspicously absent from an ember user’s point of view is a friendlier query syntax
I think we need some kind of query builder api
Dan Gebhardt
@dgeb
Jan 04 2016 02:19
I agree
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:19
(that will spit out Oql)
Dan Gebhardt
@dgeb
Jan 04 2016 02:20
OQEs are awkward
we need a string parser
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:20
yeah, we also need to convert from the flat model structure to orbit’s json structure
(will be pretty confusing as it is)
Dan Gebhardt
@dgeb
Jan 04 2016 02:20
probably true
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:20
I think we can do a release without that though
Dan Gebhardt
@dgeb
Jan 04 2016 02:21
yeah we shouldn't wait much more
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:21
yeah, I think there’s enough there
we can put a roadmap together so people know it’s coming
Dan Gebhardt
@dgeb
Jan 04 2016 02:21
I'd like a release of ember-orbit by mid-January if possible
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:21
yeah, sounds good
I think secondary keys are the only thing missing really
(they’re probably not far off either, just haven’t looked at them)
Dan Gebhardt
@dgeb
Jan 04 2016 02:22
they shouldn't be hard
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:22
yeah
Dan Gebhardt
@dgeb
Jan 04 2016 02:23
tell me what would be most useful from me over the next few days
I'm splitting my time on orbit and ember engines
do you want me to focus on finishing rethink in orbit
?
and merging to master
or do you want a review of your ember-orbit PR first?
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:25
I don’t think there’s any blockers on ember-orbit
Probably best to get orbit.js all merged into master
Dan Gebhardt
@dgeb
Jan 04 2016 02:25
ok I will focus there then
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:25
One thing though, one big change I’ve made is how the the hasMany arrays work
Dan Gebhardt
@dgeb
Jan 04 2016 02:26
that makes sense b/c of livequeries
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:26
They now send all changes through Store and the Cache then updates the LiveQuery that’s backing the hasMany
yeah
it solves the data flow issues I was having before
it means there may be more of a delay while the UX updates
But this is only until optimistic UI lands
Dan Gebhardt
@dgeb
Jan 04 2016 02:27
ah I see
it is probably the right flow
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:27
yeah, I’m pretty confident about that
Dan Gebhardt
@dgeb
Jan 04 2016 02:28
yeah - it is clear that optimistic UI will be a best practice
to make it performant as well
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:28
yeah
and having a single data flow will simplify everything
Dan Gebhardt
@dgeb
Jan 04 2016 02:28
right
so do you have more to do on your ember-orbit branch?
or are you waiting for me to review?
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:29
I need to the secondary keys and store.unload
That’s about it though
Dan Gebhardt
@dgeb
Jan 04 2016 02:30
ok cool
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:30
There’s things we can clean up probably, consolidate some helper utils, but I don’t think there’s anything that will effect the interfaces so we can do them later.
There’s a new orbit.js PR orbitjs/orbit.js#237
For updating the Transactions
Dan Gebhardt
@dgeb
Jan 04 2016 02:33
ok great - I will start there
what's the story with orbitjs/orbit.js#229 ?
still TBD?
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:34
there was some rather spurious test failures with that one
Dan Gebhardt
@dgeb
Jan 04 2016 02:34
ok
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:34
I haven’t had a chance to dig in
Dan Gebhardt
@dgeb
Jan 04 2016 02:34
np - just checking if it's been superceded
Oliver Searle-Barnes
@opsb
Jan 04 2016 02:35
there’s a couple of other little things I picked up while integrating with ember-orbit, I’ll just make some PRs for those
Dan Gebhardt
@dgeb
Jan 04 2016 02:35
sg
Oliver Searle-Barnes
@opsb
Jan 04 2016 03:59
@dgeb what are your thoughts on handling store.didPatch(removeRecordOperation)? Should the record simply be evicted from the identity map or should it be destroyed as well? The scenario I’m wondering about is if the current route is /posts/post1 and post1 is destroyed, how do we handle it? Seems like the Route would need a hook.
BTW the only thing that’s stopping ember-orbit from going green is that the live query relatedRecords operator doesn’t handle relationships that are included when a record is created e.g.
store.addRecord({type: ‘planet’, id: ‘planet123’, relationships: {
  moons: { data: { 'moon:moon1': true } }
}});
Oliver Searle-Barnes
@opsb
Jan 04 2016 04:10
The last thing I think is store.query(oql), if we’re going to allow it to return any value how do we know when to use the identity map? Perhaps we should have different signatures?
store.queryForRecords(oql) // uses identity map, returns collection
store.queryForRecord(oql) // uses identity map, returns single record
store.query(oql) // doesn’t use identity map, returns arbitrary value
Emiliano Jankowski
@mustela
Jan 04 2016 11:29
hi there! has anyone used orbit with angular? I can't find a real integration example
Dan Gebhardt
@dgeb
Jan 04 2016 14:03
@opsb when a record is destroyed, I think we should evict it from the identity map but not force the object to be destroyed. Probably better to mark it with an attribute.
@mustela I see that you've already been on the issue in orbit re: angular (#214). Sorry to say that I don't know of further examples available atm.
Dan Gebhardt
@dgeb
Jan 04 2016 14:14
@opsb I suppose that we could allow findRecord / findRecords to take an oql expression
but that probably doesn't translate well to livequeries :/
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:02
@dgeb I’ve been giving a little thought to a fluent interface for querying. Just some ideas at the moment
Planet.filter({name: 'Jupiter'}).query(planets => {});
const liveQuery = Planet.filter({name: 'Jupiter'}).liveQuery();

const Planet = EO.Model.extend({
  name: attr(),

  scopes: {
    namedJupiter() {
      return scope.filter({name: 'Jupiter'});
    }
  }
});

Planet.namedJupiter.query(planets => {})
const liveQuery = Planet.namedJupiter().liveQuery();
We can achieve a similar api going via the store as well
store.type('planet').filter({name: 'Jupiter'}).query(planets => {});
const liveQuery = Planet.filter({name: 'Jupiter'}).liveQuery();

store.type('planet').namedJupiter.query(planets => {})
const liveQuery = Planet.namedJupiter().liveQuery();
Dan Gebhardt
@dgeb
Jan 04 2016 18:19
@opsb the store-specific version has potential
I've also been considering a store-specific OQE that looks up records
that could be used within OQL
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:20
How would that look?
Dan Gebhardt
@dgeb
Jan 04 2016 18:26
store.query({ oql: oqe('toRecord', oqe('get', [type, id])) })
I don't think that's quite it
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:26
ok, so toRecord is doing the identity map lookup?
Dan Gebhardt
@dgeb
Jan 04 2016 18:26
right
we would clearly need to make this easier on the eyes
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:28
I think we need to aim for a minimal api the querying, ember-data is currently
this.store.find('person', { name: "Peter" });
store.type('planet').filter({name: 'Jupiter'})
would be the equivalent
this still allows for the operator based querying that oql allows though
Dan Gebhardt
@dgeb
Jan 04 2016 18:29
well, we've already gone down the findRecord path https://github.com/orbitjs/orbit.js/blob/rethink/lib/orbit-common/store.js#L33
in orbit
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:29
true
Dan Gebhardt
@dgeb
Jan 04 2016 18:29
we could support the same in EO
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:30
I’m also considering relationships
planet.get(‘moons’).filter({name: ‘Callisto’})
planet.get(‘moons’).namedCallisto()
trying to find a holistic approach
Dan Gebhardt
@dgeb
Jan 04 2016 18:31
that is nice stuff, but I don't want to add too much sugar until we get the fundamentals right
there's a lot of sugar to unpack in namedCallisto for instance
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:32
sure, I don’t think we need that yet, just want to bear it in mind while we consider options now
Dan Gebhardt
@dgeb
Jan 04 2016 18:32
I think filter works well for relationships
k
it is good to think ahead
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:34
I’d like to be able to do traversals as well, e.g.
sun.get(‘planets’).relatedRecords(‘moons')
I think we can achieve all of this with a single query builder api
Dan Gebhardt
@dgeb
Jan 04 2016 18:34
yeah, that's nice
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:34
(obviously there’s a little work to do on the operators as well)
Dan Gebhardt
@dgeb
Jan 04 2016 18:35
we just need to break these all down to queries on the store
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:35

yeah, something like

store.type('planet').filter({name: 'Jupiter'}).query(planets => {});

seems like a good place to start

Dan Gebhardt
@dgeb
Jan 04 2016 18:35
so findRecord(oql) could desugar to store.query({ oql: oqe('toRecord', oql) })
for instance
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:36
right

so

store.type('planet').filter({name: 'Jupiter'}).query(planets => {});

would simply desugar to a call to store.query()

Dan Gebhardt
@dgeb
Jan 04 2016 18:37
right, and we'd also need to support liveQuery
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:37
that makes sense, a leaky abstraction
store.type('planet').filter({name: 'Jupiter'}).liveQuery();
Dan Gebhardt
@dgeb
Jan 04 2016 18:37
yeah
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:38
I think a query builder would be fairly easy to build now, we just start with a single OQE and keep wrapping around it
Dan Gebhardt
@dgeb
Jan 04 2016 18:38
my concern is that we're polluting the store namespace
but before we get too cute, I want to get store.query(oql, results => {}) working well
and store.liveQuery(oql)
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:39
You’d prefer something like?
store.query(Q.type('planet').filter({name: 'Jupiter'}))
yeah, I agree we should get them working first
Dan Gebhardt
@dgeb
Jan 04 2016 18:40
I think we should consider a way to parse OQL strings
but I'm not opposed to a query builder syntax either
working with both OQL strings and QB expressions seems like a good goal
haven't considered the QB options much yet tbh
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:42
I think a query builder syntax would be easier to work with. It also allows us to do the relationships and scopes consistently with the store querying style.
I did wonder if we could cheat a little and use a graphql parser
Dan Gebhardt
@dgeb
Jan 04 2016 18:43
hmmm
I do like the QB concept a lot
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:44
I think it’s a major step up from ember-data
Dan Gebhardt
@dgeb
Jan 04 2016 18:44
yeah
just concerned about the namespace pollution
on Store
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:44
It paves the way for things like 'through relationships’ (from rails)
which I think are sorely missing
Dan Gebhardt
@dgeb
Jan 04 2016 18:45
yeah
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:45
I think we could avoid attaching it to the store namespace
Dan Gebhardt
@dgeb
Jan 04 2016 18:45
I agree - just considering our options :)
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:46

But I’m not sure it’s desireable,

store.type(‘planet’).filter({})
sun.get(‘planets’).filter({})

is consistent

I suppose I’m thinking about the sales pitch of orbit a little
The superficial things are noticed first
Dan Gebhardt
@dgeb
Jan 04 2016 18:47
true
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:47
We’ve already done the hard work of making such an api possible
Dan Gebhardt
@dgeb
Jan 04 2016 18:47
maybe we expose store.records and store.record ?
store.records.type('planet').query()
store.records.type('planet').filter({atmosphere: true}).query()
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:48
I suppose I think of store as being records, but yeah something like that could work
store.records(‘planet’)
I don’t know if it makes sense to ever request all records, perhaps
Dan Gebhardt
@dgeb
Jan 04 2016 18:50
seems plausible to query multiple types
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:50
yeah, ok
Dan Gebhardt
@dgeb
Jan 04 2016 18:51
esp. if we're moving from /:type/:id to /:id with indices
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:51
yeah
Dan Gebhardt
@dgeb
Jan 04 2016 18:55
we could be explicit and have recordsByType as well as allRecords
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:56

It feels a little redundant,

store.recordsByType(‘planet')
store.allRecords()

vs

store.type(‘planet’)
store.all()
The store is a container of records
Dan Gebhardt
@dgeb
Jan 04 2016 18:57
ok, how about finding a specific record by type / id?
Oliver Searle-Barnes
@opsb
Jan 04 2016 18:57
store.type(‘planet’).get(‘pluto123’)
Dan Gebhardt
@dgeb
Jan 04 2016 19:00
ok, so we wouldn't support findRecord on the EO.Store?
I think the challenge is knowing when a single record is expected vs an array of records
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:02
I think we can seriously slim down the Store api
Dan Gebhardt
@dgeb
Jan 04 2016 19:02
ok
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:03
I’d like to remove any methods that are used internally by Model
e.g. replaceAttribute
the public api should be to always use a model instance
Dan Gebhardt
@dgeb
Jan 04 2016 19:03
ok, that's fine
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:05
yeah, I agree about knowing whether or not to treat the result as a record or not
Dan Gebhardt
@dgeb
Jan 04 2016 19:06
if we start with the toRecord and toRecords query expressions, we can do all this as plain OQL to start with query and liveQuery
and then graduate to all this nice QB syntax
I think it's got huge potential
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:06
yeah, that does seem like a good plan
yeah, definitely
Dan Gebhardt
@dgeb
Jan 04 2016 19:07
:+1:
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:07
ok, definitely something we can do for mid jan anyway
are you still planning on looking at doing the hybrid evaluator?
Dan Gebhardt
@dgeb
Jan 04 2016 19:08
yes - later this week - maybe Wednesday - unless you want to tackle it sooner
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:08
I won’t have time before then no
Dan Gebhardt
@dgeb
Jan 04 2016 19:08
ok
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:09
Going to start work again on wednesday I think(for Zapnito), still taking it pretty easy but I’ll try and get that ember-orbit PR tied up
Dan Gebhardt
@dgeb
Jan 04 2016 19:09
nice - thanks a bunch
hope you're feeling better
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:09
yeah, nearly better for sure
Dan Gebhardt
@dgeb
Jan 04 2016 19:09
phew :)
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:10
did you see my comment about the relatedRecords operator and store.addRecord() ?
i.e. when you add a record with related records the relatedRecords operator doesn’t notice
Dan Gebhardt
@dgeb
Jan 04 2016 19:14
so this is an issue for live queries?
was your comment here or on an issue?
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:18
Sorry, yeah, the comments are a bit scattered on orbitjs/ember-orbit#85
It’s currently the only failing test on that PR
There is an issue for it though orbitjs/orbit.js#236
Dan Gebhardt
@dgeb
Jan 04 2016 19:20
ah thanks
so shouldn't we be getting a didPatch for the inverse op?
which should be emitted from the cache
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:22
I thought we’d decided to do that internally in the Cache
I was a bit fuzzy on that point though
Dan Gebhardt
@dgeb
Jan 04 2016 19:23
I think we want didPatch to reflect every change to the Cache
whether calculated or applied directly
otherwise we would need to re-calculate everywhere
in order to watch for changes like this
which is pretty inefficient
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:24
I agree
ah, sorry, I misread your comment
Dan Gebhardt
@dgeb
Jan 04 2016 19:26
np :)
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:26
it does emit the reverse op, but the relatedRecords operator only listens for one side of the relationship (the non-inverse because the inverse doesn’t necessarily happen if it’s not specified in the schema)
Dan Gebhardt
@dgeb
Jan 04 2016 19:28
do we have a failing test case in orbit?
I'm a bit confused about this scenario
Oliver Searle-Barnes
@opsb
Jan 04 2016 19:28
no, I’ll add one in
Dan Gebhardt
@dgeb
Jan 04 2016 19:28
thanks
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:05
@dgeb I’ve added a failing tests for the relatedRecords issue orbitjs/orbit.js#240
Dan Gebhardt
@dgeb
Jan 04 2016 22:12
@opsb thanks - will poke around with that
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:14
@dgeb mindful of the fact that we’re trying to avoid a state machine, I’m not sure about adding a flag to records to indicate that they’ve been deleted...
events seem to be the only other option though
liveQueries will be automatically updated anyway
I think the only scenario that needs handling is when the deleted model is the current model object for a Route.
Dan Gebhardt
@dgeb
Jan 04 2016 22:20
I suppose someone could be holding onto a model for any number of reasons
although it is almost always a mistake
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:20
It could be in a Service I suppose
Dan Gebhardt
@dgeb
Jan 04 2016 22:21
the purpose here is to indicate that the model object is no longer representative of a record in a store
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:21
yeah
I’m still wondering if model object events aren’t such a bad idea, i.e.
record.on(‘destroy’, () => {})
that way you only need a reference to hook into the event handling
i.e. the consumer can decide whether or not it’s interested
Dan Gebhardt
@dgeb
Jan 04 2016 22:24
that is fine I suppose
I would still like a state flag like recordDestroyed
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:24
yeah, it gives me pause for thought
I’m not necessarily against it
but so far we’ve avoided keeping state in the records
Dan Gebhardt
@dgeb
Jan 04 2016 22:25
it is the one scenario in which we need state in the record - to say it is no longer "linked"
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:25
loading state is the other thing though, people are definitely going to ask for that
how does ember mark a destroyed object?
Dan Gebhardt
@dgeb
Jan 04 2016 22:26
I don't think we need any other state
loading, saving, etc
those have no equivalents in orbit
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:26
what’s our answer to the loading question?
use a promise I guess
i.e. store.query and store.liveQuery return a promise that resolves when the data is loaded
Dan Gebhardt
@dgeb
Jan 04 2016 22:28
you'll need to define "loading"
I mean records either exist in the store or they don't
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:29
I’m using it to mean “loading from a remote source"
Dan Gebhardt
@dgeb
Jan 04 2016 22:29
you can load more into the store
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:29
or slow source really
Dan Gebhardt
@dgeb
Jan 04 2016 22:30
so you're requesting them really
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:30
yeah
Dan Gebhardt
@dgeb
Jan 04 2016 22:30
and then they appear or they don't :)
they aren't in a "loading" state
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:30
no, it’s just the call to store.query that blocks
Dan Gebhardt
@dgeb
Jan 04 2016 22:31
yeah, so you can wait on that promise
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:31
ok, yeah, that does seem fine
Dan Gebhardt
@dgeb
Jan 04 2016 22:31
but the records themselves are never in a loading state
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:31
we can do the same with liveQueries
Dan Gebhardt
@dgeb
Jan 04 2016 22:31
yeah
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:31
yeah
ok
Dan Gebhardt
@dgeb
Jan 04 2016 22:32
so when I say I want a "deleted" state for Model instances
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:32
so do we really need the deleted flag on records? (would be nice to avoid state completely if we can)
Dan Gebhardt
@dgeb
Jan 04 2016 22:32
I mean that we want a "disconnected" flag really
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:32
hmm
Dan Gebhardt
@dgeb
Jan 04 2016 22:32
i.e. the Model instance no longer has a corresponding record
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:32
yeah, I like that
Dan Gebhardt
@dgeb
Jan 04 2016 22:32
ok
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:33
could it be reconnected? (unlikely, just considering the full lifecycle)
Dan Gebhardt
@dgeb
Jan 04 2016 22:33
I don't think so
it should be banished from the identity map
never to return
kind of sad - poor thing :(
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:34
seems a bit harsh ;)
Dan Gebhardt
@dgeb
Jan 04 2016 22:34
lol
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:34
brb
Dan Gebhardt
@dgeb
Jan 04 2016 22:34
k
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:48
ok, seeing as a model doesn’t actually contain any state, I guess we’ll need to raise an error if it attempts to access the store in any way
e.g. if get attribute is called
Dan Gebhardt
@dgeb
Jan 04 2016 22:49
yes
in fact, we could just set this.store = null
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:49
so we set store to null?
Dan Gebhardt
@dgeb
Jan 04 2016 22:49
lol
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:49
:)
Dan Gebhardt
@dgeb
Jan 04 2016 22:49
sounds like "disconnected" to me :)
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:49
yeah, I like that approach
Dan Gebhardt
@dgeb
Jan 04 2016 22:50
same
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:50
should we notify getters that have cached values?
or leave them as are
I suppose leaving them is less aggressive
Dan Gebhardt
@dgeb
Jan 04 2016 22:51
I think we can leave them
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:52
ok, I’ll put that in place next then
keys is the other thing
what’s the expected api for those? (I’ve never used them)
Dan Gebhardt
@dgeb
Jan 04 2016 22:52
do you think we need a model level disconnect event?
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:53
if you’re in the middle of editing the model in the UX you’d want to be notified I think
Dan Gebhardt
@dgeb
Jan 04 2016 22:53
:+1:
and we can have a disconnected alias
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:54
yeah
I’m not sure about what should emit the event though
it could be the store
depends if we want to add other model hooks I think
e.g. model.on(‘attributeUpdated’, () => {})
Dan Gebhardt
@dgeb
Jan 04 2016 22:55
let's leave it off for now and figure it out through examples
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:55
ok
so what about them keys?
is it just a case of exposing getters for them?
Dan Gebhardt
@dgeb
Jan 04 2016 22:56
I think so yes
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:56
it’s also a bit fiddly with primaryId at the moment
is that necessary or can we just use record.id?
Dan Gebhardt
@dgeb
Jan 04 2016 22:57
we can just use record.id
all other keys are secondary
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:57
ok, I’ll clean out primaryId then
Dan Gebhardt
@dgeb
Jan 04 2016 22:57
thanks
so let's leave off the events for models entirely for now (unless you have a really strong immediate need)
keep it as simple as possible initially
Oliver Searle-Barnes
@opsb
Jan 04 2016 22:58
no, I don’t have any strong vision for them at the moment
happy to leave them off for now
Dan Gebhardt
@dgeb
Jan 04 2016 22:58
:+1:
ok got to run for a bit - bbs