This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-09
Channels
- # announcements (5)
- # babashka (1)
- # beginners (116)
- # calva (139)
- # cider (11)
- # clara (2)
- # clj-kondo (13)
- # clojure (247)
- # clojure-dev (18)
- # clojure-europe (5)
- # clojure-france (2)
- # clojure-italy (2)
- # clojure-nl (7)
- # clojure-spec (24)
- # clojure-uk (34)
- # clojurescript (41)
- # cursive (11)
- # data-science (2)
- # datomic (33)
- # emacs (10)
- # events (3)
- # fulcro (134)
- # graphql (9)
- # jackdaw (3)
- # jobs (1)
- # joker (20)
- # kaocha (3)
- # leiningen (7)
- # luminus (2)
- # malli (3)
- # music (1)
- # pedestal (7)
- # re-frame (25)
- # remote-jobs (7)
- # ring (7)
- # shadow-cljs (85)
- # spacemacs (13)
- # testing (2)
- # tools-deps (60)
- # xtdb (11)
- # yada (7)
if you using deps.edn
you can use: https://github.com/Olical/depot
@thheller I’ve got an additional “hint” on that weird tagged literal leaking to transit write while compiling: It seems to happen when I’m using deps :local/root
. I switch between that and normal version when working on Fulcro bugs. It does it under the following conditions (so far, these seem the only way I get it): Build target is :react-native
, and I’m using a dependency that has heavy use of CLJC through :local/root
in deps.
Confirmed. If I put Fulcro out as a SNAPSHOT and use :mvn/version, then I don’t get the shadow-cljs exception about the tagged literal
@tony.kay can you try with the latest version? I added an additional try/catch that should assist with debugging
then it should be printing the full EDN data (in the server log, so don't start in the background)
:transit-str
{:depends-on []
:start
(fn []
(fn [data]
(let [out (ByteArrayOutputStream. 4096)
w (transit/writer out :json)]
(try
(transit/write w data)
(.toString out)
(catch Exception e
(log/warn-ex e ::transit-str-failed {:data data})
(throw e))))))
:stop (fn [x])}
email? <mailto:[email protected]|[email protected]>
Seems like this function from Fulcro is confusing it:
(let [update-fn (fn [component f args]
#?(:cljs (.setState component
(fn [prev-state props]
#js {"fulcro$state" (apply f (gobj/get prev-state "fulcro$state") args)}))))]
(defn update-state!
"Update a component's local state. Similar to Clojure(Script)'s swap!
This function affects a managed cljs map maintained in React state. If you want to affect the low-level
js state itself use React's own `.setState` directly on the component."
([component f]
(update-fn component f []))
([component f & args]
(update-fn component f args))))
and I do get a warning about .setState
…it’s the warning thta is being passed through:resources 269, :compiled 4, :warnings [{:source-excerpt {:start-idx 452, :before [" (get-in cst (if (sequential? k-or-ks) k-or-ks [k-or-ks])))))" "" "(let [update-fn (fn [component f args]"], :line " #?(:cljs (.setState component", :after [" (fn [prev-state props]" " #js {\"fulcro$state\" (apply f (gobj/get prev-state \"fulcro$state\") args)}))))]" " (defn update-state!" " \"Update a component's local state. Similar
:extra {:warn-type :target, :form (. component setState (fn [prev-state props] #object[cljs.tagged_literals.JSValue 0x7713c25e "cljs.tagged_literals.JSValue@7713c25e"]))}
:extra
is warning data and the :form
it warns about is probably something like (fn [prev-state props] #js{:foo ...})
with :local/root
the :infer-externs :auto
logic kicks in and starts warnings about stuff
I’m also seeing warning that make no sense to me when using react native target. When I use (:import [
and then use something like (.-EXCEPTION ErrorCode)
without a ^js
meta marker I get a warning about Cannot infer target type in expression (. ErrorCode -EXCEPTION)
…I expected imports to “just work”
@tony.kay both issues should be fixed in [email protected]
When I use instaparse and require instaparse.core from a cljs project using shadow-cljs, I see a bunch of warnings. However, they all seem to come from :clj portions of feature expressions (or whatever we call them these days in clojure). Is anyone else familiar with this, or understand why it might be happening?
(the warnings all originate from java stuff that is meaningless in cljs, which is why presumably they're in :clj blocks instead of the :cljs part)
------ WARNING #3 - :protocol-invalid-method -----------------------------------
Resource: instaparse/gll$macros.cljc:51:4
Bad method signature in protocol implementation, CharSequence does not declare method called charAt
The required namespace "instaparse.macros" is not available, it was required by "instaparse/core$macros.cljc".
"instaparse/macros.clj" was found on the classpath. Should this be a .cljs file?
(what I mean is, I use self-hosted for a REPL I've implemented, but I don't need to use instaparse in the REPL)
the :bootstrap
build is controlling what is available to use in self-hosted code eval'd in the browser
Ok, that makes sense. I'm sure you're right - entries includes my core namespace, and I included instaparse there.
yeah, only include namespace there that you want your users to be able to actually use
Sure. I mean honestly in my ideal world they could use any namespace. But I understand that cljs has limitations in this regard.
not sure if some adjustments could fix it for instaparse, might be possible to get that working but not sure. could also just exclude the macros.
Sure. And I'm sure there are many subtleties I don't understand. I still hope someday we end up in a completely self-hosted cljs world. But I'm not sure we're ever really going to get to "clojure in clojure" like Rich used to talk about a decade ago.
self-hosted will always mean that the build is gigantic which makes it a no-go for most apps
I understand. I expect that to be less and less of a problem in the future, especially for certain classes of apps.
https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 explains pretty well why it likely won't change until some major breakthrough in the "mobile" world
This looks interesting, and I will read it, but talking about performance budgets loading CNN on mobile phones doesn't speak to what I'm talking about. That's why I said "for certain classes of apps". I don't think a news site on a random phone is exactly in the domain of having a self-hosted REPL which you can use to write code at runtime. Anyway, this is almost certain outside the core of shadow-cljs
discussion. Thank you for the article - I will finish reading it.
sure certain apps don't care much about size. just saying that a "completely self-hosted cljs world" is not even a goal at this point, at least shadow-cljs will never go there.
I'm sure there is a lot I don't understand about the cljs compilation world, but since shadow-cljs isn't the compiler or the runtime, I didn't expect that being a goal or not was contingent on shadow-cljs's perspective on the relative importance of being completely self-hosted.
not sure how to answer that. all I can tell you that if you want something completely self-hosted without a JVM required then you'll never find that in shadow-cljs
Sure, I'm sure you're right, and I don't think it seems to currently be a goal for the clojure folks either at this point.
maybe once a full JVM can run in WASM 😉 but then we'll be north of 100MB which makes it even less of an option 😛