This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-26
Channels
- # admin-announcements (1)
- # beginners (167)
- # boot (117)
- # boulder-clojurians (1)
- # cbus (1)
- # clara (3)
- # clojure (87)
- # clojure-conj (2)
- # clojure-japan (2)
- # clojure-russia (23)
- # clojure-spain (3)
- # clojure-za (2)
- # clojurescript (184)
- # community-development (8)
- # core-async (7)
- # core-matrix (4)
- # cursive (36)
- # data-science (74)
- # datascript (3)
- # datomic (171)
- # events (6)
- # hoplon (83)
- # ldnclj (5)
- # ldnproclodo (1)
- # lein-figwheel (2)
- # leiningen (19)
- # liberator (2)
- # off-topic (5)
- # om (227)
- # onyx (5)
- # re-frame (142)
- # reagent (4)
- # yada (5)
I was looking at this https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/core.cljs
but couldn't really understand it, like for example how to get the counter component from the Basic Tutorial to work as a devcard
@paulb have you gotten devcards working with other components? I was able to pass in components created via defui & om/factory with no trouble
@paulb but I was not using om next to manage state yet, so I’m not sure how the updates would work
@mhuebert yes, I can can set prop values and see what the component looks like, but don't know of a way to test how the component functions when interacted with
@paulb ok. I’ve just started figuring out om mutations myself and am not yet clear on how it all works.
Tiny non-working recursive tree in om/next: https://gist.github.com/mhuebert/dc1acc48b7c192cc49fb I would have expected queries in child components to run, but they are ignored. it seems all data must be passed down from the top? (when I try that, data flows down appropriately but I run into a "No queries exist for component path” error when I try to mutate)
when using om next, does a flux architecture make sense? or is there something that would fit better?
looks like I spoke too early with react native. Seems like it was more a lucky hit because of some pre-loaded code
hrrrmm Error: Invariant Violation: ReactDOM.render(): Invalid component element. This may be caused by unintentionally loading two independent copies of React.
all right, time to call it a loss. Overwriting js/ReactDOM with js/React seems to solve a lot of the problems as the API is still very similar.
I also changed add-root!
to not use gdom
, but the final error I couldn't manage to get around (yet) is You cannot render into anything but a top root
.
Tried saving the reference of the top root component from index.ios.js
and using that, but still didn't work.
I guess I'll just wait a little until om next is at a more stable point or react native adapts react 0.14 fully. If anyone has tips of things I could try, please ping me!
I started playing with Om Next and I'm at the end of the "Components, Identity & Normalization" wiki article - for some reason, I only end up with a console error "Cannot read property 'render' of undefined". I tried copying the full code from the Appendix, but it's all the same - where should I look?
ok, another go at a recursive tree in om/next - I tried to make the queries like the examples: https://gist.github.com/mhuebert/dc1acc48b7c192cc49fb it renders appropriately, but after my first mutation I get a "No queries exist for component path (layout.core/Root layout.core/Leaf)” error (stack trace is in a comment on the gist)
@chipf0rk is there a reference somewhere to js/React.render? that should now be js/ReactDOM.render, changed in recent version of React
1.0.0-alpha9, but I also tried with 1.0.0-alpha8, as referenced at the beginning of the article
@chipf0rk I had to add :exclusions [cljsjs/react cljsjs/react-dom]
to some other dependencies in my project (sablono, devcards) in order to get the correct (om-specified) version of react to load.
the funny thing is, ReactDOM is undefined
, but it shows up in the console's autocompletion when I start typing "Rea..."?!
ok. when this happened to me it was from some other dependency loading an old version of react
@dvcrn: it’s just a bug we have references to ReactDOM in the reconciler, should probably parameterize that
@dvcrn: you don’t need flux if you’re using Om Next, all the flux stuff becomes plumbing
Well, it's working now. lein deps :tree
only showed what om pulled in and it was all 0.14.0
; however, react.inc.js
was at 0.13.3
for whatever reason and wouldn't change even after pulling deps and restarting figwheel. I killed the whole js/
directory and my ~/.m2/
too, then restarted – that fixed it
@dnolen: I'm planning to invest a few more hours tomorrow into making it run with native at least once. Do you have thoughts on a workaround for that bug I could try?
parameterize js/ReactDOM.render
so that instead that becomes some user supply-able thing in the reconciler :config
Hi, getting error "No queries exist for component path (lisperati.core/Parent lisperati.core/RectLayout)" https://gist.github.com/drcode/617351ed39533e11ff43 on alpha9
I have a parent component that is using a rather generic "Rectangle Layout" component to manage it's children
I suspect that I'm doing something in the Parent class either in render() or in query(), because both functions manage both the RectangleLayout class and the Child class objects
> (om/get-query Parent) [{:rects [:db/id :rect/dimwidth :rect/dimheight :rect/color :rect/width :rect/height :rect/left :rect/top]}]
your code is missing another layer because the parent is abusing the child query and not providing it’s own
every component must provide it’s own query. You cannot reuse the child’s query. This is a modularity violation to do so.
@drcode your example is something I think we can detect without creating problems so will probably throw an error if you do what you did.
@drcode figuring out how to validate queries and transactions is definitely something for me as well others to think about.
most of the issues people have are not understanding how to separate out their queries and where to run transactions.
I'm playing with writing a basic Kanban app using om.next, with boards that refer to lanes and lanes that refer to cards. And it works! om.next normalization works perfectly, I've got something similar to add-friend
(`move-card`) that moves a card from one lane to another, and I even managed to get card drag-and-drop to work with transactions. Amazing! Starting to get the hang of this. Thanks @dnolen for your patience, help and hard work.
Perhaps I should turn it into a blog post, just to give people another example app to look at? It currently operates against local state only, so it would be easy to put it on GitHub and allow people to play with it as well.
more examples are good, writeups even better as long as there are caveats “alpha software” yadda
@dnolen: I am struggling with the same error of “No queries exist” when calling transact! in a child component. I have gone back over the docs, and can’t find guidance on where they should go. Am I overlooking it?
2) put transactions where they actually belong (children who don’t actually have the context to run a transaction should never invoke it)
@dnolen: I didn’t think I was violating those rules of thumb. But I was thinking about what you have written before, so I passed the function in as a callback and it worked. Now I just need to get my head around why.
Hey all, I’m following along with the om-next-demo app on alpha9, why does the send function now recieve a map of the form {:remote [:foo]} instead of just the map.
query*
is that supposed to be the case?
@gardnervickers: Because you can specify multiple remotes now, I believe.
E.g. instead of {:value ... :remote true}
in read
, you can do {:value ... :remote1 ... :remote 2 ...}
.
@gardnervickers: See https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial
another bit of validation that I added - https://github.com/omcljs/om/commit/f0d7feb3e93373e0349761e3f77a1330900a2813
@jannis: So really my :send
function needs to be able to handle where to route stuff now?
@gardnervickers: yes and no
if you don’t care about mutiple remotes you will always get a map with one thing in it :remote
gotcha
that’s the default, but for users that want to design their application around HTTP caching, the multiple remotes bit makes life a whole lot simpler
@dnolen: Looking forward to your unsession at the conj. Anything we need to do to say I'm attending or anything like that?
how is an om.next reconciler able to extract the queries of all the children given a root?
currently don’t maintain child parent relationships, but this doesn’t seem like useful information to me - or not useful enough to track
so given any “class path” the indexer knows what query template is associated with that path.
okay, so the reconciler uses the indexer to figure out all the different queries and merge them together
it asks the indexer for components that match those keys, it re-renders those components
it re-renders them with props determined by re-running queries for these components (which the indexer delivers)
the indexer knows everything - the reconciler just keeps things in sync and makes remote requests on your behalf.
@jannis such a blog post would be appreciated, I am doing something similar with lanes. But not at your stage yet
just looked into the remote sync tutorial, it looks like DashboardItem explicitly calls om/get-query
, on the child elements (Post, Photo, Graphic)
@dnolen: yep, I was just foggy on how a parent's query gets those child queries, seeing that code cleared things up
@scriptor: right you could jump around randomly but I do suggest reading the tutorials in order from beginning to end
true, I read the quick start, was just getting a bit curious how nested components might work
is it possible for the results of a parent query to influence a child component’s query? ie. a parent component fetches a list of IDs, then child components fetch data associated with those IDs
trying to render a recursive tree, wondering how, say, a mutation that only affects a leaf node would trigger only that leaf to re-render, if the entire tree is passed down from the root in a single query
does all data always flow from the root component? ie. its query reaches down into the tree w/ get-query
(and a child component does the same to its children, as far as needed)?
one problem with this - from what I understand, the call to om/transact! should not come from a leaf node, hence the “no queries exist” error
leaf queries cannot 'stand on their own,' as they only return selectors - '[:leaf/label :leaf/id :leaf/_parent]
- the only place where an actual id shows up is at the root node, so every data update would require the whole tree to be reconstructed
transact! can come from any node that implements IQuery so your conclusion is not correct here
the example is pulled from a little outliner i’m making. you would want to get away from nesting?
if you’re encoding your UI deeply into the data itself … you’re also creating problems for yourself.
so the data itself is just a pile of nodes with child-parent relationships in datascript, which i can use a recursive pull expression to get a tree out
and use a listen! on the datascript db and re-render the whole tree on every change?
unless your tree has thousands of things it (which it shouldn’t because React will fall down anyway)
so from the first brief reading I’d done I had thought of the indexer as a means to know which components were dependent on which nodes, and then I could force those components to refresh via the :value
field in the mutation
windowing?
gotta run, but I cannot explain all the optimizations that React nor Om Next doesn’t solve
@dnolen - doc error on http://omcljs.om wiki, page “Components, Identity & Normalization”, in Normalization section: example uses: (def init-date Should be init-data.
so your case actually corresponds almost precisely to the problem of recursion in type systems
queries are kind of like typing over the UI (this analogy make sense it’s what’s known without running the thing - static)
@mhuebert: so the question becomes how can the reconciler deal with this thing which has a recursive query
so if a query is recursive, switch to a cursor instead (which is purely a runtime thing)
so all my previous statements hold - but we could provide a way to hook back into the reconciler so you can get precise updates
not sure about whether I’ll actually pursue that, but I’ve jotted some notes down about it.
@kahunamoore: thanks fixed
@dnolen cool, thanks. I can see the analogy w. types & static analysis. I haven’t used cursors in om before so I’ll have to look into that (I used them w/ reagent), I’m not sure what switching to a cursor would look like in this case.
@mhuebert: it would just be a way to run transact on something that the indexer could not possibly index
once you hit the recursive case the indexer necessarily would have to give up - it wouldn’t know how deep the thing is or what’s underneath the recursive query
@dnolen Hello, I'm reading "Components, Identity & Normalization" and I don't get what the {:keyfn :name} is for in this line (def person (om/factory Person {:keyfn :name}))
@maoran: It's for generating a unique React key based on (:name props), so each Person component gets its own key.
this is a react concept: https://facebook.github.io/react/docs/multiple-components.html#dynamic-children
It's a React thing that it uses to identify components, in particular to optimize/reduce modifications to the DOM.
without a key it just uses order, but if you remove something it needs to know which exact element to remove, for example