This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-12
Channels
- # aleph (1)
- # beginners (81)
- # boot (20)
- # cider (46)
- # cljs-dev (6)
- # cljsjs (6)
- # cljsrn (8)
- # clojars (2)
- # clojure (104)
- # clojure-berlin (3)
- # clojure-italy (4)
- # clojure-losangeles (2)
- # clojure-nl (16)
- # clojure-spec (16)
- # clojure-uk (28)
- # clojurescript (88)
- # core-logic (31)
- # cursive (8)
- # data-science (3)
- # datascript (1)
- # datomic (95)
- # docs (1)
- # emacs (6)
- # figwheel-main (24)
- # fulcro (106)
- # graphql (5)
- # hyperfiddle (2)
- # midje (2)
- # nrepl (1)
- # off-topic (14)
- # om-next (1)
- # parinfer (2)
- # pedestal (26)
- # portkey (2)
- # re-frame (11)
- # reagent (27)
- # ring (6)
- # rum (4)
- # shadow-cljs (33)
- # spacemacs (10)
- # specter (53)
- # tools-deps (17)
- # vim (31)
I want to pretty print a data structure into a div on my screen so I can check some values I'm playing with in figwheel. The problem is the linebreaks and spacing isn't being preserved.
If pre doesn't work try textarea
Oh wait, nvm, textarea
is the trick for displaying text in a block you can Select All with and not get the entire page... carry on...
Yeah, it was real useful in an Electron app I built to generate a weekly email report I had to send in. Just select-all, copy, paste into email, send.
Might help to set a monospaced font style too
As newer versions of Ecmascript become widely adopted what are the implications for Clojurescript, particularly with JS library interop?
If a JS lib is written in ES6 and makes heavy use of generator functions will it be usable from Clojurescript?
@U0CLQ83LZ It's a bit speculative, but as Google's Closure compiler matures, we'll probably pick up some capabilities automatically. Some newer JS idioms around generators may never be brought into core - some might be. I doubt you'll see cljs.core chasing the latest JS features. Like, if some lib requires that you yield
on something, I'm not sure if CLJS will ever integrate JS's async functions directly, so interop with that lib might be non-trivial. But if it's something you really need, you can always use the js*
escape hatch. And if Closure eventually supports it, somebody could make a lib for it.
So Clojurescript is basically bound to Google Closure’s capabilities? Do you think that’s healthy in the log run?
There are clojure-like lisps that run on javascript that aren't tied to GoogClosure. If really didn't like Closure, I might consider using one of those. But since the compiler does such of a good job eliminating dead code, what we don't use doesn't really get in the way...
As far as health of GoogClosure in the long run, I guess we could fork it if that ever became a problem. It's used pretty heavily inside google though, last I heard.
and again, GoogClosure doesn't necessarily prevent us from leveraging newer JS features. You just have to call out directly, perhaps using js*
. The issue with introducing a new "async-fn" type in CLJS is that it'd probably seem like a significant divergence from Clojure-proper semantics
It would be preferable to wrap those newer functionalities in more clojure-like idioms, if possible. Otherwise, it'll probably just be left to library authors to wrap newer js features up in interesting libraries.
I made a lib from cljsjs
process that has the name antd-mobile
, I imported it to my project, I´m seeing it in js/window
but when I try to use it, it says that Uncaught ReferenceError: antd_mobile is not defined
@fabrao antd-mobile
is not a valid JS variable name since it treats -
as "minus" (ie. antd - mobile
). The CLJS compiler by convention converts all dashes to underscores so you'd be much better off just created antd_mobile
in your cljsjs
package.
The aget call should work though
but js/window
is not an array so if anything you should be using (goog.object/get js/window "antd-mobile")
@thheller Arrays in js are objects. Is there a special reason not to use either when accessing arrays/objects, apart from semantics ?
Is there a resonable (repl-able) way to use cljs in an existing nodejs project? That is, the cljs part would be just a "module".
Hello guys! Can you help-me? I'm not succeding at changing a value inside an atom.. Given this atom:
(def app-state (r/atom {:available {"Default" [["/a/foo/path/" 1]]}
:selected "Default"}))
I'm trying to change the string "/a/foo/path" using swap!
and update-in
, but I could find the right way...yes.. i did, but I got this error: "TypeError: f.call is not a funciton
(swap! app-state update-in [:available "Default" 0 0] "/a/new/path")
if you just want to replace it you can pass in (constantly "/a/new/path")
or #(do "/a/new/path")
yes..
it works
@gleisonsilva depending on what you're doing, assoc-in
is probably just what you want
(swap! app-state assoc-in [:available "Default" 0 0] "/a/new/path")
how do people feel about using macros to do side effects, e.g. load files, make network requests, at compile time?
I'm thinking about things like loading a .edn file into .cljs file, or validating a query against a schema
I'm takeing the dust off re-frame after a long time, but this is more of an async/await question. Which I probably need when useing fetch like this
(rf/reg-event-db
:home-fetch-slides
(fn [db _]
(let [res (-> (js/fetch (str ENDPOINT "/home") #js {:method "POST"})
(.then (fn [resp] (.json resp)))
(.then (fn [json] (parse-transit json))))]
db)))
I'd need res
to be a value, to evenutally merge it into db. Was there any support for async/await yet? Or am I missing some alternative solution when handling promises like that.no support for async/await and none planned - coverting a promise into a channel is a couple of lines at most
I guess the whole callback needs to be under a go
macro then? I can try, but I feel like the return value will end up being core.async data.
I don’t use callbacks in re-frame
async/await is not really relevant to this situation. the problem is that reg-event-db
expects a synchronous value
One effect handler dispatches the async call, and when the request comes back it just fires another event
yes, I know of http-fx. I've been in typescript last 6 months, and the fetch workflow somehow got trained into me.
really? how so?
I like core.async, so I'll give it a try, maybe I'm overthinking and it will work fine.
and this is also the way redux-thunk works, really good ideas there that cljs could borrow from.
Yeah, I wouldn’t call that a problem per-se, the http-fx library handles the callback stuff by dispatching an event
so maybe from reg-event-db
’s perspective it’s getting a synchronous event, but the event itself was dispatched when the ajax call returned
like I said I don’t know much about these libs - but putting an async call inside the state stuff like that seems code-smelly to me
@hlolli using core.async or async/await is neither here nor there - you won't be able to use it with reg-event-db
. you'll need to use effects, and at that point you're recreating http-fx
I don’t think it’s inside the state stuff — the effect dispatches the client -> server request, and then it’s done (as far as effect handling is concerned). There’s a mechanism under the hood that dispatches a new event when the response comes back, and the event handler does the actual state update.
@lilactown yes, I like experimenting. I guess I'll end up useing that. But the "not so good" about it, is that it's kinda anti-flow having cljs-ajax, XmlHttpRequest goog/ or js/ kind, and all sorts of http request interfaces. I feel like fetch is going to take over the js world, and it's pretty simple to use.
anyway, gotta run, which sux because I’m just getting interested in this convo
yes! haha, I would like to see re-frame-thunk middleware somewhere a la https://github.com/reduxjs/redux-thunk
This seems like a fair assessment of fetch https://medium.com/@shahata/why-i-wont-be-using-fetch-api-in-my-apps-6900e6c6fe78
I tend to agree - it’s not really giving you anything over higher level libs esp. those that manage JSON or Transit for you
the difference is that thunks are written imperatively, with callbacks, whereas effects are written declaratively with data
yup, spot on, need to get coffee. Thunks are side-effect based, providing dispatch as callback parameter. And that can get smelly.
@gleisonsilva If you're using constantly
or the #(do $result)
, assoc-in
is probably what you're looking for.
Whoops. I just got connection back. Disregard. 🙂