Fork me on GitHub
#clojurescript
<
2020-07-10
>
Rabie02:07:52

@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?

jerger_at_dda07:07:52

Hi, can anybody recommend a well maintained hiccup equivalent for use in clojurescript ?

jerger_at_dda12:07:11

seems to be worth a try 🙂

cap10morgan17:07:51

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.

lilactown17:07:42

@cap10morgan you’ll need to make sure that you install any npm deps

lilactown17:07:47

in the consuming app

lilactown17:07:57

you definitely do not want to pull in any compiled CLJS code

cap10morgan17:07:16

That's not great...

lilactown17:07:38

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

wcohen17:07:17

sorry to make you answer this question twice at the same time, @lilactown

cap10morgan17:07:14

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.

lilactown17:07:17

:target :bundle is for apps, right? you don’t bundle a library

cap10morgan17:07:42

it seems great for my library, up until the point I try to consume it

lilactown17:07:56

well, right lol

lilactown17:07:35

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

cap10morgan17:07:01

but a library's consumers should not have to re-specify its deps

lilactown17:07:19

let me try and be clearer

lilactown17:07:35

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

lilactown17:07:11

here are the bare minimum files

lilactown17:07:58

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

lilactown17:07:51

you can specify this using the :install-deps compiler option: https://clojurescript.org/reference/compiler-options#install-deps

lilactown17:07:22

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

lilactown17:07:32

so you don’t have to enable :install-deps

lilactown17:07:02

does that make some sense @cap10morgan so far?

cap10morgan17:07:36

yes, as implementation details that the tooling would ideally not require I know or care about day-to-day haha

lilactown17:07:08

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

lilactown17:07:16

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

cap10morgan17:07:23

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.

cap10morgan18:07:28

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!

cap10morgan18:07:14

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.

cap10morgan18:07:43

yeah, shadow-cljs is still an option I'm considering

lilactown18:07:45

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

lilactown18:07:41

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

cap10morgan18:07:20

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.

lilactown18:07:28

yeah that’s not a super common use case, so I imagine you’re going to be very much in the weeds there

lilactown18:07:23

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

lilactown18:07:38

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

lilactown18:07:26

there are of course situations where it is reasonable but they are few and far between IMO

lilactown18:07:46

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.

lilactown18:07:17

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

cap10morgan18:07:21

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.

cap10morgan18:07:49

and then everything in CLJS land can just use :target :bundle and a good chunk of hair-pulling goes away 🙂

cap10morgan18:07:43

@henryw374 Yeah, I ran across that a week or two ago. Very helpful, thanks!

đź‘Ť 3
dnolen20:07:23

@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

dnolen20:07:30

nobody cares about how to build your library

dnolen20:07:41

it's really not something anybody wants to know

flyboarder20:07:47

Hello everyone, what is the equivalent of the spread operator in js for cljs MyObj.method(…params)

isak21:07:32

Can you use apply instead?

dnolen20:07:12

:target :bundle when you create an application solves this for you

dnolen20:07:29

there's no such thing as :target :bundle really for libraries

dnolen20:07:55

because libraries aren't things that are concerned about that

dnolen20:07:22

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

dnolen20:07:54

:npm-deps is the way - you've decided you don't need it for your app

dnolen20:07:57

not the other way around

cap10morgan20:07:56

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."

dnolen20:07:32

I would say it's done for the foreseeable future

dnolen20:07:39

we don't care about package.json it's really that simple

cap10morgan20:07:56

well... I care?

cap10morgan20:07:12

:target :bundle is really great! I want to standardize on it!

dnolen20:07:15

sure but that's not under consideration 🙂

dnolen20:07:50

we spent many years on this problem - it's addresses all the important points as far as I'm concerned

dnolen20:07:06

I use this thing for work for many use cases including the transitive dep problem

dnolen20:07:22

and it doesn't cause me any confusion nor do I see any meaningful inconsistencies

dnolen21:07:04

none of this is to say that feedback isn't being collected or your opinion isn't heard

cap10morgan21:07:46

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.

dnolen21:07:53

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

dnolen21:07:07

anyways I don't have much more to say about it, sorry 🙂

dnolen21:07:40

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

dnolen21:07:58

tooling, libraries etc. all have to align - this takes a really long time

dnolen21:07:28

:target :bundle created churn - which is something we try hard to avoid but sometimes you cannot

dnolen21:07:42

so more changes mean more churn

dnolen21:07:08

and in the Clojure community I don't think anybody has a lot of patience for too much of that

cap10morgan21:07:03

makes sense. I don't mind churn personally when it's such a great improvement like :target :bundle. So thanks for that!

dnolen21:07:40

yes, but this a core community value and should remain so

dnolen21:07:48

the rest of the world is drowning in churn

dnolen21:07:51

not interested