Fork me on GitHub
#om
<
2016-09-19
>
jasonjckn00:09:44

@anmonteiro just watched your talk at full stack fest, great job 馃檪

jasonjckn00:09:09

(defn class->name [clz]
  (->> (.-name (.-constructor (.-prototype clz)))
       (re-matches #"^.*[$]([^$]*)$")
       (last)))
I need this function to work simple/advanced optimized builds, but it only works with :none optimization

jasonjckn00:09:28

i takes a defui component as argument and returns it's name

peeja01:09:08

@anmonteiro Ah, perfect! Cheers.

anmonteiro10:09:25

@jasonjckn: try to use displayName instead of name

hlolli14:09:56

I thought this was once possible, using om/get-query! inside om/set-query!, but I get

Query violation, [object Object] reuses function components$front_page$FrontPage(){
var this__35286__auto__ = this;
React.Component.apply(this__35286__auto__,arguments);

anmonteiro14:09:23

@hlolli probably a bug, mind sharing a minimal repro?

hlolli14:09:12

yes, I post asap on github. Added: Done https://github.com/omcljs/om/issues/776

anmonteiro14:09:31

@hlolli just read your issue. your second example is just plain wrong and you should expect the error to happen

anmonteiro14:09:35

the first one could probably be a bug

anmonteiro14:09:17

oh actually, both are wrong

anmonteiro14:09:23

so not an issue

anmonteiro14:09:33

you鈥檙e stealing another component鈥檚 query

jfntn15:09:47

Are there any practical differences between a query that uses say [{:bar (om/get-query Foo)}] and one written with '[{:bar ?foo-query}] where the om/get-query call happens in the component鈥檚 om/IQueryParams?

hlolli15:09:21

@anmonteiro I've never had problem with two components having the same query, but that is wrong?

anmonteiro15:09:49

@hlolli the problem is that queries must compose. you鈥檙e not composing, but stealing

anmonteiro15:09:38

example of composing:

(defui A
  static om/IQuery
  (query [this]
    [:foo]))

(defui B
  static om/IQuery
  (query [this]
    [{:bar (om/get-query A)}]))

anmonteiro15:09:17

^ notice that B is 鈥渁bove鈥 A in the tree

anmonteiro15:09:42

if you steal queries there鈥檚 no way to know which is which

hlolli15:09:26

so if I manually write two exact queries for two seperate component, there would be no way to know which is which?

anmonteiro15:09:51

@hlolli you need to clarify what you鈥檙e trying to do

anmonteiro15:09:47

queries must compose (recursively) in a way that your root component knows about every other query in the application

hlolli15:09:26

I think I see why this is a problem, just asking more to clarify for myself. But what Im trying to do is basically resolve the vector and even conj other queries into it and tell the component that this vector is its queries.

anmonteiro15:09:45

@hlolli right, so there鈥檚 probably another thing here. Imagine this component tree:

A
   /\
  B  C

anmonteiro15:09:13

B and C can have the same query, as long as A knows about them

anmonteiro15:09:19

is that what you鈥檙e trying to achieve?

hlolli15:09:42

No, what I am trying to achive is some minimal routing. I want the root component to change its queries depending on what its children need. So that Im only reading from the app-state that the children need from the root component.

anmonteiro15:09:16

so you鈥檙e probably doing it the wrong way

anmonteiro15:09:40

you can definitely set the query for your root component, but it needs to compose

hlolli15:09:45

so if B needs some queries, I just resolve it and attatch the same query to A.

hlolli15:09:10

(and conj to some other keys that I need A to always see)..

anmonteiro15:09:11

e.g.: this is not valid

(defui A
  static om/IQuery
  (query [this]
    [:foo]))

(defui B
  static om/IQuery
  (query [this]
    [:foo]))

anmonteiro15:09:17

but this is:

(defui A
  static om/IQuery
  (query [this]
    [:foo]))

(defui B
  static om/IQuery
  (query [this]
    [{:bar (om/get-query A)}]))

hlolli15:09:44

so will component B query for :bar or :foo?

anmonteiro15:09:59

component B will query for [{:bar [:foo]}]

hlolli15:09:20

ok, easy to test out. I think you put me on the right track. So I guess we can close the issue (with or without comment).

anmonteiro15:09:54

definitely a non-issue

peeja16:09:33

Om's codebase has a dom.cljs and a dom.cljc next to each other. Is that supposed to be able to work?

peeja16:09:12

It breaks figwheel's build system, but I can't tell if that's a figwheel bug or something that's shouldn't have worked in the first place.

anmonteiro16:09:18

@peeja upgrade to ClojureScript 1.9.229

peeja16:09:43

I have, but figwheel still doesn't seem to like it

peeja16:09:51

Maybe my figwheel is still behind

anmonteiro16:09:11

hrm, maybe you need to add an :exclusion to figwheel?

peeja16:09:31

No, I have the right version of ClojureScript, it's the file reloading that it doesn't know how to do

peeja16:09:56

Oh, heh, maybe you're right 馃檪

anmonteiro16:09:57

ahh, the file reloading

anmonteiro16:09:12

hrm, I don鈥檛 know about that

anmonteiro16:09:27

the commit I pasted above solves the compilation part

peeja16:09:44

In any case, it sounds like it's either a figwheel bug or I'm getting the wrong versions of things

peeja16:09:07

What does it mean to have both files?

anmonteiro16:09:41

@peeja it鈥檚 so that Bootstrapped ClojureScript can consume the macros file

peeja16:09:12

Oh, huh. Interesting.

peeja17:09:58

@anmonteiro One more bug which I think is related to links. I'm hitting a Cannot read property 'call' of null coming out of query-template

peeja17:09:08

(om-next/query-template '[{:compassus.core/route-data
                           {:app/projects
                            [{[:app/current-user _]
                              [{:user/organizations [:organization/vcs-type :organization/name]}]}]}}]
                        '[:compassus.core/route-data :app/projects [:app/current-user _] :user/organizations])

peeja17:09:43

That's the call that causes it. I don't understand query-template's purpose well enough to understand if that's bad input or something it's failing to handle correctly.

anmonteiro17:09:57

@peeja where is it coming from?

peeja17:09:22

My expectation was that I could use the click handler to set-query! the :selected-org param, to get a different org to feed into org-projects.

anmonteiro17:09:01

it happens when you click OrgListItem?

anmonteiro17:09:12

getting computed props?

anmonteiro17:09:17

doesn鈥檛 make a lot of sense

peeja17:09:09

The computed props don't make sense?

anmonteiro17:09:19

do you mean the error happens in line 11 of your snippet above?

anmonteiro17:09:38

there鈥檚 the onClick on OrgListItem

anmonteiro17:09:57

oh. it鈥檚 the set-query! call

anmonteiro17:09:00

I didn鈥檛 get it at first

peeja17:09:08

Yeah. Sorry, it's a little twisty at the moment.

peeja17:09:51

query-template is just supposed to zip to the path in the given query, right? It feels to me like a bug in query-template.

anmonteiro17:09:52

@peeja agreed it feels like a bug in query-template

peeja17:09:56

Or path shouldn't have a link in it

anmonteiro17:09:11

as I said yesterday or the day before, links in queries just haven鈥檛 been battle-tested

peeja17:09:12

query-template explicitly uses expr->key

anmonteiro17:09:16

glad you鈥檙e doing it now 馃檪

peeja17:09:21

Happy to help 馃檪

anmonteiro17:09:32

the problem is we鈥檙e using identical? to potentially compare vectors 馃檪

peeja17:09:59

Oh, snap!

anmonteiro17:09:34

also, expr->key just seems wrong to me

anmonteiro17:09:41

since we allow links in queries

peeja17:09:06

It does seem weird, but it looks like k' does become [:app/current-user _], and I'm not sure why it's not :app/current-user instead.

peeja17:09:16

given that it's the result of expr->key

anmonteiro17:09:38

it doesn鈥檛 become the link for me 馃槢

anmonteiro17:09:01

ah that鈥檚 right, because node is the join map

anmonteiro17:09:17

so expr->key is actually right

anmonteiro17:09:27

the problem is just the equality check there

peeja17:09:32

Oh, got it. That makes sense.

liamd18:09:42

can anyone explain the syntax of the defui macro? particularly Object and static om/IQuery. is this clojure syntax or specific to om or to cljs?

anmonteiro18:09:11

@liamd only the static part is specific to Om

anmonteiro18:09:28

the rest is what you would commonly do in defrecord or deftype

anmonteiro18:09:35

minus the argument vector part

liamd18:09:30

ok makes sense

liamd20:09:04

reposting here: can i use my om/next components as functions and just pass them props for testing or do they need to be all hooked up with a reconciler and all that?

liamd20:09:04

i鈥檓 interested in the ideas in this blog post: https://juxt.pro/blog/posts/generative-ui-clojure-spec.html using spec to generate ui states with devcards. and i was wondering what the simplest way to make om eat all that generated data was. disclosure: i鈥檓 still wrapping my head around om/next鈥檚 declarative query stuff

peeja20:09:31

For most things where you don't need the state machinery of the reconciler, I think you should be able to just call factories from anywhere. I've used Om Next defui components from old Om as generic React components without issue.

liamd21:09:16

ah i see now in the quickstart doc you just do as you would expect like (mycomponent {:aprop 1}), for some reason i got all mixed up by the new stuff

jasonjckn22:09:21

transact! logs are kind of noisy when I include read keys

jasonjckn22:09:30

because it shows the the read query join's full subquery

jasonjckn22:09:45

any way to make it less noisy, I would just like the read-key to be logged without it's subquery included

jasonjckn22:09:01

or is there a way to disable transact! log entirely

anmonteiro22:09:53

@jasonjckn you can disable logging e.g. by passing :logger nil to the reconciler