@lxsameer React works there’s nothing really the matter with it and React Native would take a lot effort. It’s not a complicated choice IMO.

@lxsameer I made one with pure ClojureScript called Respo http://respo.site but it lacks some features to make it really useful in old browsers.

The nice part is I can implement the virtual DOM with persistent data structure thus it reuses old virtual DOM tree well. But I'm not sure if it can perform better in performance.

I want to have some simple way to edit html for the website for my girlfriend, I found this https://github.com/Alex-D/Trumbowyg/blob/develop/src/trumbowyg.js which seems to do what I need, and also I already am using jquery. I’m just in doubt whether to try to rewrite it into clojurescript or not. It would make it easier to do things like saving the data, otherwize I would have to get the data back from the dom again, which is also not a big problem. Has anobody experience with converting js to clojurescript?

How to add 3rd party react native library like react-native-material-design in cljs project made with expo using lein new exponent proj-name.?

does anyone know what changed in recent Clojurescript versions that makes js/process evaluate to #js {:env #js {:NODE_ENV development}} under e.g. Phantom? Used to be nil under 1.9.562

@dm3 set :process-shim false

@anmonteiro thanks! Pardon my ignorance, but how is that flag useful?

@dm3 when processing JS modules through Closure we need to emulate the Node runtime

Where certain libraries dispatch on production vs development

Using process.env.NODE_ENV

what’s then the future-proof way to check if js/process is usable? E.g. I have to determine whether to use process.nextTick or goog.async/nextTick in a library.

People shouldn't be using the process shim in Node

Or any env that exports process

This may need more education/docs

@dm3 it would seem better in your case to check for Node target not process directly

@dnolen thanks, I’ll look at doing that

@dm3 at runtime cljs.core/*target* is a thing

only catch is that it’s value is a string since it’s a Closure define

I have a package that uses foreign-libs and :optimization :simple; when I use it from another project it works well in dev-mode, but with release (`:optimization :advanced`) it fails.

What am I missing here?

@hkjels probably externs

but saying it “fails” is skipping a lot of useful information for someone else to help you 🙂

@dnolen variables from those external-files are missing, yes

I’ve created an externs-file, but there might be some issue with it that I’m not qualified to see

I also tried :infer-exters, but same result really

the error will tell you which externs are missing

you can recover the original name by using :pseudo-names true, make it look nicer with :pretty-print true

OK, so with :pseudo-names true I could basically use a CDN right?

I’ll just end up with somewhat larger output

There’s no problem with concatenating two libs and creating an extern for it right=

I’m telling you how to debug your problem

if you’re OK with a giant payload then use :simple

@hkjels you need to be a bit more clear “concatenating two libs” what does this mean?

two JS libs?

yeah, basically cat file1.js file2.js > use.js

Ohh, I think I’m more in-tune with the purpose of all this now

concatenating two JS libs then using that as foreign lib - no issues

you still need to supply externs

and externs are the methods we use of those libraries

?

@hkjels yes, if you haven’t looked a this yet - this is required reading https://developers.google.com/closure/compiler/docs/api-tutorial3

not just methods, any properties that come from some foreign thing Closure Compiler will never see

@hkjels ^ FWIW this is the big selling point of the new NPM module support

before: we prepend foreign JS libs to the output of Closure advanced compilation

after (now!): Closure sees processed JS modules and in some cases doesn’t need externs

I think I’m hitting an issue with the particular thing I’m trying to mangle. When I use an extern instead of :infer-extern I get SEVERE: ERROR - Duplicate extern input

that error doesn’t have anything to do with :infer-externs (unless you can demonstrate something minimal that shows that)

the error means you’ve submitted the same externs file twice

Yeah, but I haven’t.. With a full project-search it’s only referenced from deps.cljs

https://github.com/bdo-labs/signalr-cljs/blob/master/src/deps.cljs

@hkjels you may think you haven’t but somehow it is happening

otherwise you wouldn’t get that error

what is your :externs value?

in your project

do you mean the file-path? “js/signal-r.ext.js”

right so that’s not a file path

that’s a resource path

so if that somehow appears in multiple places on the classpath, you will pass dupes to Closure

(.. (Thread/currentThread) (getContextClassLoader) (getResources "js/signal-r.ext.js")) (In a Clojure REPL)

if that’s not it then you could debug this by calling in cljs.closure/get-upstream-deps* at a REPL and seeing what got duped

Got it running!

@hkjels ok, but what was the problem? 🙂

It was my understanding of boot

you need to have source-path both in source-path and resource-path, but having the extern in both places messes it up

it’s not logical to me and I’m kind of not using the features of boot, so I think I’ll stick with leiningen for most of my clojure-needs from now on

only thing in favor, is that I can compile garden along with clojurescript with a single command

I'm using :preloads to monkey-patch createClass onto React v16 this works perfectly in dev mode, but not in advanced. Is there any proper solution for this, short of forking cljsjs.react?

hallo 🙂

@bendlas using :preloads under :advanced is not really a supported thing

so in this case you’re likely on your own

ok

A "fun" windows path problem here: https://github.com/funcool/promesa/issues/52#issuecomment-326366789

@dnolen I'll work around it for now, but ticket welcome?

@bendlas no, we have no intention of supporting :preloads under advanced sorry

it’s not for that

it’s an injection for dev time only

we even emit a warning about this so I’m not sure what you are expecting

I read that

I'd expect the same thing as for :none something that is ordered, as if required before requiring any app namespace

to set up polyfills, dom magic, global state, ...

if preloads is not the right thing for that, what is?

I don’t really have anything more to say about this

I’m not sure why you have those expectations, but I would lose them

all this said try master and it might work for you

but this not a promise we will ever make

oh, did something change in that regard since last release?

yes there was a implementation detail bug around :npm-deps

so obviously, you don't see a problem in designing such a flag, but you don't want to promise behavior and support it, right? so that means, that you think it's a worthless use case?

yes

I already said that

sorry also in the middle of other things, need to close this conversation 🙂

“worthless use case” I’m not even talking about that

but this isn’t what :preloads is for, anyways done for now

ayup, that's gonna be trouble 🙂 https://github.com/clojure/clojurescript/blob/f5af28f814896d3a538cba717331b651a5ef9239/src/main/clojure/cljs/compiler.cljc#L1118

funnily, this is only going to fail for deps that have a first letter that correspond with an ascii control char

@cemerick so file a bug 🙂

@dnolen I will, just spelunking a bit. All the fancy module stuff is new since I've been in here

@cemerick def, if you want to help out some would be glad to take it 🙂

@dnolen minor parse error on that last message, but :thumbsup: regardless

putting a patched build through some paces now

@dnolen that I haven't been filing tickets and otherwise causing a ruckus is mostly just a sign that you and the team have been doing good work 😄

lol

no joke bud https://twitter.com/cemerick/status/902929932120150017

for anyone following along: https://dev.clojure.org/jira/browse/CLJS-2345

hopefully I did the patch attach and tag dance right, it's been a while 🙂

cool thanks