This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-02
Channels
- # admin-announcements (1)
- # alda (1)
- # aws (4)
- # boot (276)
- # cljs-dev (3)
- # cljsjs (1)
- # cljsrn (3)
- # clojars (22)
- # clojure (174)
- # clojure-austin (1)
- # clojure-italy (2)
- # clojure-russia (20)
- # clojurecup (1)
- # clojurescript (233)
- # cursive (4)
- # datavis (97)
- # datomic (122)
- # hoplon (80)
- # ldnclj (8)
- # leiningen (6)
- # om (82)
- # reagent (10)
- # spacemacs (8)
- # specter (5)
@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
therefore, your other marked root (which is done correctly) is not a subroot…it is the only detectable root.
@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)))`).
scratch that….`tree->db` does it…it was just confusing to have two types mixed in an or
@dnolen: just added update-query!
's docs to the wiki. diff: https://github.com/omcljs/om/wiki/Documentation-(om.next)/_compare/0890322afd107d69d6ada94ccc3ee198b40af6ec...c38f65d2848d2edf387b76540186b4ce41311166
@anmonteiro: thanks
if anything is not OK, please say so
@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
@anmonteiro: what needs changing?
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
this is what I remember from the top of my head
@anmonteiro: Lein :source-paths
?
@dnolen: Lein :source-paths
, yes
cool, thanks
@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?
@anmonteiro: @tony.kay was looking at 550
@anmonteiro: this might not be so hard ^
I was also a bit puzzled, I was seeing that 534 was closed 😛
@dnolen: I was indeed looking over 523 yesterday or today morning
@dnolen: but I don't think I wanna mess with that one
I might miss something
tracking recursion depth should be easier due to the graph loop code that is already there
@dnolen: gonna check 543 first
and dig into 523 afterwards if I've got time
@dnolen: You might see an easier way to fix om-550, but I made a stab at it that works. PR sent.
@tony.kay: go ahead!
@krchia: your are referring to Om Now, right?
it is supposed to work, a minimal example of your problem should be able to help us identify your problem
@dnolen: on recursion limit: should we still stop on detection of graph loops, or continue to the specified depth?
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?
are you specifying the key(s) to be re-read in the transact call?
that seems to work nicely. Thanks @adammiller
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 ?
@artesonraju: the parser doesn’t really handle anything
@dnolen ok, I see I have to manage myself the references in the query. Thanks
@dnolen: given the following union query:
{:union {:foo [:baz]
:bar [:qux]}}
is it supposed to be possible to recursively parse the query?
e.g.: in :union
's read
method, call (parser env query)
@anmonteiro: not automatically at the moment, you have to sort that out
ok.. I'm trying to construct an example for OM-543
thought I needed this
@dnolen: I managed to create an example of recursion within a union without any Om changes
but it feels a little hacky, so I was wondering if you could look over it before actually considering merging it into the repo
@dnolen: om-523 is done. PR in place. Fixed AST stuff for joins, db->tree
, and verified tree->db
. Anything else I’m forgetting?
@tony.kay: sweet will probably take a look on tomorrow or Monday - seems good off the top of my head
@anmonteiro: perhaps add what you’re thinking to the issue to so we can track though process some place more visible?
@dnolen: will do, after some cleanup