@richiardiandrea :no-transpile doesn't mean anything at all. if you set :output-feature-set :es-next it will leave all features the GCC supports as they are. it will not "transpile" them. features it does not support will still break. we always NEED to process the code and at least change the require/import/exports. so no there is no "please don't touch this JS" option. if you output "standard" javascript :es-next is as close as you'll ever get to :no-transpile.

GCC must be able to parse the code that is pretty much the only limitation currently

Sharing here on suggestion of @thheller

@pwalsh I'm using apollo client and do server side rendering on nodejs. I have chosen https://github.com/macchiato-framework and it works ok.

Shadows spec doesn't like the following destructuring syntax:

(defn pending-button [{:keys [:pending? :pending-text] :as opts
                       :or {:pending-text "Sending..."}} & children]
(...))

-- Spec failed --------------------

  (... [{:keys [:pending? :pending-text],
         :as opts,
         :or {:pending-text "Sending..."}} ... ...] ...)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

has extra input
or
should satisfy
  vector?
-- Relevant specs -------
:shadow.cljs.devtools.cljs-specs/param-list:

@fbielejec it doesn't like it because its invalid 🙂 should be a symbol

:pending-text should be pending-text (in the :or section)

and altough clojure accepts keywords in the :keys section, its also more idiomatic to use symbols there 😉

true, way more unforgiving then other compilers though 😄 It comes from a forms library

a chance to send a pull request 😄

Clojure 1.10.0
user=> (defn x [{:keys [:foo] :or {:foo 1}}])
Syntax error macroexpanding clojure.core/defn at (REPL:1:1).
{:keys [:foo], :or {:foo 1}} - failed: vector? at: [:fn-tail :arity-n :bodies :params] spec: :clojure.core.specs.alpha/param-list
({:keys [:foo], :or {:foo 1}}) - failed: Extra input at: [:fn-tail :arity-1 :params] spec: :clojure.core.specs.alpha/param-list

plain clojure 1.10 agrees (no shadow-cljs involved)

@fbielejec FWIW although it is "accepted" in normal CLJS it doesn't actually work so I guess nobody every ran into this.

cljs.user=> (defn x [{:keys [:foo] :or {:foo 1}}] foo)
#'cljs.user/x
cljs.user=> (x {})
nil

cljs.user=> (defn x [{:keys [:foo] :or {foo 1}}] foo)
#'cljs.user/x
cljs.user=> (x {})
1

+1 for shadow for specing and catching it early 🙂

hello. I'm trying to use #fulcro + react native I already had success rendering stuff like (r/createElement rn/View #js {} (r/createElement rn/Text #js {} "helloaa")) I can require (without use) fulcro.client.primitives with no errors But when I require (without use) fulcro.client it thows undefined is not a object (evaluating 'goog.loader.activeModuleManager.setDefault') it thows in goog.module.modulemanager.js:674:32 I'm using shadow-cljs + :target :npm-module

@souenzzo did you see https://github.com/thheller/fulcro-expo?

I will check this repo

setup with expo should be about the same

there is a note about the bug you see. fulcro.client.mutations requires cljs.loader but doesn't use it

the goog.loader.activeModuleManager namespace doesn't seem to work correctly in react-native but it shouldn't be required anyways

https://github.com/thheller/fulcro-expo/blob/master/src/main/fulcro/client/mutations.cljc is from fulcro master 5 days ago with just the cljs.loader require removed

forgot to open an issue about this in the fulcro repo

:target :react-native nice!

working with :target :npm-module. tnkx @thheller I will try to move into target react-native. I'm (intentionally) not using expo so it may be a little different.

there is nothing specific to expo in :target :react-native

@thheller I was looking for that ticket to add to it. I noticed a similar issue with the fulcro.client.routing namespace - it includes cljs.loader and it does use it, which broke things for me. Fortunately, the new routing in Fulcro-incubator doesn’t use it, so in the process of converting to that. I’ll add a comment when you create the ticket, although not sure Tony will want to mess with it, since I think he plans to make the new routing the default soon. Other than that everything is working great, even release build and publishing to Expo! Much better development experience than figwheel-bridge, and hot reload is much quicker, almost instantaneous for small changes like tweaking the style of a component.

One thing I’m curious about - it looks like you are handling externs/type-hints automatically with js/require, or something like that? Because I didn’t add any type hints and was expecting my first release build to have a bunch of extern errors, but it worked perfectly out of the box.

yes, there is some extra inference work shadow-cljs does

mostly about properly propagating hints on js/... calls and :require namespaces

you'll still probably want to turn :infer-externs :auto on though as it isn't 100% https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs

Well, it does a heck of a lot better job than the cljs compiler. Before switching to shadow, I tried externs inference and never could get it working right, ended up switching to using oops to access JS stuff via string name (which was a royal pain, and stinks for optimization).