Fork me on GitHub
#om
<
2015-12-01
>
tony.kay00:12:57

those two were hard to see...pushed

tony.kay00:12:47

sweet. do I get a sticker???

dnolen00:12:29

ha! need a logo first simple_smile

tony.kay00:12:00

@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.

dnolen00:12:49

@tony.kay: ok, that PR / issue requires more reading / thinking on my part so I haven’t got to it yet

dnolen00:12:09

but it’s next on my list, in the meantime if you want to clean up any formatting things there that would be helpful

tony.kay00:12:48

ok. Will do. I'll make the change I just described...I'm pretty certain that's the right thing to do.

tony.kay00:12:11

is it ok if I do that as a second commit (instead of keeping it squashed) so you can see the diff?

dnolen00:12:51

no as I don’t know when I’ll actually look at it and it will inevitably just make it more confusing for me

dnolen00:12:06

just make the commit you want, and I will read through and probably have some questions for you when I do

tony.kay00:12:58

@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.

dnolen00:12:17

@tony.kay: I might take you up on that, but I will probably just want to read through it first

tony.kay01:12:31

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.

caleb02:12:16

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.

caleb02:12:02

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

caleb02:12:10

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.

nodename08:12:27

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

nodename08:12:03

It appears that the trick he uses of set!ting js/React does no longer work; it generates

nodename08:12:24

ERROR: JSC_CONSTANT_REASSIGNED_VALUE_ERROR. constant React assigned a value more than once.

dvcrn08:12:07

we also have a channel for react native only talk over at #C0E1SN0NM

nodename08:12:50

If that’s where you are willing to talk then fine with me simple_smile

dvcrn08:12:43

let me try to reproduce your problem really fast

nodename08:12:09

(I do have the ns and :require at the top of the file; I have not set! js/React before the :require)

nodename08:12:41

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

nodename08:12:51

I have had it working in cljs without Om by saying(def React (js/require "react-native"))

nodename08:12:22

but after bringing in om next that def comes back as undefined

dvcrn08:12:00

can you drop me your code somewhere?

dvcrn08:12:49

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 anyway

dvcrn08:12:34

in 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

nodename08:12:02

code coming in a minute

nodename08:12:22

but I have the idea that natal is only for ios, not true?

dvcrn08:12:08

oh you said android -

dvcrn08:12:52

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 ....)?

nodename08:12:20

like I said, it gives an error

nodename08:12:14

hmm but the error is at compile time. Maybe it’s an error that should be ignored...

nodename09:12:04

Anyway I’ll study the template, thanks!

dvcrn09:12:44

@nodename: it compiles your code without problems for me

nodename09:12:20

Interesting. I must sleep now though. Thanks

artemyarulin10:12:38

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?

danielstockton11:12:01

shouldn't child be quoted (a symbol) in the transact call?

artemyarulin11:12:37

yep, I removed it in order to look nicer in slack simple_smile

danielstockton11:12:02

ok, otherwise looks ok to me

danielstockton11:12:13

unless something changed recently

artemyarulin11:12:31

so I understand transact! right as (om/transact! this [(mutation-name {:mutation ~parameters}) :list-of-dependen-fields])

danielstockton11:12:10

yes, i think so

artemyarulin11:12:10

last argument is exactly for this purpose? To force other components which depends on this information to re-render?

artemyarulin11:12:30

ok, thanks, then probably I have error somewhere else or I should take the version from the master

danielstockton11:12:11

i havent tried the latest alpha, not sure if something changed in this regard

danielstockton11:12:23

ah, something is coming to me

danielstockton11:12:38

did you try {:keys [:child]} as the second element in that vector?

artemyarulin11:12:25

yep, no difference

anmonteiro11:12:09

{:keys [:child]} is not for the 2nd argument in the vector

anmonteiro11:12:40

as I understand, it is supposed to be the :value in the mutate function result

danielstockton11:12:48

am i right that there have been changes recently to this stuff? atm its just a feeling

danielstockton11:12:04

from remembering little things i've heard in passing

anmonteiro11:12:23

there have been changes prior to the Conj

anmonteiro11:12:42

before, :value was just a vector of keys

danielstockton11:12:56

alpha22 is the last i tried

anmonteiro11:12:04

now it is a map of {:keys [:foo] :tempids []}

anmonteiro11:12:20

don't know in regard to which alpha number

artemyarulin11:12:27

it makes sense because I was wondering why my mutation function should know about dependent keys

artemyarulin11:12:42

cool, thx - I’ll try

anmonteiro11:12:57

@artemyarulin: this :value in the mutation function doesn't really do anything

anmonteiro11:12:19

at least the :keys part; I don't know about the :tempids

anmonteiro11:12:56

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)

anmonteiro11:12:14

in the transact! call itself

danielstockton11:12:45

as i understand, :tempids is used when merging novelty from a remote into the app state (and tempids need swapping with actual ids)

griffio11:12:27

@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

danielstockton11:12:04

isnt passing the :child key to transact trying to exercise the control?

danielstockton11:12:14

how else do you control it

artemyarulin11:12:37

@griffio: thanks, looks related but still hard to follow

griffio11:12:21

@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!

artemyarulin11:12:04

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't

artemyarulin11:12:26

i’m trying to understand because most probably I’m thinking about it in a wrong way simple_smile

artemyarulin11:12:27

oh… unless I’m changing a wrong place in a tree

griffio11:12:32

@artemyarulin: As someone else pointed out {:value {:keys [:child]} doesn’t do anything.

artemyarulin11:12:02

now I’m totally lost. What is a current way of pointing dependent keys? Inside mutate function or as an argument to transact! call?

griffio11:12:48

@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

artemyarulin11:12:58

But I guess I found an error - my mutate functions is wrong and doesn’t update state atom at the end. Thank you guys! simple_smile

griffio11:12:25

@artemyarulin: Cool. Helps to discuss the problem to see it!

dnolen11:12:35

@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.

artemyarulin15:12:12

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?

artemyarulin15:12:03

i know that I can do pretty much anything in read function, but I wonder what could be the right approach?

dnolen15:12:26

@artemyarulin: there no such thing as a query returning only ”value2”

dnolen15:12:33

queries must return maps (nested and of course vectors may appear)

artemyarulin15:12:09

sorry, I mean to say return map with only this value

artemyarulin15:12:30

I mentioned it because I can have query :p which returns the whole thing

dnolen15:12:18

if you use idents

dnolen15:12:25

your query could be as simple as

dnolen15:12:40

[{[:foo 2] [:ch]}]

artemyarulin15:12:59

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?

dnolen15:12:50

sure but you should just learn about idents

dnolen15:12:02

all the tutorials are meant to be 10 minute reads tops

artemyarulin15:12:56

to read - 10 minutes for sure. To understand - much more in my case unfortunately simple_smile But yeah - I guess this task is best solved with idents. Thanks!

gabe15:12:29

@dnolen: if you don’t mind cultural appropriation, an obvious logo option would be to use one of the symbols for om

gabe15:12:41

but I’m sure you’ve thought of that

dnolen15:12:19

@gabe: yep, no rush on my part to figure out the design stuff yet.

colinf15:12:45

@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.kay16:12:44

@colinf: Try (reset-autobuild) at the REPL. This cleans the proj and rebuilds.

tony.kay16:12:00

oh, sorry, from the REPL

tony.kay16:12:20

Are you running the latest master?

tony.kay16:12:31

try the reset and see what happens nontheless.

colinf16:12:44

@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 {}

wilkerlucio16:12:40

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

dnolen17:12:01

haha, funny how little actual UI bits there are simple_smile

artemyarulin18:12:29

Not sure, maybe it was mentioned already - does Om-next support server rendering? I have no use for it currently, but just wander

brettevans18:12:57

@artemyarulin: You need a JavaScript context like Nashorn then you can use render-to-str

dnolen19:12:59

@artemyarulin: it probably will eventually without needing a JS engine

dnolen19:12:11

we’ll likely adopt @arohner’s ideas, he gave a talk about it at the last Conj

wilkerlucio20:12:22

@dnolen: yeah, UI pretty simple, I liked how even for simple UI's like this it feels that Om.next totally worth using simple_smile

artemyarulin22:12:00

@brettevans: Oh, that was a nice talk and a cool idea

anmonteiro22:12:57

@dnolen: cryptic bug when using this in componentWillMount

anmonteiro22:12:02

says it's not declared

anmonteiro22:12:06

not really sure why

anmonteiro22:12:24

ignore that about solving

dnolen22:12:03

@anmonteiro: I have a componentWillMount case in my devcards and I don’t see anything like that

anmonteiro22:12:41

I found the problem

anmonteiro22:12:49

it happens in WillMount & WillUnmount

anmonteiro22:12:56

submitting issue & PR

anmonteiro22:12:35

it doesn't happen if you don't use this

denik22:12:57

this being undefined in componentWillMount

anmonteiro22:12:51

just noticed it's not a single commit

dnolen22:12:25

ah k, thanks

dnolen23:12:32

@anmonteiro: that’s still a merge commit

anmonteiro23:12:01

i know, your figwheel bump f'ed up my branch