Fork me on GitHub
#om
<
2016-07-10
>
creese00:07:12

I'm trying to extend the tutorial on normalization and identity. I want to set the query for RootView to something else but I'm getting an error.

Warning: flattenChildren(...): Encountered two children with the same key, `.$null`. Child keys must be unique; when two children share a key, only the first child will be used.

creese00:07:18

What does this mean?

creese00:07:27

I think I understand the error. After I set the query, the props come back as

{:list/two [nil nil nil]}
I'm not sure why that is.

cjmurphy00:07:29

@creese: Your first error comes from React. A good way to stop it is to have a :keyfn in your component factory function.

cjmurphy00:07:03

(def ui-todo-item (om/factory TodoItem {:keyfn :db/id}))

cjmurphy00:07:57

With the second I would expect let [{:keys [list/one]} (om/props this)] to work. You only have one join keyword (`:list/one`), so that is all that should be coming out of props.

creese00:07:38

I'm changing it to :list/two in the REPL.

cjmurphy00:07:10

I see now. It makes sense to me what you are doing, or trying to do.

cjmurphy00:07:12

A good thing to use for switching like that is unions.

cjmurphy00:07:27

I don't think set-query is used for setting the whole query, just for setting params, so should be used in conjunction with IQueryParams.

creese00:07:49

The tutorial renders two lists sequentially. I want to create a nav so I can choose which one is displayed.

creese00:07:40

It seemed like changing the query for RootView was the way to go

cjmurphy01:07:40

That TodoMVC tutorial, where is it from?

cjmurphy01:07:38

There's no set-query! in that tutorial - it is used in other tutorials.

creese01:07:08

I know. I'm done with the tutorial. I'm trying to extend it

cjmurphy01:07:31

Also the query used in that tutorial makes sense as two people to be shown.

creese01:07:53

There are two lists of three people each

creese01:07:19

I want to figure out routing. I have two pages now, each one shows a different list. I haven't seen a tutorial on that.

cjmurphy01:07:08

Look at the union example the most

cjmurphy01:07:49

That is indeed promising. Old but very good to study.

cjmurphy01:07:49

Shows you how to avoid all the complications, so gives a really good start...

cjmurphy01:07:42

From before - yeah I see - two lists of people in the app state.

creese02:07:57

@cjmurphy: I'm working through "Routing with Union Queries". The query is:

[:app/route {:route/data {:app/home [:home/title :home/content], :app/about [:about/title :about/content]}}]
What should the data be?

krchia02:07:25

i have this really weird bug

krchia02:07:58

"Don't know how to create ISeq from: clojure.lang.Symbol” and it’s pointing at the reify part of every single one of my component

krchia02:07:22

it looks like this

krchia02:07:24

---- Could not Analyze src/cljs/om_test/core.cljs line:27 column:3 ---- Don't know how to create ISeq from: clojure.lang.Symbol 26 (defn cell [cell owner] 27 (reify ^--- Don't know how to create ISeq from: clojure.lang.Symbol 28 om/IRenderState 29 (render-state [_ {:keys grid-values}] 30 (dom/div #js {:className (str "grid-cell tile-position-" (:id cell)

krchia02:07:12

it was just fine when i was using IRender

krchia02:07:29

the problem only comes up when i change it to IRenderState - but i can’t imagine why

krchia02:07:30

ah, i got it

creese05:07:13

The example for Routing with Union Queries works fine, but I'm getting an error when I try the version using set-query!

Uncaught Error: No method in multimethod 'om-tutorial.core/read' for dispatch value: :params
It seems that when set-query! is called in componentWillMount, the query is wrapped in :params and this is seen by my read parser that way.

creese05:07:07

I've created a repo for anyone who wants to take a look: https://github.com/creese/om-next-routing-example

cjmurphy08:07:23

@creese: Seems like you got through the Unions example. The example that really helped me with Unions is here: https://github.com/untangled-web/untangled-cookbook/blob/master/recipes/tabbed-interface/README.md. I can't help with set-query! as so far for me there have always been simpler approaches - like just using Om Next app state - that have solved the problem.

anmonteiro15:07:44

@wilkerlucio: so the problem is the distinction between class / instance

anmonteiro15:07:30

when you write (js/Object.create (.-prototype c)), get-query will think this is a component instance instead of a component class

anmonteiro15:07:44

so you’ll also need to: (gobj/set c "om$isComponent" false)

anmonteiro15:07:49

then everything should work!

cmcfarlen15:07:18

@anmonteiro: I confirmed your fix to that migrate issue dropping ::compassus/route. Thanks again!

anmonteiro16:07:24

@cmcfarlen: cool, I’ll probably cut a release later today

creese16:07:18

@cjmurphy: The main requirement is that the query be small. The props should contain only data for the component shown.

cjmurphy17:07:48

@creese: The actual data that you give to a component is not exactly related to the component's query: you can have a component with lots of keys yet only provide data for some of them - the others will just be nil. Also with all the join keys it is not known whether 0, 1 or more of the joined to component are actually going to be arriving.

wilkerlucio18:07:45

@anmonteiro: humm, I just tried that, at first doing that on the non advanced made it work, but in advanced it still failing... let me show you my last attempt (I though that would work, but it didn't):

wilkerlucio18:07:13

failed with same error as before, it still considering it a component when checking at om/component?

wilkerlucio18:07:45

I had set the prototype property besides the one in object.create because otherwise on the second run it doesn't find the .prototype

anmonteiro18:07:12

@wilkerlucio: so you might be confusing something there

anmonteiro18:07:50

this will be bound to a class before instantiation but it will be bound to an instance after initialization

anmonteiro18:07:05

and an instance doesn’t have a prototype

anmonteiro18:07:17

so then you can call the method directly

wilkerlucio18:07:19

I'm confused, because the idea was to just be passing a static class around to call protocol methods on it, it wasn't supposed to be an instance of the class anywhere

wilkerlucio18:07:50

the Object.create I though was a hack so we can be able to call those methods again (because on advanced compilation, everytime I return the class from a method it loses the static methods)

anmonteiro18:07:23

@wilkerlucio: right but after a component is mounted you’re probably passing a component instance?

wilkerlucio18:07:39

this method of mine is never called on instances, just statically

wilkerlucio18:07:56

and you can check my last snippet, it's a minimin case isolated from my code

anmonteiro18:07:58

hrm, I’ll double check it later and let you know

wilkerlucio18:07:14

the issue here is being:

wilkerlucio18:07:27

1. I have a custom static protocol on my Om component

wilkerlucio18:07:40

2. The class of the component is returned by a function

wilkerlucio18:07:25

3. We call this static method on this returned reference

wilkerlucio18:07:42

4. Inside of the static method, we call another static method (`get-query` on this case)

wilkerlucio18:07:58

this last call is being the one that is failing for me no matter what I do

wilkerlucio18:07:28

and thanks for looking at it with me

hueyp18:07:33

if you specify! on it outside of defui does it work? e.g. (defui Foo), (specify! Foo ICustomProtocol) ?

hueyp18:07:37

ah nvm, re-reading — the protocol works, its the second call that fails?

anmonteiro18:07:37

@wilkerlucio: so I’m noticing something now

anmonteiro18:07:49

if you already modify the object in which you’re making the 1st call

anmonteiro18:07:55

why are you doing it a 2nd time?

anmonteiro18:07:30

my thinking is that is should just work because you’re receiving the right object then

wilkerlucio18:07:43

the second was more like a desperate attempt, because without didn't worked as well

wilkerlucio18:07:58

what I'm noticing is that once we convert it to an instance, we can't get back to a "static class"

wilkerlucio18:07:18

the call to get-query is thinking we are dealing with an instance, but that is not the intention

wilkerlucio18:07:38

setting the om$isComponent is not taking effect for some reason

anmonteiro18:07:57

@wilkerlucio: that just sounds weird to me, but I haven’t looked at your minimal case yet

anmonteiro18:07:14

can’t do it until a little bit later, so take my words with a grain of salt

wilkerlucio18:07:09

that's really weird, I'm guessing it's about some transformation happening during the adv comp, but I didn't figure what is exactly

wilkerlucio18:07:33

can you tell me more information about the original issue, like, why on adv compilation it loses the static methods in the first place?

anmonteiro18:07:19

@wilkerlucio: no idea, no, I’ve only seen it by reading Om’s source

anmonteiro18:07:19

just pushed devcards-om-next version 0.2.0 to clojars with fixes to defcard-om-next which actually reloads component code while preserving local state https://github.com/anmonteiro/devcards-om-next

wilkerlucio18:07:59

@anmonteiro: I created this gist to make easier once you want to try to reproduce, so you can check if you see the same results as I do: https://gist.github.com/wilkerlucio/8d0e129eb714a530ecf56cddb7841169