Fork me on GitHub
Oliver George03:12:41

Is anyone using with

Oliver George03:12:23

Seems to work. Slightly fiddly with where deps should live. Tools only uses :paths and :deps from the alias.

Oliver George03:12:14

Cursive finds it all a bit baffling (build.clj in ./)

Oliver George03:12:52

This is my setup. The "double deps" seems odd to me. Perhaps I'm missing something:


the "thematic" difference between and cljs build apis is that is meant to build your project without running it and therefore works with your project classpath but does not use it


the cljs compiler however requires using your project classpath to gain access to your dependencies at runtime


so imho you should execute it as part of a -X or -M task, not part of a build.clj or -T


or technically you can move all of your CLJS related dependencies into the build alias since they won't be required at "runtime"

Oliver George11:12:22

Thanks. That makes sense.


any advice on a good place to start to bootstrap a fullstack clojure project using deps.edn / shadow-cljs.edn?

Cora (she/her)03:12:37

@chadhs you could try fulcro


im more looking for an example to how to setup the project rather than which frontend tech to use, unless you meant to look there for that purpose.

Cora (she/her)03:12:23

well, it uses shadow-cljs.edn and deps.edn and provides for full stack development


cool thnx. i’ll look there for a model to use. im pretty happy with my leiningen setup, but want to expand my knowledge a bit.

Cora (she/her)03:12:33

@chadhs oh! I just remember we had this in an edition of clojure morsels

Cora (she/her)03:12:06

that really is as simple as it gets. much simpler than fulcro

Cora (she/her)03:12:42

but, of course, fewer features


very helpful @corasaurus-hex thank you!

💜 1

But when I use this like so:

:children (fn [render-props]
                             (r/as-element [:div "foobar"]))
I’m finding that the foobar div is actually not showing up


Any ideas why that might be the case?


Is there any difference when trying [:> AxisBottom {} [:div “hi”]]?


that breaks the code and gives the following errors:

react-dom.development.js:11103 Uncaught TypeError: _ref$children is not a function
Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method


also tried this:

[:> axis/AxisBottom
        (->> {:top (+ top height)}
             (merge (axis-props :x)))
        (fn [render-props]
          (r/as-element [:div "foobar"]))]
doesn’t break anything but foobar doesn’t show


where axis-props is:

(fn [axis]
          (merge {:scale (get-scale params axis)
                  ;;:label (format-field {:title (get-field params axis)})
                  #_#_:children (fn [render-props]
                                 (r/as-element [:div "foobar"]
                                   #_[:> a/Typography.Paragraph 
                                      {:editable true}
                                      (format-field {:title (get-field params axis)})]))
                  ;;:labelProps (label-props axis)
                  :tickStroke line-stroke
                  :tickLabelProps (tick-label-props axis)
                  :stroke line-stroke
                  :numTicks num-ticks}))


Hello, not really a CLJS question, but I could very well use the expertise here. I’m trying to follow the strategy described in The idea of separating the “static” UI part from the domain logic fully resonates with me. But when I try to put it to practice, I’m mostly failing. The problem is with large components that consist of multiple nested components. It is almost always efficient and manageable to use “connected” components (connected components, in the sense, the component’s state is directly hooked to the central App state like how Reframe and Redux apps are developed instead of depending on the parent passing in the required props). It’s proving hard for me to develop large components purely in Storybook. Any pointers on how to go about this or whether this is even possible?


The way I see it, Storybook is meant for reusable components. Large components that exist in a single instance in an app and depend on a particular place in your global state aren't reusable. You can view them as not components but rather your app's chunks. If you do want to make them reusable, you gotta bite the bullet and pass everything they need to them. It can be either the data itself (which is often inefficient), some getter functions, or just the coordinates of the data in the global storage (although I'm not sure how well it could be used in Storybook).


In that talk, David showcases a really simple app, UI-wise. So your app is really complex, is no surprise that the practices the talk mentions can't be directly applied in your case.


The impression I got from the talk is that it was definitely possible to build a large app that way. But I guess not.


But they seem roundabout.


We've been experimenting with this approach. We've made a few simple and more complex UI elements. In the end it isn't just about reusability imo. If you use this approach you will often be forced to reconsider what state you really need inside an element and what state should really be managed outside that element. It is often easier for a component to manage the app state, and yet it makes life a lot more complex too. A simple question I keep asking myself these days is. if I ask a new developer to take over the code I've written, can he quickly understand what each element does, and what state it controls? If the answer is "it's complicated" then it is likely that the large component manages a too complex state to keep and I would prefer to try and find a way to simplify it further. It may lead to some overhead or "inefficiency" but in the end the benefit of being able to control state in a coherent manner is probably a life saver down the line.


Yup, reusability is not my primary concern either (using React solves this problem anyway). I’m mostly looking for, • leveraging the multitude of JS build and UI libs in a smooth way while building the UI part, and writing the the domain logic with all the powers of CLJS. • to be able to separate concerns. • to freely outsource the static UI building part. • and like you say, to properly reason about the interface of the component than intermingle the state, UI and domain logic all in the same roof.


There is another related experience (for us at least). One of our apps we build had a pretty complex state. And that state was affected/changed on multiple possible places in the app itself. This made it much harder to figure out why state sometimes was different than we expected. If you are able to let UI components only manage internal state and let the parent/caller manage the state that goes into and comes out of the UI component (etc etc), the design itself helps you to make state changes cleaner and easier to follow (in my experience).


This topic is very relevant to my work right now. I am down in the details though. How do you interop JS component with CLJS business logic? I am using Krell.


What are my options for a fix here

[Figwheel:WARNING] Compile Warning   resources/public/js/compiled/editscript/diff/a_star.cljc   line:242  column:24

  Use of undeclared Var goog.math.Long/getMaxValue

  237    ((juxt get-came get-open get-g) state))
  239  (defn- access-g
  240    [g cur]
  241    (get g cur #?(:clj Long/MAX_VALUE
  242                  :cljs (goog.math.Long/getMaxValue))))
  244  (defn ^:declared diff* [ra rb came])
  246  (defn- compute-cost
  247    [^Coord cur came g op]


@emccue if you're using the latest releases goog.math.Long/... isn't a valid pattern anymore


because that namespace became a goog.module


basically you can longer assume it exists (because some other namespace might have loaded it), you must require it and use an alias


okay so its either 1. fork library 2. track down Huahai Yang


Could you file an issue. Thanks

👍 1

yes all libs that depend on global requires of goog namespaces that became goog.modules are broken


How to fix this? I am not following goog closure.


hi folks. i have reasonable experience with clojure, but zero with clojurescript and the js ecosystem. i am trying to get an expo app up and running, with the react native web backend to have a cross-platform app for windows/linux desktops. i am hitting what i'd call schoolboy errors/beginner issues, likely stemming from my inexperience with the ecosystem. is anyone up for maybe having me bounce dumb issues off them? (i tried google, but likely lack foundational knowledge to know what i'm dong wrong.)


(will be starting with: lein new expo sbf +reagent)


and, if this is a poor/wrong way to start, am open to alternatives. just want to get to a point where i can have a skeleton app running to start dev from.


(use-case: small icecast-streaming app with live song data and ability to send http requests to a server to control playlist etc., so would like some js-interop and tray icons, notifications. it is a learning exercise/something for friends during lockdown. choosing react native web because my desktop is linux, most others are windows, so i guess it's the best option?)


also happy to take this to #cljsrn if it's more appropriate there


I think if you have questions, the best thing to do is start asking them. this is a public forum for discussing and asking questions, after all 🙂


sometimes experts in certain things (e.g. reagent, react native) hang out in different places. if there is a specific place for it, your question may get answered quicker or more precisely in the channels that pertain to the topic. e.g. if you have a question about reagent, you might try the #reagent channel.


electron + cljs + react-native-web is a pretty specific stack that you might find difficult to get help with, since each one is a niche within a niche. I'm sure others have built apps using that combination of tech but finding things on google/stackoverflow/etc. or finding someone who has used those specific technologies all together here in slack might be difficult. so you are likely to do a lot more problem solving and investigation yourself then if you were to pick something more mainstream


ok, fair enough. i am using yarn, so, after lein new expo sbf +reagent, cd sbf, read the readme, do: yarnpkg install, lein figwheel, expo start, first error: Error: react-native is not installed. Please run npm install or yarn in your project directory. so i try yarnpkg add react-native (guessing), retry expo start, great, it works. i try w for open web, web is disabled, enable by installing react-native-web. so i do yarnpkg add react-native-web and add web to a platforms array in app.json i see two things. next: Warning: Invalid version [email protected] for expo sdkVersion 34.0.0. Use [email protected]. this i can change by, I think, changing the version in package.json then, Module not found: Can't resolve 'react-dom' so I: yarnpkg add react-dom, and with expo start, w, next thing: Add @babel/plugin-transform-react-jsx ( to the 'plugins' section of your Babel config to enable transformation.

👀 1

at this point I question whether I'm doing something very wrong, because this is beyond what I'd expect to have to do to get up and running -- maybe I am using the wrong beginners toolset, or doing something obviously incorrect


I tried to figure out how to add plugins to babel configurations, how to add that additional dependency, but so far hit walls of knowledge. I am only vaguely familiar with babel (it's some transpilation tool for different ecmascript versions?)


I am happy to go with something more mainstream, if there's something mainstream for cross-platform GUI applications that allow stuff like sorta-native bindings


(I did investigate javafx, but it does not even support tray icons yet)


I know what I'm aiming for is likely niche, but it would be really nice to be able to write clojure for a cross-platform desktop app.


(and I figure it's doable, I'm just lost in the JS ecosystem/tooling, and if I spend enough time figuring out that, I likely know enough js to write one using that. my hope is that I can just lift my jvm clj knowledge with a sprinkling of voodoo to get halfway to where I need to be.)

Cora (she/her)18:12:29

I don't want to derail or anything, but have you looked at fulcro?


never even heard of it, so no.

Cora (she/her)18:12:12

it supports native


since I'm starting from ground zero, I'm open to anything, so will take a look


as long as I get windows+linux support, I'm happy. I'll give it a whirl, thanks.

Cora (she/her)18:12:14

they have a template you can start with, too (not sure how up to date it is )

Michael W18:12:22

It's not working with the newer electron fulcro-inspect app, so it needs to be updated for the newer fulcro releases.


I won't be using fulcro inspect (seems like a chrome extension?)

Michael W18:12:59

There is a stand-alone electron app to inspect your apps client database and the various pieces of state that make up your app. For a fulcro native app you would run the electron inspect app, then your native app configured to use the native inspect app. That old template will not connect and work with the newest native inspect agent. There were many changes made in a release last year. That fulcro-native-template would need changes to work with the newest version of inspect.

Cora (she/her)18:12:09

and this is the repo for the project itself

Cora (she/her)18:12:17

I haven't used fulcro myself but it seems nice and it sure does support a lot of things

Cora (she/her)18:12:46

it's from the lead dev of clojurescript

👍 1
Cora (she/her)18:12:17

and it seems like a much lighter thing than fulcro


my usual workflow is emacs + cider, will try and shoehorn one of these in


lighter is better for me, since I don't likely need much nor want to learn everything if I can avoid it. this is just a pre-xmas project


which is likely to get me most help if I get stuck with broken pieces? 😉


(I am also open to paid hand-holding, if anyone has the time & expertise & willingness. I would plan to document the outcome.)


note: does look like, while krell is lighter, it definitely expects you to know what you're doing and already know how react native tooling works. so that is less of an attractive out-of-the-box clone-and-code experience, requiring learning how to build the stuff by hand first probably (at which point i'd likely have just written it in js)


it may be that it is unavoidable to know cljs without knowing js? (I managed to do almost all jvm-clj without prior java knowledge, except when i had to dig into jnr-ffi and c-bindings stuff)

dsp18:12:15 seems like a decent example of a full electron + cljs app at least, as a reference point

Joshua Suskalo18:12:22

(@dsp there's other options for c-bindings by the way, stuff like dtype-next and #coffi these days so you don't need a java api 🙂 )


ah cool, I'll check them out. I was looking at jnr-ffi because it was used by caesium

Joshua Suskalo18:12:39

Yeah, jnr-ffi is fine, but dtype-next and coffi give you clojure-native ways to do it. If you're on an old JVM dtype-next will probably be slower than jnr, but coffi on jdk 17 and dtype-next on jdk 16 will be faster.

Joshua Suskalo18:12:30

coffi is atm the fastest ffi for clojure (even faster than jni) at the moment, but it's restricted to only jdk 17.

👍 1

might be useful for my next project. cheers