This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-04
Channels
- # architecture (27)
- # bangalore-clj (4)
- # beginners (22)
- # boot (35)
- # cider (26)
- # cljs-dev (2)
- # cljsrn (3)
- # clojure (156)
- # clojure-austria (3)
- # clojure-dev (9)
- # clojure-italy (25)
- # clojure-nl (10)
- # clojure-poland (5)
- # clojure-sanfrancisco (1)
- # clojure-spec (6)
- # clojure-uk (64)
- # clojurescript (169)
- # core-async (13)
- # cursive (13)
- # datomic (63)
- # dirac (50)
- # duct (21)
- # editors (1)
- # emacs (6)
- # events (1)
- # fulcro (1)
- # java (22)
- # keechma (14)
- # leiningen (2)
- # luminus (4)
- # off-topic (23)
- # onyx (4)
- # parinfer (5)
- # pedestal (4)
- # re-frame (6)
- # reagent (4)
- # ring-swagger (7)
- # rum (4)
- # shadow-cljs (84)
- # specter (5)
- # sql (36)
- # tools-deps (76)
- # uncomplicate (3)
- # yada (4)
Does anyone use that lib for a css preprocessing: https://github.com/roman01la/cljss ? What do you prefer? This one or garden?
Hi! My Reagent project page loading time(the period showing progress bar) is long, both because of large app.js
file and long react
init page time. I found that using async
script tag will not work. Are there any advices to decrease page loading time? Thanks very much.
@cmal <script async ...>
should work fine in the latest version? assuming you are still using shadow-cljs of course 😉
older versions had :devtools {:async-require true}
. in newer version it just detects if you are using script async
or not.
@thheller I used to use 2.1.16
and async tag does not work. There are a lot of warnings of document.write
s(in dev). In 2.1.16
release js script, there are no warnings but the page keeps going into errors. I will try to figure out whether this is a problem of my code. You say new version async
should work gives me a direction. Thanks so much.
release
builds should never do document.write
unless it is done in your code somewhere
ok that is most likely the problem then. its setup is possible in async but I forgot how. you have to create an input and iframe elements I think
So does this mean that if I do want to use async
with release
, I must deal with the goog.History
problem?
Yes, I exposes a global var someVar, and do something like someVar.init()
when window
's load
event was triggered. the function runs. but there are some weird errors which do not exist when not using async
tag.
Does this mean that if I do want to use async
with release
, I must deal with the goog.History
problem?
async
means that the browser continues loading your page and if you immediately after calll someVar.init()
that won't be loaded yet
goog.History
uses document.write
to create a few DOM elements which doesn't work in async
if you run shadow-cljs release app --debug
it should be easy to find out what fails exactly
I’m using https://github.com/r0man/cljs-http to access an API (Contentful). Cljs-http returns a channel, on which the results are returned.
What’s not so great, I think, is that I now have to wrap all subsequent functions that use the data (converting and processing it, and what-not) in go
blocks, and do (<! (func a1 … an))
instead of straight up calling those functions.
go
blocks become this contagion that spreads throughout the program, even where they are not strictly needed. I.e., functions now have go
blocks for the only reason that they happened to call another function that has a go
block. They are otherwise completely synchronous, and the benefit of core.async
is lost.
If I could wrap a whole section of the program in a go
block, the overhead wouldn’t be so bad. But since go
blocks terminate at function borders, they have to be stitched into every function separately, which creates the <!
ceremony for every function call.
One way to mitigate this would be to call as many “normal”, data processing functions as possible from within the function that deals with the returned data from cljs-http, as it already has a go
block.
Are there other ways to mitigate this?
@henrik what about https://github.com/JulianBirch/cljs-ajax/blob/master/README.md#getpostput and reference a function as the :handler
also keep in mind that you can still chain and actions together in small blocks and have that single block take a callback
Right. So, basically, what’s going to happen is: > 1. Get data from API > 2. Process data (through many functions) > 3. Stick the results in an atom, triggering rendering of a webpage So break out step 2 into normal functions, have them trigger on callback instead.
@chadhs Thanks! There’s nothing wrong with cljs-http
in itself, it’s a great library. I just need to learn how to manage core.async stuff properly.
yes its better to use core.async on the periphery to help with series of synchronous actions.
(defn card-from-image [img]
"Makes a card for the `img`"
(let [img_url (:url img)
link (str url "i/" img_url "." (:extension img))
page (reagent/atom 0)
state (reagent/atom false)]
(fn [img]
[ui/card
[ui/card-media
[:div
[:a {:href (str "#/home/")
:class "lightbox"
:id (str "/home/" img_url)}
[:img {:src link
:href link}]]
;;Thumbnail
[:a {:href (str "#/home/" img_url)}
[:img {:src link
:class "thumbnail"}]]]]
[ui/card-actions {:class "card-action"}
[ui/flat-button {:on-click #(copy-text link)
:icon (ic/content-link)
:label "link"
:class "card-button"}]]])))
@alice img_url
and link
are outside the function closure so if the img
changes, those won't be updated on re-render
@alice I can’t see what determines whether the lightbox is rendered or not. Do you change a class on some element?
If I get the lightbox to render now, clicking it again will get rid of it like it should
If it’s fairly static, and not too many of them, then flipping a visibility: hidden
CSS property is nice because you don’t have to re-render stuff.
I’m not sure why your code didn’t work. Though in general, I’ve noticed that you tend to get fewer problems by sticking stuff in a single global atom, and avoiding local atoms.
I’ve more or less switched permanently to https://github.com/Day8/re-frame, which has helped reduce weirdness quite a bit.
so there is Klipse, but is there something like <script language="clojurescript" ... /> where you could pretty much skip the CodeMirror and multiple languages support, bit still have some dependency resolution, so that you can have nice ClojureScript apps embedded in a small html wrapper?
@john92.walter [org.clojure/clojurescript “1.10.238”] but i was trying also with 1.9
i've run into this error by following the clojurescript getting started page in a random directory. clj will make an out
directory in cwd and this can cause issues
hmm lein new re-frame
create src/clj/foo/core.clj
and i have dev/user.clj
<- only this 2 clj files
@kwladyka sounds like you're able to reproduce it fairly easily... Any chance you could put together a simple repro?
ok, I will try do some random things and if it wouldn’t work I will push it. Just I don’t want consume your time too much 😉
No worries, if you've found a situation where the default quickstart is leaking into projects, I want to track it down.
hmm, seeing as how it's commented out, I don't see how that could be the culprit... it's possible though
https://github.com/kwladyka/cljs-hello-bug I hope i didn’t do something very stupid here 🙂
@kwladyka It may be worth moving your ~/.cljs
aside temporarily to see if it is affecting things
hmm.. yeah, I blasted target
and ~/.cljs
, hard reloaded the browser and it's working now
It could be a combo of figwheel and 1.10.238, perhaps not invalidating some compiled cache
Yeah, unless you want to chase it down in #fighweel. Otherwise we'd need a pure cljs repro.
@john I wonder if it is a browser cache issue. I was able to reproduce it as well and even though my connect.js
refers to my current project, in the browser it shows a connect.js
from my last project.
Looks like there's a lot of moving parts there with dirac and devtools and external-config.
yeah, and the reframe template may have been updated recently to accommodate the new external-config stuff... only chrome though...
I basically have a line 8 in
that looks like
if(cljs.core.truth_(rf1.core.mount_root)){
The rf1
is the bad bit, but it only appears after a change in the source and a reload occurs.
what do you mean? I have in the same time opened chrome and Safari. In one webbrowser i see errors while in Safari not…
If I shut down Figwheel in one project and then start it in another, and then fetch http://localhost:3449/js/compiled/out/figwheel/connect.js in the browser, I get the old project's copy. It seems to really just be a caching issue in the browser (Safari) as far as I can tell.
I mean I edited a the namespace and saved, let figwheel do a recompile, then did another chrome hard-reload and that error above disappeared, IIRC
I am following the 'modern cljs' tutorial and I am having this issue: https://gist.github.com/kuwze/160d4b2c6d463c53d34a6debc12441e4
hmm new ver. solves issue for me too. But still it is very crazy bug. How this can even read this from another project…
I have no clue how I am supposed to solve this issue if all I have to go on is "Stopping Jetty"
well it turns out I am an idiot, I had to read the tutorial again. I was supposed to run "boot wait -h" before.
@pesterhazy thank you
Hello everyone, would someone mind helping me sort our how to convert this javascript function to cljs?
@U0D4G0Q4U maybe you have an idea here?
I think something like this should work...
(defn promise-serial [fns]
(reduce
(fn [p f]
(.then p (fn [result]
(.then (f) #(conj result %)))))
(js/Promise.resolve [])
fns))
@U6GMQFAUT thanks, looks like that got me on the right track! I was having issues with the second .then
did you get it sorted out?
@U0D4G0Q4U yeah thanks
https://gist.github.com/joelnet/b286721a933e7e410120a8a2866dbcc8#file-promiseserial-js
I am trying to use clojure reduce instead of all the js interop
I could write a macro but I think I’m over thinking it