This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-11
Channels
- # admin-announcements (10)
- # arachne (2)
- # beginners (74)
- # boot (302)
- # cider (49)
- # cljs-dev (11)
- # cljs-edn (7)
- # cljsjs (13)
- # cljsrn (1)
- # clojure (164)
- # clojure-austin (1)
- # clojure-brasil (3)
- # clojure-finland (2)
- # clojure-greece (4)
- # clojure-russia (48)
- # clojure-uk (11)
- # clojurescript (138)
- # community-development (1)
- # cursive (13)
- # datascript (1)
- # datomic (19)
- # emacs (4)
- # events (1)
- # garden (1)
- # hoplon (123)
- # jobs-discuss (9)
- # keechma (5)
- # lein-figwheel (4)
- # leiningen (2)
- # luminus (15)
- # mount (1)
- # off-topic (8)
- # om (66)
- # on (1)
- # onyx (28)
- # other-languages (2)
- # planck (1)
- # proton (5)
- # re-frame (18)
- # reagent (15)
- # untangled (15)
That one looks good as well. I just havent seen any good examples of how to use normal react components and tie them into local state.
Are there any tricks to get om.next to compile with advanced compilation?
@mitchelkuijpers: what are the problems do you have ?
I get a pretty cryptic error, not sure if om.next is the problem
clojure.lang.ExceptionInfo: java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;
data: {:file
"/var/folders/fw/q25l3njx6p55bywxj5x_c8gc0000gn/T/boot.user2640523315019357413.clj",
:line 53}
java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;
java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;
com.google.javascript.jscomp.parsing.JsDocInfoParser.validTemplateTypeName JsDocInfoParser.java: 1216
com.google.javascript.jscomp.parsing.JsDocInfoParser.parseAnnotation JsDocInfoParser.java: 946
com.google.javascript.jscomp.parsing.JsDocInfoParser.parseHelperLoop JsDocInfoParser.java: 283
com.google.javascript.jscomp.parsing.JsDocInfoParser.parse JsDocInfoParser.java: 273
com.google.javascript.jscomp.parsing.IRFactory.createJsDocInfoParser IRFactory.java: 889
com.google.javascript.jscomp.parsing.IRFactory.handleJsDoc IRFactory.java: 656
com.google.javascript.jscomp.parsing.IRFactory.handleJsDoc IRFactory.java: 670
com.google.javascript.jscomp.parsing.IRFactory.transform IRFactory.java: 733
com.google.javascript.jscomp.parsing.IRFactory.access$300 IRFactory.java: 163
com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.processAstRoot IRFactory.java: 1013
com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.process IRFactory.java: 2591
com.google.javascript.jscomp.parsing.IRFactory.justTransform IRFactory.java: 931
com.google.javascript.jscomp.parsing.IRFactory.transformTree IRFactory.java: 339
com.google.javascript.jscomp.parsing.ParserRunner.parse ParserRunner.java: 117
com.google.javascript.jscomp.JsAst.parse JsAst.java: 89
com.google.javascript.jscomp.JsAst.getAstRoot JsAst.java: 50
com.google.javascript.jscomp.CompilerInput.getAstRoot CompilerInput.java: 121
com.google.javascript.jscomp.Compiler.parseInputs Compiler.java: 1330
com.google.javascript.jscomp.Compiler.parse Compiler.java: 719
com.google.javascript.jscomp.Compiler.compileInternal Compiler.java: 680
com.google.javascript.jscomp.Compiler.access$000 Compiler.java: 83
com.google.javascript.jscomp.Compiler$2.call Compiler.java: 651
com.google.javascript.jscomp.Compiler$2.call Compiler.java: 648
com.google.javascript.jscomp.CompilerExecutor$2.call CompilerExecutor.java: 93
in advanced mode, it would be a bit troublesome with externs, check the compiling output .
can you cat this file at line 53 /var/folders/fw/q25l3njx6p55bywxj5x_c8gc0000gn/T/boot.user2640523315019357413.clj
41 (set-env!
42 :repositories
43 #(into
44 %
45 [["datomic"
46 {:url "",
47 :username (System/getenv "DATOMIC_REPO_USERNAME"),
48 :password (System/getenv "DATOMIC_REPO_PASSWORD")}]
49 ["avisi-releases"
50 {:url
51 "",
52 :username (System/getenv "AVISI_RELEASE_USERNAME"),
53 :password (System/getenv "AVISI_RELEASE_PASSWORD"),
54 :snapshots false}]])
55 :source-paths
56 #{"test/clj" "test/cljs" "src/cljs" "src/cljc" "src/devcards"
57 "src/clj" "src/public”}
I am not sure this is related ill investigate some more but this should not be the problem, the error line number seems random
Hmm I think i get the wrong version of guava
that would explain the error
I just did a quick search, it does show something regarding guava as well, so it might not have any problem with cljs yet
Thank you for the help @nxqd it seems to be resolved I only get some warnings now but I think those are expected
hey guys. we decided to give Om-Next a try. I am trying to think about one idea that worked with angular in my past projects. Namely I need to have “runtime injectable” components. Imagine you grab component’s code from api, and render it on the fly. Is something like that achievable? Can someone point me in the right direction/give advice/links to examples, blogposts etc.
so in the project I mentioned it would get list of “modules” from DB and then the actual code of each “module” was in our private bower repo, it would just use the code and styles and other assets for every listed/enabled module from there and render them “on the fly"
@ag: Are we assuming your modules are also written in Clojurescript?
Unfortunately, I can’t think of any pre-baked solutions, but I suspect CLJS code splitting is a beginning to the answer: https://rasterize.io/blog/cljs-dynamic-module-loading.html
Problem with that link is your full list of modules are required at compilation time. Not sure if there’s a workaround for that.
what if instead of thinking about this problem from Om/CLJS perspective, dig it from React side? Is it possible to have compiled JS code of a component to be “injected”?
Another great question Not sure, personally, however it seems like something that could be experimented with. Om works with traditional React components quite nicely, as evidenced by the CLJSJS project (http://cljsjs.github.io/).
How can I use update-state! in om.core to merge results into an existing vector without losing what is already there.
So I have the following which sets local state of a component:
(defn test-ajax [state owner input]
(go
(let [access-token (get-in state state/user-access-token-path)
api-result (<! (ajax/managed-ajax
:get
(api-url (str "/api/v3/users?per_page=50&search=" input))
:headers {"Authorization" (str "Bearer " access-token)}))]
(om/set-state! owner :options (:resp api-result)))))
hey all, does anyone here have a ref implementation of using different markup libs like hiccup inside of om/om.next?
@sbmitchell: you can use sablono, which is pretty much just a drop-in
I guess I should clarify that Im coming from a heavy use of reagent and just wanted to see if others who came from the same background tried going the hiccup route first
if its just the case that most ppl with the same background just switch to sablono thats valid I'm just curious
@sbmitchell: well hiccup doesn’t work with ClojureScript so Sablono would be the way to go (with Om)
I see I guess the hiccup I am use too is an extension from reagent
@sbmitchell: you probably mean “hiccup-like syntax”
yes hiccup like
if so, that’s what sablono is all about
I don’t know any others in the same space
oh ok great thanks
looking at it now...looks to be what I was expecting
I need some help understanding om design pattern: If I have a defui TodoList, which has the query expressions [:todo/list], and there's 2 instances of TodoList, in the implementation of the read function for handling :todo/list, how do I figure know which instance the read is coming from?
@jasonjckn: probably need more context regarding your app’s query shape
typically you wouldn’t have repeated keys like that?
well, i'm thinking along the lines of building up an arsenal of reusable defuis in a library that I include
so let's say I wrote TodoList defui 5 years ago, and the query expression for that in this library is todo/list
well normally reusable components don’t quite have queries
Oh ok, so this hypothetical library wouldn't have query expressions defined, just the render function, but the render function would assume things about the query expression wouldn't it
which probably don’t need to be in queries if the components are to be made reusable
let me look up a few examples
this repo has 2 reusable components
they don’t have queries, but they assume certain things are in props
@anmonteiro thanks, so let's say I have a reusable component which is 5-star rating widget, it shows the average rating, when the user clicks on one of the stars, it contributes to the overall average rating, so clearly I can easily encapsulate the rendering of this into a library as how om-mantras does this, but there's also state logic around when users click on a star, that it updates the local state, with 1 more rating to contribute to the overall average rating. So it's fair to say that there's no way to reuse this state logic in om-next really, because this would mean adding a query expression which specializes the component too much to a specific kind of application
it would also mean calling transact! for when the user clicks on one of the 5 stars in this hypothetical library which om-mantras doesn't do
@jasonjckn: the component can also accept a function as a prop
this function (which the component knows nothing about) is responsible for updating the overall thing
and the rating component calls it whenever a star is clicked