This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-19
Channels
- # bangalore-clj (35)
- # beginners (42)
- # boot (89)
- # cider (9)
- # clara (2)
- # cljs-dev (29)
- # cljsjs (3)
- # cljsrn (14)
- # clojars (9)
- # clojure (332)
- # clojure-brasil (1)
- # clojure-dev (5)
- # clojure-italy (4)
- # clojure-russia (36)
- # clojure-spec (38)
- # clojure-uk (65)
- # clojurescript (114)
- # clr (11)
- # community-development (105)
- # core-async (10)
- # cursive (4)
- # datascript (1)
- # datomic (58)
- # defnpodcast (3)
- # emacs (4)
- # hoplon (7)
- # juxt (3)
- # keechma (8)
- # off-topic (7)
- # om (109)
- # om-next (8)
- # onyx (26)
- # pedestal (3)
- # planck (8)
- # re-frame (76)
- # reagent (28)
- # rum (25)
- # spacemacs (2)
- # specter (35)
- # untangled (31)
- # yada (27)
@anmonteiro just watched your talk at full stack fest, great job 🙂
(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@anmonteiro Ah, perfect! Cheers.
@jasonjckn: try to use displayName
instead of name
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);
@hlolli probably a bug, mind sharing a minimal repro?
yes, I post asap on github. Added: Done https://github.com/omcljs/om/issues/776
@hlolli just read your issue. your second example is just plain wrong and you should expect the error to happen
the first one could probably be a bug
oh actually, both are wrong
so not an issue
you’re stealing another component’s query
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’s om/IQueryParams
?
@anmonteiro I've never had problem with two components having the same query, but that is wrong?
@hlolli the problem is that queries must compose. you’re not composing, but stealing
example of composing:
(defui A
static om/IQuery
(query [this]
[:foo]))
(defui B
static om/IQuery
(query [this]
[{:bar (om/get-query A)}]))
^ notice that B is “above” A in the tree
if you steal queries there’s no way to know which is which
so if I manually write two exact queries for two seperate component, there would be no way to know which is which?
@hlolli you need to clarify what you’re trying to do
queries must compose (recursively) in a way that your root component knows about every other query in the application
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.
@hlolli right, so there’s probably another thing here. Imagine this component tree:
A
/\
B C
B and C can have the same query, as long as A knows about them
is that what you’re trying to achieve?
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.
so you’re probably doing it the wrong way
you can definitely set the query for your root component, but it needs to compose
e.g.: this is not valid
(defui A
static om/IQuery
(query [this]
[:foo]))
(defui B
static om/IQuery
(query [this]
[:foo]))
but this is:
(defui A
static om/IQuery
(query [this]
[:foo]))
(defui B
static om/IQuery
(query [this]
[{:bar (om/get-query A)}]))
component B will query for [{:bar [:foo]}]
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).
definitely a non-issue
Om's codebase has a dom.cljs
and a dom.cljc
next to each other. Is that supposed to be able to work?
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.
@peeja upgrade to ClojureScript 1.9.229
hrm, maybe you need to add an :exclusion
to figwheel?
No, I have the right version of ClojureScript, it's the file reloading that it doesn't know how to do
that problem should have been addressed by https://github.com/clojure/clojurescript/commit/ce6c657a751cce5fb1b8e94eb97e74944c0d7fa6
ahh, the file reloading
hrm, I don’t know about that
the commit I pasted above solves the compilation part
In any case, it sounds like it's either a figwheel bug or I'm getting the wrong versions of things
@peeja it’s so that Bootstrapped ClojureScript can consume the macros file
@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
(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])
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.
@peeja where is it coming from?
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
.
it happens when you click OrgListItem
?
getting computed props?
doesn’t make a lot of sense
do you mean the error happens in line 11 of your snippet above?
there’s the onClick
on OrgListItem
oh. it’s the set-query!
call
I didn’t get it at first
The query-template
call is from here: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1746
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
.
@peeja agreed it feels like a bug in query-template
as I said yesterday or the day before, links in queries just haven’t been battle-tested
glad you’re doing it now 🙂
the problem is we’re using identical?
to potentially compare vectors 🙂
also, expr->key
just seems wrong to me
since we allow links in queries
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.
it doesn’t become the link for me 😛
or does it
ah that’s right, because node
is the join map
so expr->key
is actually right
the problem is just the equality check there
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?
@liamd only the static
part is specific to Om
the rest is what you would commonly do in defrecord
or deftype
minus the argument vector part
@anmonteiro Got another one 🙂 https://github.com/omcljs/om/issues/779
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?
i’m 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’m still wrapping my head around om/next’s declarative query stuff
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.
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
any way to make it less noisy, I would just like the read-key to be logged without it's subquery included
@jasonjckn you can disable logging e.g. by passing :logger nil
to the reconciler