Fork me on GitHub
#om
<
2016-01-02
>
hkjels13:01:23

@dnolen: is the om-next-demo suppose to be fully functional?

dnolen13:01:38

@hkjels: not necessarily

dnolen13:01:49

been too busy to keep it up-to-date

tony.kay14:01:58

@deplect: Your process-roots sample is not a bug. You can only mark joins for promotions, not selector expressions of a join…you’d have to move the marking out to the :route join itself

tony.kay14:01:22

therefore, your other marked root (which is done correctly) is not a subroot…it is the only detectable root.

tony.kay14:01:38

I suppose we could add a warning for this, or more docs

tony.kay14:01:06

@dnolen: I noted this in om-550, but I don’t want it to get lost in the shuffle..it is a trivial fix I’m sure you’d rather just make. Line 1351 of current master is missing get-query (`(or query (:root @(:state reconciler)))`).

tony.kay14:01:32

scratch that….`tree->db` does it…it was just confusing to have two types mixed in an or

anmonteiro15:01:57

if anything is not OK, please say so

anmonteiro15:01:11

@dnolen: btw, will you accept a patch updating the project.clj file? I know you haven't been using it in a while, but I don't use Cursive and I'm having to manually change it everytime I want to run the tests and such

dnolen15:01:36

@anmonteiro: what needs changing?

anmonteiro15:01:30

update lein-cljsbuild to 1.1.2 (`deps.cljs` is breaking examples compilation, see: https://github.com/emezeske/lein-cljsbuild/commit/b5d1c7d882631f62746ea668cdfbd496d1f2b973) add "src/test" to :source-paths

anmonteiro15:01:44

this is what I remember from the top of my head

dnolen15:01:26

@anmonteiro: Lein :source-paths?

dnolen15:01:30

(i.e. not cljsbuild)

anmonteiro15:01:43

@dnolen: Lein :source-paths, yes

anmonteiro15:01:40

cool, thanks

anmonteiro15:01:20

@dnolen: also, are there any pending issues you need help with or would like to delegate, or are there only things you wanna sort out yourself?

tony.kay15:01:31

@dnolen: I’m fixing 550 right now

dnolen15:01:53

@anmonteiro: this might not be so hard ^

dnolen15:01:14

OM-523 is meaty

dnolen15:01:22

lots of changes - but mostly boring

anmonteiro15:01:29

I was also a bit puzzled, I was seeing that 534 was closed 😛

dnolen15:01:31

i.e. it should not be conceptually challenging

dnolen15:01:55

pretty much the only tricky bit would be tracking recursion depth in db->tree

dnolen15:01:03

but I don’t think even that will be all that hard

anmonteiro15:01:45

@dnolen: I was indeed looking over 523 yesterday or today morning

anmonteiro15:01:31

@dnolen: but I don't think I wanna mess with that one

anmonteiro15:01:35

I might miss something

tony.kay15:01:52

tracking recursion depth should be easier due to the graph loop code that is already there

anmonteiro15:01:29

@dnolen: gonna check 543 first

anmonteiro15:01:13

and dig into 523 afterwards if I've got time

tony.kay16:01:40

@dnolen: You might see an easier way to fix om-550, but I made a stab at it that works. PR sent.

tony.kay16:01:41

I could take a stab at 523

krchia16:01:02

does om/update! not apply the change to app-state?

krchia16:01:05

it seems to reset back to the default value without refreshing the webpage

anmonteiro17:01:16

@krchia: your are referring to Om Now, right?

anmonteiro17:01:36

it is supposed to work, a minimal example of your problem should be able to help us identify your problem

tony.kay17:01:40

@dnolen: on recursion limit: should we still stop on detection of graph loops, or continue to the specified depth?

dnolen17:01:53

@tony.kay: continue to specified depth

dnolen17:01:58

same as Datomic

tony.kay17:01:04

thx…didn’t know which it did

tony.kay17:01:29

that makes it trickier simple_smile

tony.kay17:01:23

actually, I take that back…not that hard

deplect17:01:46

@tony.kay: yes I understand now. Thanks for the clarification.

hugod18:01:41

I have an om.next app with a react native ListView, which has a button to delete each element from the list. The button uses om/transact! to remove the element, but the list view doesn't seem to get updated (it still has an element in the list for the deleted element). Should I be manually forcing the list view to update?

adammiller18:01:22

are you specifying the key(s) to be re-read in the transact call?

hugod18:01:12

no - I didn't realise you could

hugod18:01:17

that seems to work nicely. Thanks @adammiller

artesonraju19:01:36

Hi there, messing with idents and joins queries, like [:id {[:current_user _] [:name]}], I found that it isn't managed correctly by the parser. When using the parser recursively (https://gist.github.com/Artesonraju/e93224619c04ccbd7f1b), I get [:current-user ] keys instead of :currentuser in the result. On the other hand om/db->tree seems to manage it correctly, but the components aren't updated when the key (:current_user in the example) is updated (if I did it correctly...). Is that a bug or should those kinds of expressions be avoided ?

dnolen19:01:43

@artesonraju: the parser doesn’t really handle anything

dnolen19:01:45

that’s up to you

artesonraju19:01:50

@dnolen ok, I see I have to manage myself the references in the query. Thanks

anmonteiro19:01:37

@dnolen: given the following union query:

anmonteiro19:01:45

{:union {:foo [:baz]
         :bar [:qux]}}

anmonteiro19:01:51

is it supposed to be possible to recursively parse the query?

anmonteiro19:01:55

e.g.: in :union's read method, call (parser env query)

dnolen19:01:35

@anmonteiro: not automatically at the moment, you have to sort that out

anmonteiro19:01:33

ok.. I'm trying to construct an example for OM-543

anmonteiro19:01:48

thought I needed this

anmonteiro21:01:40

@dnolen: I managed to create an example of recursion within a union without any Om changes

anmonteiro21:01:22

but it feels a little hacky, so I was wondering if you could look over it before actually considering merging it into the repo

tony.kay21:01:11

@dnolen: om-523 is done. PR in place. Fixed AST stuff for joins, db->tree, and verified tree->db. Anything else I’m forgetting?

dnolen21:01:27

@tony.kay: sweet will probably take a look on tomorrow or Monday - seems good off the top of my head

dnolen21:01:00

@anmonteiro: perhaps add what you’re thinking to the issue to so we can track though process some place more visible?

anmonteiro21:01:29

@dnolen: will do, after some cleanup