This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-09
Channels
- # alda (9)
- # announcements (1)
- # beginners (6)
- # boot (140)
- # cbus (2)
- # cider (27)
- # cljs-dev (19)
- # cljsrn (17)
- # clojure (104)
- # clojure-art (1)
- # clojure-brasil (5)
- # clojure-colombia (2)
- # clojure-russia (146)
- # clojure-sg (3)
- # clojurescript (64)
- # clojurex (1)
- # cursive (17)
- # data-science (22)
- # datomic (41)
- # editors-rus (5)
- # events (1)
- # hoplon (61)
- # ldnclj (35)
- # lein-figwheel (1)
- # off-topic (1)
- # om (119)
- # onyx (214)
- # re-frame (3)
- # reagent (13)
- # robots (5)
- # slack-help (1)
- # yada (17)
@thomasdeutsch: In my eyes, the appeal of Datascript boils down to how similar you want the structure of your data store to be to the structure of the UI... Part of the appeal of "query selectors" is that the UI and data store can be quite different in structure, but the benefits of Datascript in an Om Next app are at their greatest if the difference in structure between UI and data store is relatively small.
;; transcribed om next screenshot
[:some/key] ;; prop
[(:some/key {:arg :foo})] ;; prop + params
[(:some/key [:sub/key])] ;; join + selector
[({:some/key [:sub/key]} (:arg :foo))] ;; join + params
[[:foo/by-id 0]] ;; reference
[(fire/missiles!)] ;; mutation
[(fire/missiles! {:target :foo})] ;; mutation + params
Does Om.now has something similar to statics in React? https://facebook.github.io/react/docs/component-specs.html#statics
I want to be able to see the ‘type’ of an instance of an Om component, and I thought that was a way of doing it. Any other suggestions are welcomed
i started to use datascript simply because in many components, i needed to get state that can be found on multiple locations - and there are many problems connected to this issue.
(same atom)
a sample app: a todo-list application, and every todo-item has a "tag" input where you can select from given tags like "important" or "later". the list of tags is a global entity (not part of the todo-list or item).
@dnolen: maybe it was not a good idea to allow this query to work [:a/name {:a/b [:name]}]
without a reader for :a/b to be required.
(for datascript)
@dnolen: thanks for the recursive queries, I am going to study it today
@hmadelaine: not quite done yet
still sorting through update issues and recursive queries fundamentally need path optimization support
@thomasdeutsch: whether a query will or won’t work is not something Om Next is involved in. That’s entirely up to you.
@dnolen: type in quotation. I just want to find out, whether a component has a certain characteristics. I could use React’s statics for this, but I cannot find anything similar in Om.now
@grav there’s no supplied sugar for defining static methods. but you could supply such sugar yourself this is how defui
works in Om Next.
@dnolen: thank’s for the advise 😉
Hi, I’m trying Om.next and I’m curious if (get (om/props this) :children)
should work or am I doing something wrong?
@hmadelaine: so one thing I’m wondering is whether the generalized recursion thing is worth pursuing, it would add a lot of complication over the support for Datomic Pull …
so basic recursive queries with mutations works in master https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/core.cljs#L299-L388
it means stuff that's normally tricky, like threaded discussion UI is kind of trivial in Om Next esp. if you throw Datomic into the mix.
@dnolen: I am going to think about that. For the moment I have used DataScript to store my recursive nodes and Marked the children as “component” to bypass the lack of declarative recursive Query. It works well to represent the data. But fails as we expect if I send a mutate action from a child node. Maybe it is not worth pursuing if only me and @mhuebert ask for it
@hmadelaine: hrm wouldn’t the mutation bit be covered if you can intercept the transaction?
@hmadelaine: the other reason I’m kind of lukewarm about the generalized recursion thing is I don’t really see how to make it work for sending across the wire.
@dnolen: I am going to try the interception as you suggest
@dnolen I have to try Om-Next with a backend
@hmadelaine: hrm I guess the backend bit could be made to work if there was support for naming queries … but that’s a whole other complication
@dnolen: so now that the basic recursive queries with mutation works in master, I can study it ? And try it with DataScript ?
@hmadelaine: the bigger issue is that neither Datomic nor DataScript support this anyway
@hmadelaine: yes please try it out
@hmadelaine: i would love to see a small example in datascript
@hmadelaine: so far my hunch is that the component trick + Dataomic DataScript local recursion can be made to work for most problems.
@dnolen: you are right, I did not think about the syntax problem.
@hmadelaine: I am fixing the tx intercept stuff right now
and you can of course pass up any information the parent might need to make the transaction precise
@dnolen: great ! It should work
@hmadelaine: fix applied to master it may (probably does) need some tweaking - so feedback is welcome
@dnolen: thank you very much ! I am going to roll up my sleeves and try it
@dnolen: the example I have set up with DataScript now works out of the box with the support of recursive query.
@hmadelaine: awesome
@dnolen: you are awesome !
Quick question on re-rendering logic so I understand intended behavior. If component A has two children, A-1 and A-2, and component A initiates a transact!, I know it will re-render. Do A-1 and A-2 always re-render, or is an equality check on their props done to determine if they need to re-render?
Can someone explain the reasoning for mutations to modify atoms instead of being pure and hiding the actual statefulness?
For what purpose. Also mutations don't have anything to do with atoms. Any state transition.
@dnolen how did you decide on the idea that om should builds up a denormalized tree and is passed down from the root via props. i think relay’s approach is closer to each component is wrapped in a magic container with queries that keeps it in sync. is this a correct assessments of a difference? curious what tradeoffs you weighed there.
The primary difference from relay is functional first. And we can run queries on client or server a la Falcor.
Getting Started Question: I’m getting
Uncaught TypeError: Cannot read property 'force_children' of undefined
when trying to work through the om.next Quick Start. It happens with the code in the “Your First Component” section (and all sections after that I’ve tried).Yeah, I think I had the problem because I tried to use the latest cljs, but then hit a build problem (`No such namespace: cljsjs.react`), and it was easier to step back to the previous version.
Also, this is my first time playing with cljs, really, so didn’t realize lein clean
wouldn’t clear out the compiled files.
@dnolen: do you envision the tempid api for om.next to be similar to datomic’s tempid api? In the sense I can use a tempid every where a real id can be used in an transaction. Then i transact and all references to that tempid is replace with the real id?
Is there a function to get a list of components that will re-render with a given query? i.e. which components will re-render based on :a-query in: (om/transact! '[(foo {} [:a-query])]
@iwillig: that’s the basic idea yes, but specifics will not be much like Datomic or DataScript
I'm interested in it for troubleshooting. I have a component that sometimes re-renders for the same transaction. So I was trying to narrow down the problem, I wanted to be sure om.next had it as a component it would re-render based on that key to rule out that as a possible problem.
And the key, i.e. :a-query will trigger a re-render no matter how deeply nested it is in the query/component hierarchy assuming recursively parsing got us to that key at some point?
@joshfrench: fixed your bug sorry for the delay
@dnolen: Yes, exactly what I was looking for thanks. The docs threw me as the example appeared to focus on Ident.
@dnolen: just spotted that, thanks!
the combo of Figwheel + devcards & Node.js REPL + cljs.test is one of the best testing combos I’ve ever used
++ i tried out devcards on this project and just the act of isolating a component from its parent immediately surfaced all the assumptions i’d made
@dnolen: The selector part of (remote) queries should be applied server-side, right? I.e. filter fields on the server and don't send the ones not requested back over the wire.
Ok. I'm asking because if you have (om/transact! this '[(app/do-something ...) :items/list])
, it means that the server-side parser will receive an empty selector for :items/list
. Am I assuming correctly that I have to repeat the full queries when passing them to transact!
? That is, if the component query would be [{:items/list [:db/id :item/name]}]
, :items/list
would not be enough to send the same selector to the server?
Automating or providing a shortcut to reusing parts of the component query for transact!
. Especially when dealing with long queries (e.g. [... ({:items/list ~(om/get-query Item)} {:foo ?foo :bar ?bar})]
) it'll be tedious to repeat them in all transact!
calls.
But yeah, I can work with that for the moment. A simple helper function to generate a sub-query like that will do.
Does anyone know the 'correct' way to pass multiple collections to a sub-view in Om Next? I've read and implemented 'Queries with Unions' in another case, but (I think?) this is different. For example, I have a SubView that expects two collections, set up as follows, but I get a "No queries exist..." error when I transact.
SubView
Query
{:foo/all [...]
:bar/all [...]}
AppView
Query
{:foo/all (:foo/all (om/get-query SubView))
:bar/all (:bar/all (om/get-query SubView))}
Render
(sub-view (om/props this))