This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-20
Channels
- # 100-days-of-code (2)
- # aleph (53)
- # architecture (2)
- # aws (3)
- # beginners (230)
- # boot (15)
- # calva (3)
- # cider (19)
- # cljs-dev (1)
- # clojure (139)
- # clojure-conj (3)
- # clojure-italy (47)
- # clojure-nl (19)
- # clojure-spec (26)
- # clojure-uk (98)
- # clojurescript (152)
- # clojutre (4)
- # core-async (22)
- # cursive (5)
- # datomic (48)
- # emacs (11)
- # events (1)
- # figwheel-main (219)
- # fulcro (15)
- # instaparse (3)
- # jobs (4)
- # jobs-rus (1)
- # leiningen (30)
- # luminus (8)
- # off-topic (67)
- # onyx (5)
- # pedestal (16)
- # re-frame (1)
- # reagent (4)
- # reitit (31)
- # ring (8)
- # ring-swagger (3)
- # shadow-cljs (115)
- # specter (4)
- # videos (1)
- # vim (20)
- # yada (15)
I'm interested in ClojureScript and electron... but I cannot seem to find an up to date template
Hi,
I am trying to integrate https://github.com/olahol/react-tagsinput
the library expects prop of type string
and checks for it
return typeof onChangeInput === 'function' && typeof inputValue === 'string'
but when I convert from cljs regular string is represented as function:
(js/console.log (type (clj->js ""))) => ƒ String() { [native code] }
please advice what I can do to have just string
?
thanks
@kirill.salykin a string is just a string. no need for any conversion trickery. how are you passing the value to the component?
(dom/create-element js/ReactTagsInput
(clj->js {:value tags
:onChange onChange
:inputValue "" #_inputValue
:onChangeInput onChangeInput
:addKeys [9 13 32] ;; tab, enter, space
:className "react-tagsinput form-control"
:tagProps {:className "react-tagsinput-tag label label-default"
:classNameRemove "react-tagsinput-remove"}
:inputProps {:placeholder placeholder}}))
this is fulcro btw
thanks so you think it is not in typeof check?
typeof "" === typeof String
false
right, but (clj->js “”) returs f String
not ‘string’
i am not calling what?
what is your actual problem? you are probably looking at the wrong place if you think a string is not a string because that is extremely unlikely
js/console.log (type (clj->js ""))) => ƒ String() { [native code] }
this is not a string, right?
(let [props
(clj->js {:value tags
:onChange onChange
:inputValue "" #_inputValue
:onChangeInput onChangeInput
:addKeys [9 13 32] ;; tab, enter, space
:className "react-tagsinput form-control"
:tagProps {:className "react-tagsinput-tag label label-default"
:classNameRemove "react-tagsinput-remove"}
:inputProps {:placeholder placeholder}})]
(js/console.log "props" props)
(dom/create-element js/ReactTagsInput props))
inputValue: ""
return typeof onChangeInput === 'function' && typeof inputValue === 'string'
function
ƒ Function() { [native code] }
it is also not function
k, is it possible to override that function to always return true from cljs?
> that is again type
. type
does not do typeof
.
how I can invoke typeof
?
thanks
seems you are right
thanks, will debug further
@thheller problem solved, of course it was my code
thanks!
why (js/goog.typeOf thing)
rather than (goog/typeOf thing)
?
or is this a case of the good old Doesn't Matter ^^ @thheller
@pesterhazy If it's your preference to set your ns
form properly for goog
, this was relatively recently sorted: https://dev.clojure.org/jira/browse/CLJS-1677
Nice, that would remove linter warnings @mfikes. Love the attention to detail
Hello, I'm stuck again. I would like to build a SPA using cljsjs/material-ui
. But how do I use (or create) components like a Button for example?
I have put the dependency into my deps.edn and I have required cljsjs.material-ui
. But I have no clue how to put any material-ui component into my hiccup... 😞
@witek https://github.com/reagent-project/reagent/blob/master/doc/examples/material-ui.md
Is there a google closure way to set value in a nested object ? As far as i understand aset is outdated but for nested objects i am not able to use goog.object/set, i have to resort to set!/aset
@hee-foo You can do a nested goog.object/get
to retrieve the object and then do a goog.object/set
on it
@hee-foo There is oset!
in https://github.com/binaryage/cljs-oops
@mfikes I am aware, but i am also upgrading the codebase, i want to avoid another dependensy
FYI, goog.closure does come with a nested getter helper, .getValueByKeys
https://github.com/google/closure-library/blob/master/closure/goog/object/object.js#L271
Looks like someone working on Closure was a fan of Clojure?
Yeah, "Think of goog.object/getValueByKeys
as the JavaScript analog of get-in
." (http://blog.fikesfarm.com/posts/2017-11-09-avoid-converting-javascript-objects.html)
So, with re-frame events being modeled after domain concepts. Does anyone here have any opinion on whether events should represent an intention to do something or a statement that something has already happened?
For instance, :user/load-address
(statement of intention) vs :user/address-loaded
(statement of record)
does either one of those strike anyone as a pattern to be avoided or a pattern to favor?
I had been doing the latter, but I'm starting to think maybe I should favor the former...
huh. yeah I guess so. I guess they're kind of like different tiers of event. intentions should have side effects and records should only dispatch intentions
I think that usually you wouldn't really have an :user/load-address
event, though. you might have a :user/view-profile
event that then triggers the fetching and resolves with :user/address-loaded
see, so in that case you are thinking of it in terms of record. user/view-profile is something that happened the user clicked a button to bring up their profile page
but it weird in cases where other things that can happen that trigger fetching of the user profile, like, I don't know....... comparing your friends list to someone elses, or something
so its more like a record -- user-clicked-the-profile-button
, and an intention - fetch-profile
what is the best practice for instrumenting in debug mode an app?
I was doing (when ^debug goog.DEBUG (stest/instrument))
in my main namespace after all the requires but the means requiring spec.test in that namespace also in production
which we don't want ton't we?
oh maybe I have another idea
(ns your.debug-app (:require [spec.stuff :as x] [your.actual-app :as app])) (defn main [] (x/instrument) (app/main))
I actually I am requiring the spec namespace in the preload
and using a fully qualified symbol in the main
was thinking of abusing shadow-cljs
better reader conditionals but got away with that 😄
thanks Thomas 😄
@dnolen have you ever though about something like :postloads
? because instrumentation should always happen after all the namespaces have been required by the app
so I'm trying to follow https://github.com/magomimmo/modern-cljs but I get a NPE when I try to connect the REPL. am I using bad versions of something? Clojure version 1.8.0, Boot 2.8.2, and importing:
:dependencies '[[org.clojure/clojure "1.8.0"]
[org.clojure/clojurescript "1.10.339"]
[adzerk/boot-cljs "1.7.228-2"]
[pandeiro/boot-http "0.8.3"]
[org.clojure/tools.nrepl "0.2.12"]
[adzerk/boot-reload "0.5.2"]
[adzerk/boot-cljs-repl "0.3.3"]
[com.cemerick/piggieback "0.2.2-SNAPSHOT"]
;[cider/piggieback "0.3.9"]
[weasel "0.7.0"]
[org.clojars.magomimmo/domina "2.0.0-SNAPSHOT"]
[hiccups "0.3.0"]
[compojure "1.5.2"]
[org.clojars.magomimmo/shoreleave-remote-ring "0.3.3"]
[org.clojars.magomimmo/shoreleave-remote "0.3.1"]
[javax.servlet/javax.servlet-api "3.1.0"] ;; dev only
])
the error is Unhandled REPL handler exception processing message {:id 6fae686a-2f10-435d-bb11-b5772676e3a3, :op clone})
@richiardiandrea no, I don’t think we need any more stuff here
yeah that is what I am doing and this is what we had:
(ns ...)
(when ^boolean goog.DEBUG
(st/instrument))
(defn -main
...)
but if you put code between the instrument
and -main
, it won't be instrumented
so we now have:
(ns ...)
(defn -main
...)
(when ^boolean goog.DEBUG
(st/instrument))
which feels odd
one could wrap the entry point in another namespace like Thomas was suggesting above
but :postloads
would be definitely cleaner..
yeah I know I can, just exploring a cleaner alternative
maybe more productive: I'm looking for a current set of dependencies that will work for CLJS on Boot.
@richiardiandrea :postloads
is not useful since you can control when something is loaded by their requires. :preloads
is misnamed in that way. say your preload has a require for your main entry. that implies that the preload will be loaded after your main.
well I try not to require the main namespace in the preloads
but yeah that is another thing to be aware of
why not? I mean the goal of your preload seems to be to instrument the main namespace no?
@braden.shepherdson Have you checked the versions on those deps? Might want to bump them up to see if one of them is assuming an older lib.
I basically require the spec.test
in preloads
and then have:
in preload.cljs
(ns preload
(:require spec.fully))
(ns ...)
(defn -main
...)
(when ^boolean goog.DEBUG
(spec.fully/instrument))
also don't want to execute side effects in requiring the main in preload
that's why I am saying :postloads
would solve things for me, and I would not need to care about all this 😄
I don't understand the problem that :postloads
would solve here? why does the instrument call have to be in the main ns and not the preload
?
if you instrument in preload
you would have to require main in preload...which feels wrong to me...
why does it feel wrong to you? it is not wrong. it is exactly what you want and how you'd express it in code?
because :preload
should be used for dev tools to setup things right? not for apps
at least this is what I have always read here 😄
if app has mount
state and mount/start
, all your state will start in :preload
...which again does not feel right...maybe it's just me 😉
Any main side effect will be executed (I know you shouldn't have any in the first place)..
I have absolutely no idea what you mean. the only thing this code does is moving the instrument
call out of your main into the preload
Will try to come up with an example later, it is probably due to things we due here, but we have side effects on require
and those would be triggered in the preload call with your method
Lunch time now :)
load order without the preload spec.full
-> your.app
calling instrument at the bottom
You might be right, will double check
Yep true
In terms on ns, spec
-> preload
-> main
feels better than spec
-> main
-> preload
. But without real reasons really
Names are important, it will bite me in the back :)
@john I think I have pushed those forward, except that I'm using the classic nrepl (0.2.12) and not the new 0.4.0 with the new namespace. I don't know which namespace the other deps are expecting, though.
done. Successfully compiled build :raw to "target/raw/jib_out/js/jib.js" in 307.214 seconds.
😞