Fork me on GitHub
#clojurescript
<
2019-05-03
>
heefoo07:05:04

what is the idiomatic way to create custom eventypes/dispatcher in clojurescript ? I follow this pattern https://stackoverflow.com/questions/9088165/creating-events-with-google-closure but i sense there is place for deftype/protocol/reify here, althought i do not grasp the conspects clear

padraic10:05:23

Hey guys, fairly new to clojure(script), did use it 2-3 years ago for a spell so not entirely a beginner. Just wondering about the up-to-date conventions in 2019 that people are using to build web apps?

kszabo10:05:17

hey, I think http://book.fulcrologic.com/ + shadow-cljs is the way to go nowadays. It works amazingly well for us

damien11:05:02

Hi all 👋 . Looking for some prior art: Has anyone built a CLI with subcommands (e.g. like you would with commander) in cljs? My use case is building something like this and then packaging with nexe for static binary deployment to macOS/Linux/Windows.

rap1ds12:05:53

Hi @damienstanton We're soon about to start a project to build a CLI with subcommands. We have built a quick proof-of-concept and done some initial technical design. We built the proof-of-concept with tools.cli, Chalk, Inquirer and shadow-cljs and planning to use that stack for the real thing

👍 4
restenb13:05:40

anybody aware of a good "walkthrough" of clojurescripts dependence on goog? recently my production build started crashing on page load due to `Uncaught ReferenceError: goog is not defined at app.js:1`

thheller13:05:37

@restenba production build should have no references to goog left

restenb13:05:48

hm. does it have anything to do with :optimizations? i set them back to :none on the production build in order to see error messages, but the error persists with :advanced as well

thheller13:05:55

yes :optimizations controls that and :advanced should not contain goog

thheller13:05:08

:none is not a production build 😉

restenb13:05:12

well no, but javascript errors are not human readable anymore with :advanced

thheller13:05:49

typically compiling with :pseudo-names true provides some clues

thheller13:05:55

or switch to :optimizations :simple

restenb15:05:01

well, that got rid of the goog error. build still broken though, for whatever weird reason the deployed cljsbuild has decided to start having a problem with a specific library, despite there not being any version updates to that or the build itself lately

restenb16:05:11

Wow, this must be the weirdest issue I've had. Some old library starting generating errors in the production build. Nothing I did got rid of it - not updating it's version, or other dependencies, or the build tools, compiler settings, nothing. In the end I had to get rid of it and just rewrite that portion of the code without using that library

restenb16:05:14

Wasn't an obscure library either, https://clojars.org/mount

Steven Katz18:05:09

Is anyone using figmain integrated with cursive? I folowed the instructions here: https://github.com/bhauman/figwheel-main/blob/master/docs/docs/cursive.md But see this when the repl starts:

May 03, 2019 1:59:46 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
Unable to detect a system Terminal, you must not launch the Rebel readline
from an intermediate process.
If you are using `lein` you may need to use `lein trampoline`."
Is this normal?

mfikes18:05:45

@steven.katz It might be worth trying setting the REPL to be of clojure.main type instead of nREPL (assuming you have it at the nREPL default)

mfikes18:05:06

(This is in the Cursive REPL configuration dialog.)

Steven Katz18:05:08

thats what I am chosing

Steven Katz18:05:26

If I choose nREPL it does not work at all (wont take input)

mikerod19:05:37

I’ve been surprised by the behavior of doing an clojure.core/eval at macroexpansion-time in cljs. I made a small gist example to demonstrate. I’m curious if anyone could enlighten me to what is happening? I’m guessing that defs are not actually updating the state of the CLJ-ns that the macros are being expanded in. Is there any safe way to do an “eval” sort of op during macroexpansion in CLJS? In the example I just have a symbol, but I’m curious about arbitrary types of forms that have symbols to resolve as well. https://gist.github.com/mrrodriguez/dc48281196f99e30ee84c56c0ec6f63a#file-foo-cljs

dnolen19:05:38

@mikerod I think you probably just have the wrong expectations

dnolen19:05:39

clojure.core/eval is exactly that

dnolen19:05:52

has nothing to do with ClojureScript, doesn't know anything about ClojureScript

dnolen19:05:23

if you need it, expect to do a lot of work

mikerod19:05:38

@dnolen sure, I know it’s a stretch, but was curious if there are anyways to try to “do things” during macroexpansion that may involve eval-like behavior

dnolen19:05:54

there isn't

dnolen19:05:00

it's just Clojure eval

mikerod19:05:10

and I was at least a little surprised that the clj ns doesn’t have any def into it, I guess that is just all managed via the cljs compilation state instead

dnolen19:05:15

there's no way to magically make it know about ClojureScript stuff

dnolen19:05:28

it doesn't know about nses, vars, nothing

mikerod19:05:28

I know it isn’t cljs at all - wondering if cljs has any alternative way

dnolen19:05:44

Clojure eval is meaningless

dnolen19:05:00

you can do some weird things - but again not recommended

mikerod19:05:27

it’s like if I want a macro to use in cljs, and the macro receives a symbol - I want to resolve it, do something with it during expansion prior to emitting the forms from the macro

mikerod19:05:45

if it’s “just symbols” I guess I can just use some symbol resolve stuff from the cljs.analyzer

dnolen19:05:12

yes if you just need resolve then resolve

mikerod19:05:36

Yeah, this eval thing seems to have magically worked out in some cases I had before - I thought it looked like a bad idea, but then couldn’t figure out how it ever worked. I tried to simplify it down and it seems like it shouldn’t work

dnolen19:05:49

trying to make eval work is a losing battle

mikerod19:05:52

(as in, I didn’t write it, just discovered it)

dnolen19:05:59

if anything worked it was probably simple and you got lucky

mikerod19:05:08

apparently

mikerod19:05:33

thanks for the input though. at least I can now be sure it’s a bad idea

dnolen19:05:10

yeah trying to make it do something useful would make my brain hurt

mikerod19:05:55

Yep. I could see that.

pyr20:05:54

Hi! In Clojure I rely on namespaced keywords a lot and in some cases use plain JSON for serialization. cheshire handles this well both ways. In clojurescript the ingress path works well (js->clj (.parse js/JSON some-string) :keywordize-keys true) has the same behavior

pyr20:05:52

For egress, clj->js removes namespace info (since the output is a JS object it makes sense)

pyr20:05:18

is there a way to go directly to JSON and preserve that info or will I be forced to pull in transit?

jeaye20:05:48

cljs.user=> (defn transform-keys
                #_=>   [m key-fn]
                #_=>   (walk/postwalk (fn [item]
                #_=>                    (if (map? item)
                #_=>                      (zipmap (mapv key-fn (keys item)) (vals item))
                #_=>                      item))
                #_=>                  m))
#'cljs.user/transform-keys
cljs.user=> (transform-keys {::foo 1} name)
{"foo" 1}
cljs.user=> (transform-keys {::foo 1} str)
{":cljs.user/foo" 1}

jeaye20:05:05

@pyr Transforming all of these keys to strings first allows them to go to JSON without a hitch. You'll then just need to transform them back on the way in, using (transform-keys data keyword).

jeaye20:05:37

With CLJS 1.10.439, I should be able to add a dep like :npm-deps {"@sentry/browser" "5.1.0"}, use :install-deps true, add :infer-externs true, and require the dep like (ns foo.bar (:require ["@sentry/browser"])), right? This all compiles, but I see Undefined nameToPath for module$home$jeaye$projects$foo$node_modules$$sentry$browser$node_modules$$sentry$core$esm$integrations when executing.

dnolen20:05:57

@jeaye :npm-deps for X dep may or may not work, that's always been true

jeaye20:05:27

@dnolen That's ok. I just want to be sure the steps I've take are correct so that I can know it's the dep and not me.

jeaye20:05:54

I can fall back to cljsjs for this dep.

dnolen20:05:01

@jeaye it was definitely the case that scoped deps had issues

dnolen20:05:06

because of Closure Compiler

dnolen20:05:26

might be worth a try with the latest ClojureScript, I believe we have a newer GCC dep

jeaye20:05:28

Got it. Thanks, David.

dnolen20:05:38

@pyr see the clj->js docstring

dnolen20:05:46

:keyword-fn is a thing

dnolen20:05:26

@jeaye I recall at least a couple of reports that scoped deps started working again

jeaye20:05:40

@dnolen Same error with 1.10.520 for me. Will go to cljsjs for this one.

jeaye20:05:53

Thanks again.