This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-17
Channels
- # admin-announcements (104)
- # adventofcode (3)
- # aws (1)
- # boot (651)
- # cljs-dev (21)
- # cljsrn (12)
- # clojure (81)
- # clojure-china (1)
- # clojure-germany (1)
- # clojure-miami (2)
- # clojure-nl (8)
- # clojure-russia (19)
- # clojurescript (208)
- # core-typed (1)
- # cursive (19)
- # datavis (55)
- # datomic (57)
- # events (1)
- # hoplon (102)
- # ldnclj (12)
- # leiningen (8)
- # off-topic (11)
- # om (127)
- # onyx (21)
- # parinfer (2)
- # portland-or (3)
- # proton (2)
- # re-frame (2)
- # reagent (6)
@anmonteiro: it seems the generated lein template with option +next doesn't include deps for either om or om.next in project.clj
are there any good ressources in how to integrate om with a existing REST API? (or in general stuff that doesn't use fragments?)
Hi @joshfrench, @dnolen just to confirm that it works fine with master. I think my problem came from the lein install of Om. I have cleaned manually om/target
and resources/public/devcards/out
. Sorry for the false alarm.
@jethroksy: thx, fixed
@dvcrn: though I'm only integrating 1 or 2 routes, I have a sample project integrating with a REST API here: https://github.com/anmonteiro/deathrow
it has Om & Om Next code, providing the same functionality
so it's good for comparing
hi guys, what is the proper request to get todo item by-id like the one I highlighted in the source code https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/clj/todomvc/server.clj#L99-L103
How would I incorporate novelty received from a REST endpoint into the application state? I am passing the novel data to the Om.Next callback once I got the server response. How do I get the data in correct shape? I have a root query with accounts/list
and subqueries for attributes of accounts
. From the REST AJAX call, I would like to update a single attribute. Accounts have an Ident on db/id
, which would also be in the scope of building the novelty structure.
I should also mention, that the AJAX call simply gets triggered via om/transact
-> parser/send
if that is not obvious
one step further:
(callback {:accounts/by-id {(get-in account [:params :db/id])
{:name "FOOOOO"}}})
@nblumoe: probably need to override :merge-tree
in the reconciler to suit your behavior
But am I on the right track with this? Swapping this into the application state myself should be avoided, right?
I think the behavior should be defined in :merge-tree
the default approach is quite naïve
so feel free to adapt it to your use case
is there some documentation you could refer to? Or should I try to make sense from the code around https://github.com/omcljs/om/blob/b61fa371e5ec81f54addcbd7e6e0c4655bfbebc0/src/main/om/next.cljs#L1329 ?
@nblumoe: I think there's no docs on this yet
the default merge-tree
is here though: https://github.com/omcljs/om/blob/b61fa371e5ec81f54addcbd7e6e0c4655bfbebc0/src/main/om/next.cljs#L1527-L1531
it's what's called on merge-novelty
right at the end
Would you mind giving a short description of merge
merge-ident
and merge-tree
? What is supposed to do what?
not sure about merge
and merge-idents
, sorry
@nblumoe merge just runs merge-tree, migrate and merge-idents (lower level)
merge-tree is for updating the state, migrate is for updating tempids and merge-idents for adding...idents
the source isn't too hard to understand for the default implementations
using datascript, you have to implement merge-tree and migrate at least
depends on your store but they're designed to be pluggable
@anmonteiro: @danielstockton thanks, managed to get it done! :thumbsup:
if i'm persisting an entity remotely: (create! {:db/id temp-id})
sometimes i'd like to also re-read the new entity, in case the remote has changed or added some attribute: (:read {:db/id temp-id})
. it seems impossible to do this in one shot, since there's no way to resolve the temp-id from :read
against the result of create!
within the remote parser.
right now my workaround is to pass a static identifier: [(create! {:client-id (str temp-id)}) (:read {:client-id (str temp-id)})]
. but that feels redundant and also requires that those transactions run in the same sequence on the remote(s), which i'm not sure is a safe assumption.
am i overlooking a better way to do this?
@joshfrench: Hmm, if this doesn't already work perhaps we can make Om read keys aware of tempid migration somehow, so you could ask to re-read the tempid and Om would internally perform tempid migration and re-read the real thing.
@jannis seems like you’d run into problems if you had multiple db transactions — how would you know which result to resolve against?
@joshfrench: True. Although... if they are part of the same query (multiple transactions + reads) it would know, even if only one of the transaction results in the combined result has a tempid mapping.
If the transactions are sent as separate queries... yeah, I can see how that would be a problem.
i’m imagining a scenario like [(transact-A! {...}) (transact-B! {...}) (:read temp-id)]
where you’d have two possible results/tempid maps
i suppose you could just try each result until you find one that can resolve your ID
but it seems like there’s still a timing issue — even if i knew which txn to resolve against, i still need to run it and have the results prior to executing :read
so i know what ID i’m actually reading
@joshfrench: I haven't looked at the code in a while but my guess would be that Om already consolidates tempid maps into one before the migration. But I'm not sure.
Regarding the timing issue... perhaps both client and server-side parser could translate tempid reads on the fly while processing the query? Not sure that's feasible. I'm sure David will have a more informed opinion on all this.
is it safe to assume that within a vector of transactions, the sequence will be preserved on the remote(s)?
if order were fixed, i could use a request-level map to let earlier transactions add ID translations for later transactions to refer to
thanks!
Any reasons why consecutive resets on an atom state might be ignored by om component listeners?
stick with the tutorials and modifying them - then ask questions when things don’t match your expectations
I think what I might be missing is that my event handler is blocking om from rendering component upon atom state change.
@joshfrench: One note on ordering: If you use process-roots, it is possible for the reads to be re-ordered (due to root promotion merging)...but the order of the mutations is preserved.
({:auth [...more stuff]} {:user/email test, :user/password s}) becomes {:auth [...more stuff]}
that exact kind of test case works for me in general. Might need a bit more specific
oh ok, well when I store clojure data structure in javascript objects I thought there was a serialization going on in there.
@smeister: I'm not able to reproduce your output via a test, using your exact reported query, query root, and process-roots.
I thought I saw that when I added an entity from datascript to a map in om component's state atom, and then read it during another event it was no longer a datascript entity.
dnolen: Would you expect arbitrary object stored in component state across events and the reaccessed in another event to be consistent(still and arbitrary object)?
After testing in the repl with figwheel it seems okay, but this not across events in browser. However it does seem to be working across events.
@smeister: OK, Able to reproduce your issue now. A bit puzzled as to why the original test was passing.
I'm thinking the comments from @dnolen about leveraging the AST might be in order here...might simplify this algorithm and fix this problem at the same time.
So is this a hard rule "state should only consist of associative data structures like maps and vectors" or can any object be used for state?
@vipaca: what are you thinking? All that makes sense is associative structures (i.e. it has to have meaning and be able to be queried)
Can an arbitrary object that stores state be used e.g. records, structs, pojo that has accessor for example?
but to answer your question, state is managed via atom and the only things you can hold in atom is one of clojures immutable data structures
we are all n00b’s at something! are we talking about state with om.next or are you just asking about atoms in general?
I’d say if you are comfortable with clojure/clojurescript but new to react based frameworks that you may want to check out reagent. A little easier to jump into and grasp than Om/Om.next IMO. Jumping straight into Om without much cljs experience is tough.
oh that's a good suggestion, i should check that out
i was having issues just using om
trying to learn too many things at once
also a library called re-frame you can use with reagent…I think their readme on the github project is very well done and enlightening no matter which route you end up going: https://github.com/Day8/re-frame
@vipaca you can store arbitrary values but only maps and vectors can be understood by the query bits. arbitrary values will not be traversed for links for example.
btw, I reimplemented my approach to allow return after each state change and then trigger a subsequent event trigger and it now it renders each state changes upon event completion.
I was under the misunderstanding that I simply needed to update the atom and then render would occur asynchronously in om component.
adammiller: thanks for the reagent advice its the second time today Ive seen the reference.
@dnolen: This may be one you don't care about, because it relates to side-band pre-loading of data; however, here is a problem that we're having to work around:
The merge!
functionality of Om on incoming joins keyed by idents uses the indexer to find the queries in order to normalize the value. That makes sense, since the ident keys are for data that associates with disparate components.
However, if those components are not yet on screen (in the current UI query) then normalization fails because they are not in the indexer.
Might be nice to at least have a way to pass a list of component classes so that you could help it out...like we can now pass a query to help with normalization of tree responses.
@tony.kay: will need to think about it, but yes I understand the problem and I agree we need something