This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-02
Channels
- # aws-lambda (1)
- # beginners (46)
- # boot (190)
- # cider (12)
- # clara (6)
- # cljs-dev (9)
- # cljsjs (8)
- # clojure (152)
- # clojure-austin (3)
- # clojure-berlin (3)
- # clojure-finland (2)
- # clojure-france (5)
- # clojure-italy (3)
- # clojure-russia (92)
- # clojure-serbia (4)
- # clojure-spec (7)
- # clojure-uk (190)
- # clojurescript (115)
- # cursive (20)
- # datomic (20)
- # dirac (4)
- # emacs (9)
- # gsoc (5)
- # hoplon (1)
- # jobs (1)
- # klipse (4)
- # lein-figwheel (1)
- # leiningen (6)
- # lumo (2)
- # mount (18)
- # off-topic (57)
- # om (68)
- # om-next (14)
- # onyx (33)
- # perun (32)
- # portland-or (4)
- # re-frame (21)
- # reagent (85)
- # ring (6)
- # ring-swagger (23)
- # schema (1)
- # uncomplicate (1)
- # untangled (13)
- # vim (7)
I have a component that reads the stuff from :user and now I'd like to also add all the items from another part of the atom data called :nf ... how would I do that? My original query is like '[:content :link :tag] and now I wish to do something like from the Thinking With Links! page where I Have [:nf _] so I can grab some attributes from the :nf vector, but it's really unclear how I can query out-of-scope things. I provide a ident? or a key in the map? puzzled
I just resorted to picking stuff out of the atom myself...
@raspasov it looks like [{[:ui/for-a-table _] [#:many.interface.app{:a [:db/id :a/name #:organization{:type [:db/doc]}]}]}]
. turns out since that component is on another route in my app i didn't need to do anything to refresh. the reason it wasn't appearing to refresh was because when i ran a remote mutation and then a read, the read was using a database value before the mutation was applied!
@devth reads in the same transaction as a mutation need to have access to the new DB value, but you probably want to make the current DB value part of a request’s context (depending on what you’re using as a webserver this might be represented in different ways). I include an atom that contains the current DB value for the request and update it on mutations. I’d avoid grabbing a new DB value in each serverside read method, as you could read inconsistent data over the course of a request.
om.next will always call mutation methods before reads
this is pre-mutation though, so it will be out of date by the time the read gets called
yup– so you might include a :db-ref keyval that is an atom in your context and reset!
it to the :db-after in each mutation method
There are a lot of little things like this that aren’t spelled out in any documentation or tutorials.
With devcards & klipse I think om.next documentation can grow very quickly. There are still some big holes in what-does-what but i'm very optimistic 😃