Clojurians Log v2

@devth how does the component A query look like?

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

i do make the current db available in the request's context

this is pre-mutation though, so it will be out of date by the time the read gets called

(this is the case where the request contains both a mutation and a read)

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

ah

makes sense. thanks.

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 😃