This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-22
Channels
- # adventofcode (21)
- # announcements (2)
- # babashka (35)
- # beginners (45)
- # calva (22)
- # cider (28)
- # clj-kondo (39)
- # clj-on-windows (69)
- # clojure (28)
- # clojure-europe (15)
- # clojure-nl (7)
- # clojure-uk (24)
- # clojurescript (95)
- # cursive (9)
- # data-science (3)
- # datalevin (2)
- # emacs (11)
- # etaoin (9)
- # fulcro (1)
- # graphql (4)
- # jobs (8)
- # lsp (66)
- # malli (10)
- # missionary (3)
- # pathom (4)
- # polylith (67)
- # releases (3)
- # reveal (2)
- # shadow-cljs (53)
- # spacemacs (2)
- # specter (1)
- # sql (1)
- # tools-deps (6)
- # vim (4)
- # xtdb (16)
Is anyone using clojure.tools.build.api with cljs.build.api/build
Seems to work. Slightly fiddly with where deps should live. Tools only uses :paths and :deps from the alias.
Cursive finds it all a bit baffling (build.clj in ./)
Did you use the tool alias as described here: https://groups.google.com/g/cursive/c/zsexm-us1sA/m/D-IKXTb0BAAJ?
This is my setup. The "double deps" seems odd to me. Perhaps I'm missing something: https://gist.github.com/olivergeorge/a7639d5dfbe6ec57818e0bed18f9f2a2
the "thematic" difference between tools.build and cljs build apis is that tools.build 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"
Thanks. That makes sense.
any advice on a good place to start to bootstrap a fullstack clojure project using deps.edn / shadow-cljs.edn?
@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.
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.
they have a template project to look at https://github.com/fulcrologic/fulcro-template
@chadhs oh! I just remember we had this in an edition of clojure morsels https://github.com/souenzzo/atemoia
that really is as simple as it gets. much simpler than fulcro
but, of course, fewer features
Hi I’m trying to use this: https://airbnb.io/visx/docs/axis#AxisBottom_children
But when I use this like so:
:children (fn [render-props]
(r/as-element [:div "foobar"]))Any ideas why that might be the case?
that breaks the code and gives the following errors:
react-dom.development.js:11103 Uncaught TypeError: _ref$children is not a functionCan'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 methodalso tried this:
[:> axis/AxisBottom
(->> {:top (+ top height)}
(merge (axis-props :x)))
(fn [render-props]
(r/as-element [:div "foobar"]))]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 https://www.youtube.com/watch?v=3HxVMGaiZbc. 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.
Found these https://storybook.js.org/tutorials/intro-to-storybook/react/en/screen/ https://storybook.js.org/docs/react/workflows/build-pages-with-storybook
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.
https://storybook.js.org/docs/react/writing-stories/decorators#using-decorators-to-provide-data seems promising
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))
238
239 (defn- access-g
240 [g cur]
241 (get g cur #?(:clj Long/MAX_VALUE
242 :cljs (goog.math.Long/getMaxValue))))
^---
243
244 (defn ^:declared diff* [ra rb came])
245
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
basically you can longer assume it exists (because some other namespace might have loaded it), you must require it and use an alias
yes all libs that depend on global requires of goog namespaces that became goog.modules are broken
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.)
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?)
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 (https://git.io/vb4yd) to the 'plugins' section of your Babel config to enable transformation.
Here is an example using expo with fulcro: https://github.com/fulcrologic/fulcro-native-template
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 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.)
I don't want to derail or anything, but have you looked at fulcro?
it supports native
they have a template you can start with, too (not sure how up to date it is https://github.com/fulcrologic/fulcro-native-template )
It's not working with the newer electron fulcro-inspect app, so it needs to be updated for the newer fulcro releases.
ahhh thanks!
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.
and this is the repo for the project itself https://github.com/fulcrologic/fulcro-native
I haven't used fulcro myself but it seems nice and it sure does support a lot of things
@dsp oh, and this too https://github.com/vouch-opensource/krell
and it seems like a much lighter thing than fulcro
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
(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)
https://github.com/athensresearch/athens seems like a decent example of a full electron + cljs app at least, as a reference point
(@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 🙂 )
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.
coffi is atm the fastest ffi for clojure (even faster than jni) at the moment, but it's restricted to only jdk 17.