Could someone sanity check something: I haven’t tried to use the promesa async macro since 1.10 came out and now I cannot get it to compile. Test file src/tst/core.cljs:

(ns tst.core
  (:require
    [promesa.core :as p]
    [promesa.async-cljs :refer-macros [async]]))

(println "hello world")

{:deps {org.clojure/clojurescript {:mvn/version "1.10.238"}
        funcool/promesa {:mvn/version "1.9.0"}}}

@lee.justin.m do you need to require core.async?

What is the best method to wrap a reagent/render to make sure the element is loaded and not get the "Target container is not a DOM element" exception? Edit: I should probably ask this in #beginners.

@bhauman that was it thanks! when i was doing this before I was also already using core.async so I didn’t realize it had a dependency on it

do transitive dependencies not work with deps.edn or does funcool/promesa just not declare one when it should?

@lee.justin.m it seems that the dep is provided in there and I think clojure cli does not handle them, but double check in #tools-deps - https://github.com/funcool/promesa/blob/master/project.clj

That is why you need to add it explicitly

Maybe

the whole point of provided is that the consumer is supposed to provide it instead

it’s intentionally not a transitive dep

in this case, that seems wrong

there are a pretty small set of cases where provided is the right answer

Right agree

A new official guide on using Webpack with ClojureScript https://github.com/clojure/clojurescript-site/blob/83a759ba652a48ed8298ccba403c1f239ec46455/content/guides/webpack.adoc

will be pushing out a release on Friday, you can try this out with master

hopefully this dispels a lot of mystery on how foreign libs and externs inference is meant to work

Very cool!

also kind of nice succinct guide on how to use webpack for doing really basic stuff

I wasted 3 hours distilling this

very nice! maybe i don’t have to send out @pesterhazy’s double bundle link twice a week anymore 🙂

I wouldn't consider it wasted

well I mean just that wow - lots of old links, lots of incomplete information, lots of extra stuff, too many options, create-react-app isn’t configurable … and on and on

while we certainly have things to work on - I think we’re doing swell - I can’t believe that people have the patience for this stuff

though criticizing create-react-app for not being configurable is like criticizing a harley davidson for being loud. that’s kind of Its Thing.

back to the getting more people involved, I got involved with CIDER thanks to some "low hanging fruit" tags on issues. could easily find a template for what to do and the tickets were good introductory tickets

so closure/cljs can infer all externs for react(after webpacking) without warnings? nice

what's different here? https://clojurescript.org/guides/externs it emit warnings for a simple lib

What are the caveats for property access in JS? I’m seeing a totally weird situation where printing the object as a whole in console.log prints out the object containing property to: 100 but when I access it by (.-to props) or (js* "") I get undefined…. This happens only under advanced compilation mode

I’ve never ever come accross this kind of a situation

I’ll try to assign it to a variable I can access from the console. let’s see.

that’s how advanced compilation works

you cannot expect the names to remain the same

Oh… oh… I see.. 😄

So even property getters get mungled inside a fn?

all static property access is subject to munging

So the getter is not (.-to prop) but something else?

doesn’t matter where

OK, this only happens with one property in the whole app

All the other props come out cleanly

but you probably got lucky

if you’re dealing with data don’t use static property access

OK, I’d use the goog-getters then?

goog.object namespaces provides useful fns

👍

This is so obvious now… Works like a charm, thanks @dnolen!

np

I have a follow up question to this - should you ever really use the (.-propertyName syntax? It seems like you’re always at risk of getting munged. And if you shouldn’t - why even have the syntax?

Some hosty interop stuff will not be munged, so it'll still be common

Why does my (.-maps google) compiles to $update-map$.$maps$ i.e. it munges my properties? It happens in production mode using shadow-cljs. And how to make it safe to property munging if library is loaded as third party script? Solved it using ^js

How do I deal with 2.0 getting autoconverted to 2?

Not fun with a deep datastructure where floats become ints

Datomic and my specs are very unhappy

@andreas862 Clojurescript uses Javascript numbers, so everything is a float. Maybe that’s why you see autoconversion

@paytonrules you should always use .- for programmatic stuff - non-data

getting munged isn’t a risk - it’s nearly always what you want for your program - you just don’t want it for the JS interop data bits

ClojureScript data structures get completely munged for example

and you never worry about this stuff

@troglotit I would guess that as well. Problem is that I somehow must sanitize all data sent to the server. And I can't use the same spec for client/server

Thanks for the clarification @dnolen - this is a part I get continuously tripped up by

@andreas862 I don’t really understand your problem

floating point should be encoded as ~f on the server

and that will be preserved on the client side

it may be that you always want to write floating point on the client if you have a number

recent releases of transit-cljs have a :transform option for the writer - you can intercept all values before they are written and do a switcheroo to accomplish this

On the server I have {:my-floating-point 5.0}, when I round trip it through the server->client->server I get {:my-floating-point 5} back - But it might be something else like Sente/transit influencing that

@dnolen Just read over the new blog post. Really great stuff. From my understanding, it is letting webpack handle node_moudles so that you can use the output in your project, but I think I am missing some context. When/why would I choose this option over :npm-deps? Is this to allow us to use a larger set of npm deps without having to send it through the closure compiler?

@andreas862 hrm actually float is ~d and I see how this could happen, so yeah it is asymmetrical - but I still think you should be able to find a OK way to work around this

@tkjone because :npm-deps has edgecases - thus lot of people use shadow-cljs for Node modules stuff - but the post is demonstrating precisely what ClojureScript supports which far as I can tell there’s an incredible amount of confusion about

but the problem was one of documentation - I don’t think anybody really understood how :global-exports and extern inference are supposed to interact to make this stuff painless

you might still want to use shadow-cljs because it’s convenient, easier - but everyone should know you can get the same results with a small amount of effort w/ ClojureScript alone

@dnolen ok, thank you

Awesome, thats pretty much how I interpreted it. So in other words: For many libraries, we provide you with :npm-deps and that works in most cases and is being improved, but there are cases where it will not always work as expected, and when that happens you can use traditional JS tooling, like webpack, and have your project consume that...

@andreas862 in projects where where floating point rep mattered we just wrapped in BigDecimal since we weren’t using this for computation anyway since we didn’t want to do that on the client

wrapped the response from the client?

@tkjone exactly, :npm-deps is a long term investment - but this meme that you can’t use ClojureScript easily with Node stuff needs to die

Does clojurescript allow metadata on functions?

I'm trying to log out metadata that I attached on a function but (meta fn) shows null

(meta (with-meta (fn []) {:x 42}))

you probably didn’t attach metadata to a function, but to a var holding a reference to function

I'm using

(defn lesson
  {:some-meta 1}
  []
  (fn []
    [:div]))

it has to use with-meta?

AFAIK when you set metadata via defn, it gets attached to the var created, not to the function object itself

see (doc defn) it is explicit about it

http://cljs.github.io/api/cljs.core/defn

how do you read that metadata?

(meta lesson) should still give you what you expect

ok I got what you meant earlier

I am passing the function reference, so that makes sense

then use with-meta, it will create a wrapper of the original function, which acts as original function but also has support for meta-data protocols

btw. you can see the difference between result of (fn []) and (with-meta (fn []) {}) in REPL

the second one returns #object[cljs.core.MetaFn]

https://dev.clojure.org/jira/browse/CLJS-359

Does anyone have experience with Medium Editor?

The problem with all these "look we can consume UMD modules easily" posts is that they are always toy projects that do not reflect real world usage. I will take it upon myself this weekend to document the immense difficulty/impossibility to get reagent + figwheel + a react library working using node modules. Maybe the actual clojurescript compiler can handle this, but most people are not starting at these "low levels" they are trying to make things work with leiningen, which has been a completely fruitless endeavor for most people. I'm not sure where the problem lies, I will explore the differences with lein-cljsbuild/figwheel and just using the new clj tool this weekend. And by things work I mean "reagent + react16 + a random tiny react component distributed as a UMD module. " Maybe react is a PITA, but it is the defacto standard for view rendering in cljs. If I'm delusional hopefully documenting things will bring clarity to the error in my ways.

@bfast you can save yourself the trouble - people have already done it, it works

people have been using Webpack to bundle node_modules for years

the only that has changed is you don’t have to write externs yourself, and interop looks less ugly

also none this has anything to do with boot / lein / clj

the choice of tools doesn’t matter in the slightest

that said - the problem is two-fold

A) people expect tools to magically do X, when you may have to do a couple things on your own B) tools aren’t that well documented so you can figure out A) is possible

everyone doing those couple of things on their own (cargo culting & in slightly different ways from one another) is obviously not a very sustainable model either though. or perhaps it is and I'm just not clued into it yet.

certainly everybody has their own very personalized emacs setup

that statement doesn’t really align with my experience

and perhaps the clojure tooling behind each dev's setup is no different from the emacs philosophy

every actual application that people are actually shipping don’t do standard things

it’s hodge podge of cargo-culted stuff

any programming language, any stack, any company

@dnolen perhaps true. it just seems to be a bit more pronounced in the clj/cljs community

all I have to say is wat? 🙂

it’s the same in every programming language community I’ve ever been a part of

JS is way worse

I have never found a post hammering out all the details I am talking about. Specifically reagent 0.8 + react UMD foreign lib. I hope you are right David, but I spent multiple hours yesterday trying to get it to work, so I am not convinced. I am trying to be constructive by documenting where I am getting stuck. Are you saying webpack is the only way to make this work?

it took me 3 hours to figure out how to put this Webpack post together

and I still got it wrong

gimme a break 🙂

fair enough. coming from something like Visual C++ or IntelliJ is a different experience though

ha really?

IntelliJ magically figures hodge-podges

that’s why it costs $800 a year

yes, but those hodge-podges are hidden from you. 🙂

anyway, i'm not complaining and i've certainly gotten more accustomed/comfortable with this aspect over time

it's usually the frameworks that glue things together in a nice way, no?

back to the main point - yes documentation is a problem - we need to work on that

@bfast I thought the UMD thing was a bug (regression or UMD pattern it couldn’t handle) with Google Closure? We bumped that today - will be in the next release - tomorrow

but also :foreign-libs is not magic 🙂

you should be able to use Webpack to create something which provides cljsjs.react - if you’re trying to work around something

I might extend the Webpack post to clarify that

:foreign-libs was designed to be overrideable since the very beginning because you may need to work around stuff

That would be great if there is a fix. 🙂 I obviously don't have enough understanding of things to make things work yet, so I couldn't tell you what my specific issue was. Last I remember I was stuck at something like "Error: Cannot find module '@cljs-oss/module-deps'" .. but I will document everything this weekend. I am hoping to avoid workarounds and understand the root issues I am facing

@bfast that’s covered in my post

you need :npm-deps false if you have node_modules and you don’t want to use it

boom

@bfast just confirmed this works

I can run Reagent 0.8 from my own build of React via Webpack

I’ll add this to the post

it’s also comically short

https://github.com/clojure/clojurescript-site/blob/c9c4cd2b8209aab12cbabb356a95ac2d71763f2d/content/guides/webpack.adoc#overriding-a-foreign-library

@dnolen does cljs infers (via closure) all externs for react without warnings or does react complies to closure rules?

ty @dnolen I have put together a small project that shows my frustrations with the tooling... For the life of me I cannot tell what is going on with this project and why it doesn't work. https://github.com/briangorman/es6test . .... I am trying to add a single es6 module as a test that foreign libs works, but somehow the project is trying to invoke node. Even on a computer that has never had node installed. I'm trying to run the project with "lein figwheel".... maybe I'm dim

@lockdown- externs inference is just about automating externs

@bfast :npm-deps false in your build config

its there

I just verified that the Webpack override works and externs inference under advanced compilation has you covered w/ a small tweak to master @bfast

@bfast I would look at that but it’s seriously lacking in any kind of meaningful information

please describe the problem on the repo so I don’t have to run the thing first

cannot find module @cljs-oss/module-deps

paste the whole trace please

and what happens under --verbose

also :npm-deps false may be limited to master

oh well that's probably the problem

tomorrow 🙂

@dnolen ok next time I will update the readme. It looks like Bruce provided what you requested? Thanks for looking at this

https://github.com/clojure/clojurescript-site/blob/c1233554495a965efc9dfafa3aaa7e63d7d9a294/content/guides/webpack.adoc#overriding-a-foreign-library

demonstrates that advanced builds work with externs inferece

I think release should address a lot of complaining 🙂

quite valid complaining for sure

This project was generated from "reagent-frontend" template

right but it doesn’t matter what template you use

the guide shows you how to make it work regardless

Ok awesome, I will give it a whirl tomorrow.

thanks

http://rigsomelight.com/figwheel-main-template/

@dnolen why do you use warn-on-infer here https://clojurescript.org/guides/externs but not on your react/webpack example ?

you don’t need to use it

*warn-on-infer* is just an extra thing for people who are extra picky and who want to control the scope of externs inference

in theory it would affect code size, but fortunately ClojureScript users aren’t generating clashing names due to ubiquitous munging etc.

when you’re writing a library that interop with some foreign lib you might write something like

(.getX ...)

externs inference will produce Object.getX instead of something more specific

but honestly it’s probably the case that this won’t really affect most users - I did this as a completeness thing just in case

note that none of this matters for overriding cljsjs/react

Object.getX as in the object object ?

somebody has already written the interop stuff

@lockdown- I honestly wouldn’t worry about it too much 🙂

if you’re curious I would refer to Google Closure docs on externs or the Google Closure book

ok

are the conditions for inference that all modules are removed and the final bundle is ES5?

I don’t know what you’re asking

externs inference is for one thing and one thing only

not renaming stuff that can’t be renamed

previously you had to write externs by hand when using foreign libs

or hope that they were written for you a la CLJSJS

now you don’t need to care

was just curious about the use of webpack, that somehow is was needed in cljs to remove all the module stuff and es6 stuff, but I guess is needed for the same reasons is needed in JS (sorry, new to this)

it’s needed in the sense that there’s demand for it

shadow-cljs does a good job already of course - but we’d already invested a lot of effort ourselves so this just polishing up what’s there and documenting it

for example externs inference is actually based on a idea I had years ago that Maria Geller did the foundational work for 3 years ago http://mneise.github.io

Ok, was confused at first cause I though inference was closure feature instead of cljs one

so all these trouble is because some want to avoid using webpack(or js tools, even clojure tools?) at all costs? 😛

so cljs is actually ahead of typescript in this area or are TS declaration files is a different thing?

not quite

this is to support usage of other tools

i.e. you want to use some random React component

but that nearly always means you need to build React yourself