This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-24
Channels
- # aatree (27)
- # admin-announcements (5)
- # all-the-channels (2)
- # aws (27)
- # beginners (38)
- # boot (48)
- # braid-chat (18)
- # cider (6)
- # cljs-dev (9)
- # cljsrn (8)
- # clojars (4)
- # clojure (73)
- # clojure-dev (2)
- # clojure-russia (2)
- # clojure-sg (1)
- # clojurescript (96)
- # code-reviews (3)
- # community-development (4)
- # conf-proposals (17)
- # core-matrix (2)
- # cursive (2)
- # datascript (4)
- # datomic (4)
- # dirac (1)
- # funcool (5)
- # hoplon (2)
- # mount (66)
- # off-topic (35)
- # om (211)
- # parinfer (2)
- # pedestal (2)
- # proton (1)
- # reagent (2)
nothing reference-cursor-ish yet in om.next, correct?
@cascada-io: no cursors at all, queries instead
I noticed in the parser comments that there is a :union
type. shouldn't (om/query->ast '{:foo [:x] :bar [:y]})
return { :type :root, :children [{ :type :union ... }]}
?
@jlongster: for a simple app, you could always use Datomic in memory db, and listen to the transaction log and write transactions to a log file. Main drawback is your entire dataset has to fit in memory, but if you just have a small-ish dataset and want Datomic's querying abilities, it might be a viable option.
@mdhaney: I could, don't really want to handle that transaction logging & rebuilding the db though. also my data fits well with the relational model & it's kind of queries. most importantly, I feel like it's super cool to show how easy it is to use anything with om next
@jlongster: fair enough. And yes, showing that flexibility is super cool. I'm working on what sounds like something similar for a prototype at work. Difference is, the backend is all microservices instead of a db.
nice. I may try datomic at some point, but I don't like that people think om next only integrates with it
jlongster: question was whether a new (non-cursor obv) pattern/feature has surfaced to solve the problem reference cursors solved in om.now
(namely: deeply nested component has a data dependency not passed to it by its parent)
@cascada-io: still learning om next myself, not far enough in to give a good answer, but generally things work better
@cascada-io: I think a big part of the design of om-next was based on solving that problem. Look at the Thinking in Links tutorial on the Om wiki.
@mdhaney: yes, i've been looking at that and playing w/ it, but not seeing any way to avoid passing props all the way down (and no component in that example using data that wasn't directly passed to it)
(not entirely accurate... :current-user
does so. not quite comparable to reference cursors though)
contrived example: https://www.refheap.com/113991
@cascada-io: There is no way to avoid passing props down. That's how it works. Components define queries and they expect to receive the corresponding data. If you don't pass that down, you're breaking their input contract. There are at least two ways to reference "top-level data" in Om Next: One is to use links, specifically [:top-level-data _]
(note the underscore), the other is to use :shared
/ :shared-fn
: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1711 - I believe :shared-fn
is run on every render.
I made a demo of localisation with Om Next and DataScript https://github.com/bnomis/om-next-datascript-localisation-demo
@simonb: I can see that multilingual sites should become the standard now. I think if you have some kind of a translation bar ( for translator ) so he or she can translate the app by click to translate mode then he or she can translate each code block. It would be very interactive and awesome way to translate. Just my opinion
@nxqd: Yep. That's the idea. The app is the authoring tool - used to play/view the content as well as author it.
Hi. Can't get it working properly recursive component and a wrapping one around it. Using db-tree
. Did ~2h debugging and digging into src.
Is that true about denormalize*
that if data
is a vector, it should be vector of idents, not, say, maps (i.e. actual data)? This line makes me think so https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1244
Hmm, not sure if you can use the standard
db->tree
if you're working with recursive queriesinetresting @iwankaramazow
well, the thing I'm trying to get from Om Next is one it's intended to be best at — handling all these queries (i.e. co-located ones, recursive etc, all together) right
check out https://awkay.github.io/om-tutorial/#!/om_tutorial.E_State_Reads_and_Parsing Excellent example if you want to parse recursive queries
Great, thanks @iwankaramazow !
@andrewboltachev: this is an excellente example too http://anmonteiro.com/2016/01/exploration-patterns-om-next-part-1/
https://gist.github.com/anmonteiro/2b282aa35380558a8b1d#file-composite-cljs That's the code
@andrewboltachev: you can also use path optimization in recursive queries, and db->tree
will work then
@anmonteiro: so, either would it miss that line (and case (vector? data)
), or idents will appear?
unrelated
this is an extra thing, which is only triggered after mutations
see https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/core.cljs#L331-L333 for an example
So at the moment what can't db->tree
handle? Only query params?
ah, query-root
'cause I did (om/db->tree query @state @state)
@andrewboltachev: (om/db->tree query @state @state)
won't work as you expect
that will just denormalize the whole state
and you'll get repeated keys in your return from read
like, one more level of nesting
I just were trying to read keys from the root of the state
Though as I learnd, [[:foo :bar] _]
is in charge of it
@anmonteiro: if you have a query like [{:foo [:bar :baz { :other {:subproperty :anotherproperty}} }]
, you need to call your parser recursively. Am I correct? This is not something om/db->tree
can deal with?
@iwankaramazow: not sure that query is valid
@iwankaramazow: what that { :other {:subproperty :anotherproperty}}
nested maps do?
The above query is:
({:results [:place :agegroup :time :year {:person [:name :firstname]}]} {:year 2016})
I'm starting to understand why GraphQL's spec is so huge: https://facebook.github.io/graphql/
well, let's check what I have: [{:categories [{:categories/list [:db/id]}]}]
what does your data look like?
@iwankaramazow: that second one is indeed valid
does db->tree
not handle it?
{:categories/list [
{:db/id 1
:category/name "foo"
:category/_parent [
{:db/id 2
:category/name "bar"
}
{:db/id 3
:category/name "buz"
}]
}
}
I think there's an issue for that; I'm happy to look at a minimal case
@anmonteiro: console.log gives me Uncaught Error: Doesn't support name: {:person [:naam :voornaam]}
@bbss: I think that different languages have differences
oh yea
forget the translation part
Uncaught Error: Doesn't support name: {:person [:name :firstname]}
😛
ah, Dutch that is 😄
my parser could be wrong
I'll check
I were thinking @bbss you treat that as sth funny. Sorry 😐
@iwankaramazow: probably a bug, there's https://github.com/omcljs/om/issues/558 which also reports the same
so if you share a minimal case I'm happy to look at it and discuss a patch with David
I am a bit confused by some data in the default database format,
from:
(om.next/db->tree query some-data app-state-db)
Given a query expression, some data in the default database format, some application state data in the default database format, denormalize it. This will replace all ident link nodes with their actual data recursively. This is useful in parse in order to avoid manually joining in nested relationships.
@anmonteiro: I'll put a minimal case together
@iwankaramazow: thanks!
@bbss: a sec
in a snippet just above, (:tree st)
is "some data"
the way I remember it the app-state contains something like: [[:results/by-id 1] [:results/by-id 2]]
state is just your state deref'ed
and query is the query 😛
well, some-data is piece of state query is applicable on
i.e. not the whole state
@andrewboltachev: you mean " {:value (om/db->tree query (get st k) st)}))" ?
I've seen exactly that somewhere...
@bbss: that's it
well, yep that seems to be just quick solution
@iwankaramazow: and what's your data like?
{:results {:place 1
:agegroup 2
:time 3
:year 2016
:person {:name 5 :firstname 6}
}
}
what's missing?
In denormalized form it's something like:
{results [[:results/by-id "1501"]]
:results/by-id {"1501" {"id" "1501" "plaats" "1" "person" [:person/by-name "DewildeKristof"] "categorie" "H3" "tijd" "00:53:16" "jaar" "2015"}}
:persons [[:person/by-name "DewildeKristof"]]
:person/by-name {"DewildeKristof" {"naam" "Dewilde" "voornaam" "Kristof"}}} )
(dutch version)btw, there are strings: "naam"
yea my read function translates them to keywords
ok then
btw, db->tree
operates independant of read-fns, isn't it?
yes, just supply it with the necessary params
I wonder if I my error is similar to yours one, but seems no
@anmonteiro: by throwing it in a gist, taking another look at it, that bug disappeared like magic 😬
@iwankaramazow: also disappeared from your app?
yea, db->tree
works fine now.
Transit converts a json response to strings in my app, so no keywords, they're all string
My queries contained keywords, not strings, I failed to convert them at some point...
has anyone got code to om/set-query!
via a mutation?
@robert-stuttaford: you mean inside of :action
?
i actually just want to change the QueryParams
is it really as simple as i think it is?
it probably is 😇
@robert-stuttaford: you might want to look into update-query!
@robert-stuttaford: is that :action
, is set-query!
the only thing you want to do, or something else too?
@anmonteiro: How about this:
(println
(let [data
{:items [
{:id 1
:name "hello"}
{:id 2
:name "world"}
]
}
]
(println "result is"
(om/db->tree
'[{:items [:id :name]}]
data
data
)
; returns {:items [{} {}]}
)
)
)
(that's minimal case of my appeal to db->tree
)
@robert-stuttaford: I mean, don't you trying to store copy of your query params in state also?
the query-param is a datomic lookup ref
i’m writing a generic datomic browser
just need one mutation to switch the lookup ref to some new entity, which will fetch it and repopulate the state with that entity’s data
giving me repeatable forward nav
@andrewboltachev: that's not a bug
your data is already denormalized, why are you calling db->tree
on it?
this works as expected:
(def data {:items [[:item/by-id 1] [:item/by-id 2]]
:item/by-id {1 {:id 1 :name "hello"} 2 {:id 2 :name "world"}}})
(om/db->tree [{:items [:id :name]}] data data)
@anmonteiro: oh indeed...
@anmonteiro: still the same goal — I wanted Om to read data for all my components
I tried to use db->tree
w/o much thinking
i.e., I were thinking it's right to "read data for hierarchy of components"
so, I'll get into all that links (mostly your blog but not only) and find a solution then. Thanks
so today's score is 2:0, Om vs. users
iwankaramazow hasn't had a bug and me too
@robert-stuttaford: I think you might use set-query!
/ update-query!
directly from your event handlers (e.g. button click), no need for additional transact!
call
is there a trick to getting a reference to the component you’re updating from inside that component?
(om/class->any) ?
@robert-stuttaford: use this
?
of course
thanks anmonteiro. ok. i’m SUPER close
scratch that. it’s working
thanks for your help, folks
But funny. db->tree
(and friends) don't even care about components. ident?
and other predicates are used to figure out the type of the (sub)expression. Such "duck typing"
From the other hand can't say other way (e.g. through metadata etc) efficient
@andrewboltachev: anything involved in query that deals with idents will need to know the component associated with a particular query to be able to invoke ident
we don’t have a typed schema a la GraphQL which brings it’s own host of issues I’m not interested in
well should be in JS world they probably don't have such freedom of thought, always trying to be modest
i.e. carefull
everything should be protected etc
I wonder about such huge doc on GraphQL
though I didn't read it
focus on unions were definitely inspired by it, and some of thinking about recursive queries
What I think ppl loose is appealing to some fundamental things like math. Category theorists say that for graph (of some kind, I don't remember) exists free category. I guess that there a lot more "free" stuff exists for graphs, and we can borrow from it
Not sure if a type system really delivers what it promises.
I wrote my own small library once https://github.com/andrewboltachev/regexpforobj/blob/master/src/regexpforobj/core.clj#L222 (sth like regular expressions, but "objectified")
and I think I might optimize it's structure, or even make it trivial via applying sth of math fundamental constucts. Or core.logic (probably to completely replace it)
@iwankaramazow: core.typed does inference, which I believe no one (say, Python 3 with it's "type hints" is doing)
@dnolen: looking into OM-558
hoping you can answer a question
(def data
{:people [:by-name "Alice"]
:by-name {"Alice" {:name "Alice" :age 31}}})
(def query '[(:people {:length 3})])
(om/db->tree query data data)
given this snippet, should db->tree
return the denormalized version of the data?
@bbss: it's prop + params
@anmonteiro: that’s not a join
@dnolen: so it should just return the ident?
@anmonteiro: that’s what the query says
that's what I thought
@dnolen: was just confirming. ATM it's returning {}
so, submitting a patch which should solve OM-558
simple fix really
Hello all...has any one else experienced an issue after returning tempids from a mutation (server side) where after the tempids are merged the query (om.next/query) is reset to nil? In looking at the app-state from repl, the IDs appear to be merged in but client renders nothing...
result for mutate method on server {:value [:abc/abc] :action (fn [] … )} Guys I understand correctly that the key value is needed in order to specify what data you want to return after the execution of the function action?
with a mutation you don't know what can possibly happen, therefore you just specify what you want to re-read
@a.espolov: I'm not sure about the keys
fn in mutation. But I'm sure that when you mutate like this (om/transact! component [(project/update {}) :project/list)])
on frontend, the related components ( the ones that have :project/list
query ) will be rerendered.
I will get the default value for the read method (defmethod readf :default [ k ] {:value {:error (str "No handler for read sss key " k)}})
@a.espolov: no idea
endpoint for om parser '(defn api [req] (if-not (authenticated? req) (generate-response {:msg "user unauthorized"}) (generate-response ((om/parser {:read parser/readf :mutate parser/mutatef}) {:conn (:datomic-connection req) :session (:session req)} (:transit-params req)))))'
try {:value {:keys [:test/test] :action etc.}
@iwankaramazow: no this example for front-end
@dnolen: my example is based on https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/clj/todomvc/parser.clj but my version of stubbornly doesn't want to work
yea, the todomvc is a little bit outdated
is shouldComponentUpdate returning true always? https://www.refheap.com/114012
hmm, might be easier to see what's happening here: https://www.refheap.com/114013
(bar child re-renders when its data is unchanged)
@iwankaramazow: @a.espolov Please note that :value :keys
are "for documentation purpouses only". To fire a reread one must pass read query after mutations in his transact!