This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-01
Channels
- # admin-announcements (20)
- # aws (24)
- # beginners (323)
- # boot (60)
- # business (1)
- # cider (23)
- # clara (7)
- # cljs-dev (38)
- # cljsrn (12)
- # clojure (302)
- # clojure-canada (5)
- # clojure-dev (26)
- # clojure-miami (1)
- # clojure-nl (13)
- # clojure-russia (64)
- # clojurecup (1)
- # clojurescript (202)
- # clojurex (4)
- # code-reviews (5)
- # core-async (23)
- # cursive (39)
- # datavis (26)
- # datomic (34)
- # devcards (5)
- # editors (19)
- # emacs (4)
- # events (6)
- # funcool (55)
- # hoplon (5)
- # ldnclj (3)
- # lein-figwheel (1)
- # luminus (15)
- # om (159)
- # omnext (7)
- # onyx (107)
- # slack-help (2)
- # testing (3)
@dnolen: On the process roots rewrite: It is heavily tested, and works for all of the cases I could think of. The one case that I'm a little fuzzy on is a recursive query merge...I just white-boarded it a bit with a co-worker, and I don't think the test for this represents a real possibility. In fact, I can't think of a case where a recursive join should be even marked as root. So, perhaps I should delete that test, and change the code to have an assertion there instead so they get a runtime error if they try to do that.
@tony.kay: ok, that PR / issue requires more reading / thinking on my part so I haven’t got to it yet
but it’s next on my list, in the meantime if you want to clean up any formatting things there that would be helpful
ok. Will do. I'll make the change I just described...I'm pretty certain that's the right thing to do.
is it ok if I do that as a second commit (instead of keeping it squashed) so you can see the diff?
no as I don’t know when I’ll actually look at it and it will inevitably just make it more confusing for me
just make the commit you want, and I will read through and probably have some questions for you when I do
@dnolen: done. When you get to it, if you want to save some brainpower understanding what I did then I can skype or google hangout with you and show you on a whiteboard...probably save you a bit of time.
@tony.kay: I might take you up on that, but I will probably just want to read through it first
For those following the Om tutorial project, I've rearranged the project. Make sure to read the instructions again. I've also started adding exercises which will lead to building a full-blown full stack project exercising most of the features of Om.next. Several weeks to go, probably, but feedback is welcome.
@dnolen: typo is fixed
@codonnell: thanks!
no problem!
I’m playing with Om Next and I think I’m starting to wrap my head around how queries work. I understand the initial query for a component tree, and I understand mutations. What I’m not really clear on is performing queries after the page is rendered, like say if I wanted to fetch a list of comments for an article that the user clicked on.
It seems like there might be a few options: 1) Side load the data into the state atom, 2) use set-query!
to add queries to the root query, or 3) Make the user transition to a new app state and create a new root with add-root
Side loading doesn’t seem like a good answer since it sidesteps the features Om provides, and creating a new root doesn’t necessarily feel right either. set-query!
seems like it could be a solution, but I am not imaginative enough to see how that would work.
I’m trying to use om/next with React native on Android and I came across David Mohr’s post https://dvcrn.github.io/clojurescript/react/2015/10/27/going-native-with-om-next.html
It appears that the trick he uses of set!ting js/React does no longer work; it generates
ERROR: JSC_CONSTANT_REASSIGNED_VALUE_ERROR. constant React assigned a value more than once.
(I do have the ns and :require at the top of the file; I have not set! js/React before the :require)
btw the error text continues: Original definition at file:/Users/alan/.m2/repository/cljsjs/react/0.14.0-0/react-0.14.0-0.jar!/cljsjs/react/common/react.ext.js:11 at /Users/alan/Workspaces/Clojure/AwesomeProject/target/cljsbuild-compiler-0/hello/core.js line 6 : 0
I have had it working in cljs without Om by saying(def React (js/require "react-native"))
afaik it is not necessary anymore to overwrite it twice. With next, it should be ok to just do
(set! js/React (js/require "react-native/Libraries/react-native/react-native.js"))
because we specify the render function manually anywayin general the safest bet with the latest learnings is usually inside natal. So natal init foo --interface=om-next
should always give you the optimal setup
ok working non-om code is at https://github.com/nodename/AwesomeProject/blob/master/src/hello/core.cljs
and code I’m trying to make work is at https://gist.github.com/nodename/1a39441781c7bcfae1fe
hrm on the first look, not sure. I'll take a closer look when I'm a bit more free but for the time being I'd suggest to try to match the template as much as possible - https://github.com/dmotz/natal/blob/master/resources/om-next.cljs
for example, can you try specifying the full path to react-native "react-native/Libraries/react-native/react-native.js"
?
Also I am not sure when React is actually using React...
internally. Is there a specific reason why you don't want to do (set js/React ....)
?
Hi, can anybody help: I have a parent and a child component. I would like that parent do re-render when child state has changed.
Parent has a query (query [this] [{:child (om/get-query Child)}])
and child mutates like (om/transact! this [(child {:val 1}) :child])
State changes everything is fine, but parent doesn’t re-render, am I doing something wrong?
shouldn't child be quoted (a symbol) in the transact call?
yep, I removed it in order to look nicer in slack
ok, otherwise looks ok to me
unless something changed recently
so I understand transact! right as
(om/transact! this [(mutation-name {:mutation ~parameters}) :list-of-dependen-fields])
yes, i think so
last argument is exactly for this purpose? To force other components which depends on this information to re-render?
ok, thanks, then probably I have error somewhere else or I should take the version from the master
i havent tried the latest alpha, not sure if something changed in this regard
ah, something is coming to me
did you try {:keys [:child]} as the second element in that vector?
yep, no difference
{:keys [:child]}
is not for the 2nd argument in the vector
as I understand, it is supposed to be the :value
in the mutate function result
am i right that there have been changes recently to this stuff? atm its just a feeling
from remembering little things i've heard in passing
there have been changes prior to the Conj
before, :value
was just a vector of keys
alpha22 is the last i tried
now it is a map of {:keys [:foo] :tempids []}
aha, ok
don't know in regard to which alpha number
it makes sense because I was wondering why my mutation function should know about dependent keys
cool, thx - I’ll try
@artemyarulin: this :value
in the mutation function doesn't really do anything
at least the :keys
part; I don't know about the :tempids
as I understood it, it's just meant to be a guide for anyone applying the mutation (so they know which keys they need to re-read)
in the transact!
call itself
as i understand, :tempids is used when merging novelty from a remote into the app state (and tempids need swapping with actual ids)
@artemyarulin: How different is your case from what dnolan responded and sander’s query yesterday? read up from https://clojurians.slack.com/archives/om/p1448828463003661
isnt passing the :child key to transact trying to exercise the control?
how else do you control it
@griffio: thanks, looks related but still hard to follow
@artemyarulin: Yes. it’s just sorting out where your requirements are different. For example, you can use om/computed to pass down to the child the transact. So it occurs in the parent control. For example child controls don’t delete themselves!
I’m just a bit confused why my mutation functions looks like
{:value {:keys [:child]}
:action #(swap! state update-in [:a] “b")}
and it should force all the components that depends on :child
key to re-render but they doesn'ti’m trying to understand because most probably I’m thinking about it in a wrong way
oh… unless I’m changing a wrong place in a tree
@artemyarulin: As someone else pointed out {:value {:keys [:child]} doesn’t do anything.
now I’m totally lost. What is a current way of pointing dependent keys? Inside mutate function or as an argument to transact! call?
@artemyarulin: "transact is a parse expression that should include mutations followed by any necessary read. The reads will be used to trigger component re-rendering.” <- The transact is used to determine re-rendering
ok, fine
But I guess I found an error - my mutate functions is wrong and doesn’t update state atom at the end. Thank you guys!
@artemyarulin: Cool. Helps to discuss the problem to see it!
indeed!
@caleb there’s a lot of ways to solve that one. Delayed loading of queries is probably the simplest and most declarative. the FAQ has an example.
sorry for the dumb question - I have a state smth like {:p [ {:ch “value1” :idx 1} {:ch “value2” :idx 2}]}
and I would like to write a query which would return only “value2”, nothing else. I’m a but confused what syntax should I use? It couldn’t be simple join as there is a vector and I need to get second value of it first. Any suggestions?
i know that I can do pretty much anything in read function, but I wonder what could be the right approach?
@artemyarulin: there no such thing as a query returning only ”value2”
sorry, I mean to say return map with only this value
I mentioned it because I can have query :p
which returns the whole thing
hm, yeah. And what if I don’t use idents? (to be honest I don’t know how to use it yet:)) Is it possible?
to read - 10 minutes for sure. To understand - much more in my case unfortunately But yeah - I guess this task is best solved with idents. Thanks!
@dnolen: if you don’t mind cultural appropriation, an obvious logo option would be to use one of the symbols for om
@tony.kay: Thanks, the tutorial project is very useful. I’ve been looking at tutorial section E to help me understand idents and db->tree. When I run the same code from the repl in an om alpha-24 project I don’t get the same results. e.g:
(def sam {:db/id 1 :person/name "Sam" :person/mate [:people/by-id 2]})
(def jenny {:db/id 2 :person/name "Jenny" :person/mate [:people/by-id 1]})
(def app-state {:widget/people [[:people/by-id 1] [:people/by-id 2]]
:people/by-id {1 sam 2 jenny} })
(om/db->tree '[[:people/by-id 2]] app-state app-state)
doesn’t give the same result as your test. Does the devcards wrapper add something that I have missed?@tony.kay: Thanks. Not on the latest master but will try the (reset-autobuild)
and then if no joy fetch the latest version of the tutorial. But the above code seems fairly independent in that the only “external” code it uses is om and that is what has confused me. I have also run it at the repl in a skeleton project with only om alpha-24 to try and eliminate other factors but it always returns {}
I just released a Chrome extension to created loops for youtube videos, built with Om.next, might be useful as reference for some of you: https://github.com/wilkerlucio/youtube-looper
@wilkerlucio: whoa!
Not sure, maybe it was mentioned already - does Om-next support server rendering? I have no use for it currently, but just wander
@artemyarulin: You need a JavaScript context like Nashorn then you can use render-to-str
@artemyarulin: it probably will eventually without needing a JS engine
nice, thanks
@dnolen: yeah, UI pretty simple, I liked how even for simple UI's like this it feels that Om.next totally worth using
@artemyarulin: I think @dnolen is referring to this talk http://youtu.be/fICC26GGBpg. Blog post here as well https://rasterize.io/blog/server-side-foam-rendering.html
@brettevans: Oh, that was a nice talk and a cool idea
@dnolen: cryptic bug when using this
in componentWillMount
says it's not declared
switching from ~this
to this#
seems to solve it, here: https://github.com/omcljs/om/blob/master/src/main/om/next.clj#L81
not really sure why
ignore that about solving
@anmonteiro: I have a componentWillMount
case in my devcards and I don’t see anything like that
I found the problem
it happens in WillMount & WillUnmount
submitting issue & PR
it doesn't happen if you don't use this
@anmonteiro @dnolen just reproduced
@dnolen: see PR 511
just noticed it's not a single commit
squashing
@anmonteiro: that’s still a merge commit
i know, your figwheel bump f'ed up my branch
@anmonteiro: merged, thanks