Hi guys. Anyone knows how can I export module for npm from clojurescript? I am writing npm module with cljs but got stucked…

does it help https://github.com/thheller/shadow-cljs/wiki/ClojureScript-for-node.js-libraries

@jiyinyiyong Thank you for information! 😭 I had no idea to search for build tools.(I was trying with lein-cljsbuild) After searching, I found same functionality in lein-figwheel. I will use it because I am more familier to it than shadow-cljs. FYI: https://github.com/bhauman/lein-figwheel/wiki/Node.js-development-with-figwheel#nodejs-module-development-with-figwheel

not bad. if you want to find more on shadow-cljs's side, try #shadow-cljs

Is there a modern consensus on how to handle logins and sessions with clojure/script?

Specifically, how can I make sure a login persists between browsers being connected and not ? I want to make things as uninterruptive (new words yay) as possible for someone revisiting.

Some ideas I had revolve around keeping a local hashed value and then transmitting it over the wire on new connect and de-hashing it, and verifying logins that way. Is that reasonably secure, or is there a better way?

@sova between browsers seems impossible, as there is no way to data at a location multiple browsers can access as far as I know. Of course you could retrieve a session after a login, so the only thing they have to do on another browser is to log in again. If all your state is in the back end, you can then just go on as before. I started my current project from https://github.com/nginx-clojure/nginx-clojure/tree/master/example-projects/clojure-web-example they use a shared map to store information in the session, but have hints to use redis so you could scale. And you need not to hook the old session to the new session when the same user logs in again. There might me better/easier solutions.

Hi everyone, I'm trying to configure a var at compile-time with "goog-define" but I receive the following warning:

WARNING: Use of undeclared Var job_name.core/goog-define at line 4 src/cljs/job_name/core.cljs

:closure-defines {job_name.core/foo "value"} 

@giorgio.porzio goog-define is a macro and can only be called statically

(goog-define foo "default value")

how are you calling it?

sorry I forgot to write it, I'm calling it in the same way as you did

which CLJS version are you on? might just be an old verison?

ok, it was a version problem. Thank you!

How do I call getAttributeNames on a dom node? This method cannot be found with advanced compilation

add exterms then

I think its not part of the standard yet do doesn’t have externs by default

https://github.com/google/closure-compiler/commit/0ae2a39e2ac50a857f5d02ef2ba4c1ca45609646

or upgrade 😉

Thanks

is is ok to use cljs.core.async instead of re-frame for a small application?

@bravilogy I've successfully used core.async with Om

(Om previous)

-- I had various channels in my app-state, and responded to messages with transact! Using core.async's pub-sub worked well for me

thanks, just what I wanted to know 🙂

what it did mean was that I passed all messaging channels through to views so they could construct UI event-handlers that dispatched messages, which lead to changes in app-state (no direct coupling - all event handlers send messages like {:click :my-button} - no direct state-mutation in handlers)

- that way you can associate other events with the same responses, like messages from the server, so you can drive the UI from server messages too

does anyone here use cljs-oops? if so, how do you work with javascript date objects? when i try (ocall (js/Date.) :getTime) i get Uncaught Oops, Unexpected object value (date-like)

@joshkh use normal cljs interop in case of dates, it is covered by default externs, more details https://github.com/binaryage/cljs-oops/issues/13#issuecomment-332560027

strings, dates and other standard javascript objects are guaranteed to have externs covering them (those externs are bundled with closure compiler)

here is the full list of diagnostics checks cljs-oops does in dev mode: https://github.com/binaryage/cljs-oops/blob/b8a2e8b3d8b9b2740e85ef7bcb0a1a4dc2b72276/src/lib/oops/codegen.clj#L46-L63

thanks @darwin . i didn't realise there were default externs bundled with the closure compiler 🙂

https://github.com/google/closure-compiler/tree/master/externs

thanks for the links/info

Hi, Is there a way to ensure/see if my externs file is being found by the closure compiler? It doesn't appear to be but I get no errors/info.

@mbutler maybe try to introduce a syntax error into your extern file? I believe closure compiler should spit some warning at least

this is one thing I don't like about externs btw. see what I wrote in point 4 here https://github.com/binaryage/cljs-oops#externs-from-hell

@darwin It would appear that my externs files is indeed not being read in/found 😞

Are there some good checks/obvious pitfalls?

I don't know, once I had to modify ClojureScript compiler with some verbose logging of what is being passed into closure compiler API as parameters, my problem was that a library I was dependent on had bundled externs but it didn't seem to work

Also sorry @darwin I lied, I threw in the syntax error in dev mode casually forgetting to turn advanced compilation on... At least i can now be confident that my file is being read and the problem is my inability to write externs 😄

However, it was working, all i did was move a few files around, I dont know if that is more scary 🙂

I’m getting an error compiling cljs: “No reader function for tag Inf” with the newest versions of cljs, what could be causing this? I looked in the file and it’s just to do with defining infinite number literals for js

make sure you're on the last version of cljs and tools.reader

it might be that you're using an incompatible version

“1.9.946” is the cljs version

is it expected to explicitly declare tools.reader dep?

i believe so

clojurescript itself, i mean

do a lein deps :tree | grep tools.reader and make sure you're getting version >=1.1.0

Thanks, making sure that was up to date fixed the issue.

could someone help me understand what i'm doing wrong with the recent code splitting / :modules compiler options updates? i set up a dummy project with the following advanced compilation configuration: https://github.com/joshkh/modules/blob/master/project.clj#L45 when i compile with lein cljsbuild once min i get the following error:

------ Figwheel Configuration Error ------

Missing required key :entries at path (:cljsbuild :builds 1 :compiler :modules :cljs-base)

  {:cljsbuild
   {:builds
    [{:compiler
      {:modules
       {:cljs-base
        {:output-to "resources/public/js/compiled/app.js"
         :entries ...
         ^---- The required key :entries is missing
         }}}}]}}

------------------------------------------

@joshkh Figwheel version?

i don't think so, i'm running the very latest figwheel / clojure / clojurescript versions

providing the :cljs-base map with an :entries [] key/value doesn't appear to work either as suggested here: https://clojurescript.org/news/2017-07-10-code-splitting

you do not need a { before cljsbuild

i don't in the actual project.clj in the link. i think that's just how figwheel does its reporting 🙂

oh i did not notice you linked to the actual file 🙂

I believe you need an output-to file.js

good idea, let me give that a shot

it just looks like figwheel maybe has the wrong validation for this?

thats not a CLJS error, its figwheel

you have one in :outside {} but one needs to live inside :compiler {} according to a recent project.clj here locally

i think i might have been barking up the wrong tree. figwheel shouldn't have anything to do with this. it's advanced compilation.

sorry, red herring

figwheel still validates the config.

yeah figwheel won't run until it's satisfied

that everything is "valid"

(is my understanding)

https://github.com/bhauman/lein-figwheel/blob/master/sidecar/src/figwheel_sidecar/schemas/cljs_options.clj#L317

hmmm, okay, update: https://github.com/joshkh/modules/blob/master/project.clj#L45 weirdly enough my public/js/compiled directory has a bunch of files that look more like no optimisations: app.js cljs cljs_base.js cljsjs clojure goog outside outside.js process reagent re_frame work

thats why it won’t accept [] (which CLJS is totally fine with, I think)

good catch thheller

i'll raise an issue if i confirm that i'm doing this correctly

so uh, can you just put nil there or :none ?

the base module is kinda special, so usually it should not be allowed to be empty

but empty entries are still fine since they “catch” common dependencies in the graph

what's the :entries line for exactly? i know nothing about advanced compilation in cljs land

i think maybe i'm missing something fundamental here. if i include no module descriptions and run lein cljsbuild once min i still get loads of files in js/compiled. that doesn't sound right at all for advanced optimisation.

isn't that ok though? i figured it was only the end product .js that got all the optimizations

compilers are a magical black box 😄

i don't think so? my other cljs projects produce a single some-app.js when i use advanced comp. what's going on here! maybe it's time for a walk. 😉

(or maybe those files get produced anyway but they're never loaded)

(maybe for source maps?)

Yeah, what role the files in the output-dir play is still a mystery to me

the end goal of this madness is to compile cljs based web workers into their own files

https://clojurescript.org/reference/compiler-options

you want each webworker to have its own .js ? sounds attainable ... modules seems to be the best way to go about that so far? it's a new puzzle to me

if i remove the :cljs-base entirely and keep the :outside module entry then i get an app.js of 0 bytes, cljs_base.js of 234 kb, and outside.js with 160kb. anyway that's a start... thanks for the input guys. i'll keep playing around with it.

@joshkh One workaround would be to switch off figwheels config validation. See validate-config

that sounds handy

i wish the newest module changes had a bit more documentation with practical examples. they seem to be fantastic changes and cover a lot of ground that previously separated cljsbuild from something like webpack

i think you want to give each webworker two things: base namespace that they all share in common, unique namespace that each webworker has its own code specific to it, and then specify :entries #{"namespace.unique"} and :depends-on #{"namespace.shared"}

i'll make a note of that for now and apply it i get a simple module example working. thanks again!

compiler comprehension is a team effort 😃

you could try shadow-cljs where modules actually work and I have been using them since 2013 😉

you're not the first person to suggest that

@joshkh looking at the backlog I’m not really I understand what your issues is

the guide takes you through a complete setup https://clojurescript.org/guides/code-splitting

what you were referring to was the announcement which doesn’t really show you how to use it

still, it may be that shadow-cljs is more convenient for the WebWorker use case, but I wouldn’t know about that

@joshkh see https://github.com/thheller/shadow-cljs/wiki/ClojureScript-for-the-browser#web-workers, just set :web-worker true for the module and the rest will be taken care of

@dnolen i'm very sure it's just a problem on my end - sometimes i need a little practice for things to click. i haven't spent much time playing with the compiler itself. @thheller thanks for the link. i'll play with shadow-cljs if it solves my use case, then dig more into :modules when i have some time.

In terms on lines of code, from when would you consider using Cljs instead of JS?

😉

@lockdown- I'd go for cljs if it's a SPA. for the more typical "sprinkled bits of js in a server-rendered app", cljs might be overkill if you're not very familiar with it