This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-10
Channels
- # announcements (5)
- # aws (18)
- # babashka (1)
- # beginners (81)
- # calva (7)
- # chlorine-clover (1)
- # cider (5)
- # cljs-dev (8)
- # clojure (125)
- # clojure-dev (1)
- # clojure-europe (31)
- # clojure-italy (3)
- # clojure-nl (2)
- # clojure-norway (1)
- # clojure-spec (5)
- # clojure-sweden (1)
- # clojure-uk (31)
- # clojurescript (85)
- # code-reviews (1)
- # core-async (17)
- # cursive (39)
- # datomic (16)
- # emacs (1)
- # fulcro (6)
- # java (16)
- # kaocha (2)
- # luminus (4)
- # malli (2)
- # off-topic (65)
- # pathom (3)
- # re-frame (11)
- # reagent (5)
- # remote-jobs (1)
- # rum (5)
- # sci (10)
- # shadow-cljs (24)
- # spacemacs (4)
- # test-check (3)
- # tools-deps (22)
- # xtdb (15)
@jamesleonis Well actually I am using reagent/reframe. The issue is that I need to import react-spring to the whole thing for animations . As far as I know there is no cljs wrapper for react-spring. So I was looking for a way to call directly the javascript ract commands with cljs. The problematic part is the js function
function App() {
const props = useSpring({opacity: 1, from: {opacity: 0}})
return <animated.div style={props}>I will fade in</animated.div>
}
Any idea on how to tranlate this into cljs?I haven't used React-Spring, but I imagine it should be similar to this call https://github.com/reagent-project/reagent/blob/master/examples/todomvc/src/todomvc/core.cljs#L50
@rnait1977 Let me do you one better. I found this SO that integrates Reagant and React-Spring https://stackoverflow.com/questions/58977738/javascript-to-clojurescript-interop-with-react-spring
Hi, can anybody recommend a well maintained hiccup equivalent for use in clojurescript ?
@jerger_at_dda does something like reagent suit your needs? https://github.com/reagent-project/reagent#examples
seems to be worth a try 🙂
Thank you @jamesleonis
If I have a CLJC library that is consumed by another CLJC app (using :target :bundle
for the CLJS side), I know I can pull in the CLJ side with maven coordinates in deps.edn
. But to pull in the CLJS side of the library, do I need to pull in the compiled JS via npm / package.json
? Or can I use the same maven coords for that? Currently it's failing to compile the library; saying it can't find the npm deps of the library.
@cap10morgan you’ll need to make sure that you install any npm deps
That's not great...
if your lib has a deps.cljs
on the classpath, you can specify npm deps there and tooling can automatically install it when using your lib
sorry to make you answer this question twice at the same time, @lilactown
Ideally the :target :bundle
tooling would generate the deps.cljs for me, then? Just wondering if this is a "we haven't gotten to it" kind of thing vs. "we'll probably do it differently" kind of thing.
why not?
it seems great for my library, up until the point I try to consume it
you might bundle it while testing it out, but the output of a CLJS library is a bunch of CLJS source files. not compiled JS code
but a library's consumers should not have to re-specify its deps
lib/
deps.edn
src/
lib/core.cljs
deps.cljs <--- has your libs npm deps specified in it
app/
deps.edn <--- specifies `lib` dependency
build.edn
src/
app/core.cljs <--- uses `lib.core`
package.json
now, if we’ve setup our lib
project like this where we specify npm deps in its deps.cljs
file on the classpath, in your app
build.edn you can tell it to automatically install npm deps
you can specify this using the :install-deps
compiler option:
https://clojurescript.org/reference/compiler-options#install-deps
however, you may decide that you’d rather control the npm deps yourself when writing app
since maybe the npm dep is something like React, where you’d like to bump it to 16.13.1 despite lib
specifying 16.9.0
does that make some sense @cap10morgan so far?
yes, as implementation details that the tooling would ideally not require I know or care about day-to-day haha
hm OK I’m not sure how to react to that. FYI I didn’t build CLJS 🙂 but it seems par for the course when dealing with any sort of build system
if you want something that Just Works:tm: a bit more, you could try out shadow-cljs. it solves a lot of the config pain for app
’s needs
so, just from a very high level perspective, there isn't always a clean distinction between "app" and "library" projects. ideally I'd be able to specify my CLJS and JS deps in the same way / place in either situation. just like how CLJ and Java deps work in Clojure itself.
it had seemed like :target :bundle
was finally taming the madness a little in CLJS; but that seems not to be as cut n' dry as I'd thought. I do appreciate you walking me through the details, though!
if it's a "we haven't gotten to it yet" thing I'm very motivated to pitch in and help. but I want to understand what it should ideally look like first.
yeah, shadow-cljs is still an option I'm considering
FWIW I don’t know, I’m not on the CLJS dev team so I don’t want to give the impression that I have any authority
but I do want to point that there’s always going to be a big distinction between “apps” and “libraries” in CLJS, because their output artifact is going to be very very different. you might have one project that serves as both an app and a lib, but you still have to treat those two aspects of the project separately
Sure, yeah, CLJS code vs. compiled JS. I'd hope the tooling could help w/ this, though. For instance, even in a pure library project, you might want to make it consumable by third-party JS code.
yeah that’s not a super common use case, so I imagine you’re going to be very much in the weeds there
turning a CLJS lib into a JS lib is going to be very painful no matter what, because you’ve gone from “I need to deploy a JAR with some CLJS code + pom.xml” to “I need to use the ClojureScript compiler and optimize this in such a way that foreign JS can consume it”.
you’ll also be bundling with your lib all of cljs.core
, so your artifact size will be much bigger for the functionality it provides
I’ve tried writing JS libs in lots of compile-to-JS langs (CLJS, ReasonML, PureScript) and it’s the majority of the time awful for consumers because of the bundle size. compile-to-JS langs are much more suitable for apps or language-internal libs
there are of course situations where it is reasonable but they are few and far between IMO
I do agree with you that CLJS tooling is rough. It’s very much DIY - to some extent on purpose. the expectation is that you will be using something like figwheel or shadow-cljs to build your apps, which wrap the CLJS compiler into a more friendly API.
in that regard, there’s a lot of opportunity for motivated individuals (like you) to build on top of the CLJS compiler to make things easier
yeah; and thanks again for all that background info. very helpful! this feels so close to what I want. like maybe just needs to embed something in the library jar that tells consumers how to compile it.
and then everything in CLJS land can just use :target :bundle
and a good chunk of hair-pulling goes away 🙂
@cap10morgan I wrote about some of this stuff here http://widdindustries.com/cljs-npm-libraries/
@henryw374 Yeah, I ran across that a week or two ago. Very helpful, thanks!
@cap10morgan I think you are still misunderstanding what I've said, or perhaps looking at the problem in way that just makes things more complicated for everyone
Hello everyone, what is the equivalent of the spread operator in js for cljs MyObj.method(…params)
while in your app you may decide to use package.json
instead of :npm-deps
it's really irrelevant wrt. packing a library for consumption in a general way
You are absolutely right that I'm still misunderstanding! Here's what I know: I have a library where :target :bundle
works great for things like building and running its tests. I have a consumer app where I'd like to be consistent and also use :target :bundle
. But it can't consume my library unless I handle the npm deps in an entirely different way in there. So I'm confused why there isn't at least a vision for making this all more consistent and developer-friendly. I get it's not done yet, but I don't get why "this should be good enough."
well... I care?
:target :bundle
is really great! I want to standardize on it!
we spent many years on this problem - it's addresses all the important points as far as I'm concerned
none of this is to say that feedback isn't being collected or your opinion isn't heard
yeah, I get that. you're knee deep in it. and we all appreciate that very much! but this feels like an arbitrary inconsistency to not even want to improve upon from my less-in-the-weeds perspective.
but nothing is going to change anytime soon - tools are aligning w/ what currently there and maybe in a year or so it'll be more obvious what's missing
alright
the other thing to keep in mind is whatever issues you or anyone else may perceive there's really a very broad problem of change
:target :bundle
created churn - which is something we try hard to avoid but sometimes you cannot
and in the Clojure community I don't think anybody has a lot of patience for too much of that
makes sense. I don't mind churn personally when it's such a great improvement like :target :bundle
. So thanks for that!