This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-28
Channels
- # announcements (33)
- # aws (2)
- # babashka (14)
- # beginners (128)
- # calva (34)
- # cestmeetup (3)
- # clj-kondo (12)
- # cljdoc (3)
- # clojure (114)
- # clojure-europe (31)
- # clojure-italy (3)
- # clojure-nl (7)
- # clojure-uk (6)
- # clojurescript (35)
- # conjure (20)
- # cursive (3)
- # data-science (3)
- # datomic (16)
- # docker (13)
- # events (1)
- # figwheel-main (22)
- # fulcro (109)
- # jobs (1)
- # kaocha (8)
- # keechma (1)
- # lambdaisland (5)
- # malli (1)
- # meander (8)
- # mid-cities-meetup (1)
- # off-topic (6)
- # overtone (7)
- # pathom (6)
- # re-frame (2)
- # reitit (9)
- # ring (1)
- # shadow-cljs (92)
- # specter (1)
- # tools-deps (311)
- # xtdb (76)
@sova load-file in clojurescript doesn't seem right. what's wrong with require? I think the key is to remove any references in the cljc file to anything in the cljs file. is this project open source? it's hard to talk in the abstract about how to fix the dependencies
my main problem is that rum/defc is a macro that is used to define components for the serverside and clientside, but i cannot -- i don't know how -- import these variadic rum/defc component definitions. this pretty much makes the .cljc file useless in trying to be cljs/clj compatible. imagine the cljc file has a call
(rum/defc page-header [room-name]
[:div room-name])
how would one import this .cljc result into a .cljs file?if defn
is there, you just use :require [vector of the functions]
but if it's a custom macro, with a custom name... what to do
Have you ever defined a component in a cljs file and then used it in another cljs file?
have never had the need, figured it would be possible if necessary, it's the exemplar use case for cljc and it doesn't seem to be possible
@sova I’m not sure I understand yet. vars defined by defc
can be referred just the same as any other
ex if you have some namespace:
(ns my-app.feature
(:require [rum.core :as rum]
,,,))
(rum/defc page-header [room-name]
[:div room-name])
and then elsewhere,
(ns my-app.something-else
(:require [my-app.feature :as feature :refer [page-header]]
,,,))
;; use the page-header here
I found a difference between clojure and clojurescript:
(into nil nil)
; clj=> nil
; cljs=> ()
Is it to be expected or fixed?
I tested via Kaocha. I will test again tonight, manually.
I just tested via shadow-cljs and it returns nil. There must be something wrong with by kaocha setup.
The problem was Kaocha is using a version of CLJS by default which does not contain the fix to this bug. Not a problem related to the latest CLJS.
An easy fix was to add a dep to the latest CLJS in my project.
What is current best practice for cljs library development. When you also want a final artifact to be available on NPM for JS users. It obviously needs to be the minimum size possible. I’m assuming figwheel.main is the way to go??
@grounded_sage those are really 2 completely separate questions. for CLJS lib you just publish the lib to clojars, no compiled code at all. lein works best IMHO. for npm you actually build the project and publish only the compiled code to npm, no sources. shadow-cljs has :target :node-library
to make that easy. for figwheel I don't know, may require a bit more work. use :advanced
to keep it as small as possible although small is relative given that it will contain a minimized version of cljs.core
.
Cool. Yea I was wondering whether to move to tools.deps. Currently assessing between cljs.main, figwheel.main and shadow-cljs. Trying each of them out. Already familiar with shadow so seeing how the rest compare.
funny to see htis now, @grounded_sage -
I just wrote up a little guide for how to publish a namespaced dependency if cljsjs is slower to merge your PRs
ah, sorry, my eyes did a double-take at CLJS
Hey all. I'm testing out node initializers and made this: https://github.com/chr15m/create-shadowfront Which you can use to very quickly bootstrap a Reagent application like this:
npm init shadowfront myapp
cd myapp
make watch
then browse to http://localhost:8000/ and http://localhost:9630/
Would appreciate any feedback!just did a quick glance. the template shadow-cljs.edn shouldn't have these two lines
https://github.com/chr15m/create-shadowfront/blob/master/template/shadow-cljs.edn#L7-L8
@lilactown thanks a lot, i am now wondering how i can call the main socket-sending function in sente (chsk-send! [:event data])
from the cljc file. it seems like it operates as two separate instances if i simply replicate the code to .cjlc ... how can i have my socket sends from my ui work when moved to cljc land?
resolved. looks a little cray. but it works. moved the socket definition into the cljc with reader conditionals, and used refers to include them in the client.cljs it was not possible to use a let and nested defs, i had to explicitly make some keys happen
#?(:cljs
(def ma-sacket (sente/make-channel-socket-client!
"/chsk" ; Must match server Ring routing URL
?csrf-token
{:type :ajax ;rand-chsk-type
:packer :edn})))
#?(:cljs (def chsk (:chsk ma-sacket)))
#?(:cljs (def ch-chsk (:ch-recv ma-sacket))) ; ChannelSocket's receive channel
#?(:cljs (def chsk-send! (:send-fn ma-sacket))) ; ChannelSocket's send API fn
#?(:cljs (def chsk-state (:state ma-sacket))) ; Watchable, read-only atom
that lives in a .cljc file and the functions are called by name so it's all groovy. thanks for your help everyone! @dpsutton @lilactown
Hi all! Curious to know if people have ported their Clojurescript web app to re-natal (react native)? What was your experience in doing this? Our web app uses reagent and re-frame. My guess is that the logic would remain the same except we would have to change how the UI is rendered? Thanks a bunch for your help!
I think at this point shadow-cljs, figwheel, or krell (I work on it, still pretty alpha) are better options if you're going to do React Native - I think doing RN is a lot more effort than it sounds like - while the situation has improved greatly - I think you should expect to become familiar with some aspects Android / iOS development.
I see, ok. Thankfully, we have some prior experience with Android but none with iOS. So, fingers crossed. I think we’ll try to port a small part first using shadow-cljs and see where it takes us. Thanks a bunch!
The problem was Kaocha is using a version of CLJS by default which does not contain the fix to this bug. Not a problem related to the latest CLJS.