@aron probably just a bug, the REPL we ship still needs a lot of work - but it doesn't get a ton of love since it mostly used for testing + Quick Start - other REPLs like Figwheel will probably have whatever config you need to do what you want

well I know it does since I've done exactly what you're talking about before 🙂

@dnolen heh, thanks 🙂

Hi all, I’m trying to resolve this warning I’m getting on build:

Oct 30, 2018 1:42:17 PM com.google.javascript.jscomp.LoggerErrorManager println
WARNING: resources/public/generated/js/inferred_externs.js:109: WARNING - name goog is not defined in the externs.
goog.string.StringBuffer;
^^^^

:thinking_face: is it possible to get ns-publics of a namespace at macro-time?

yes

see cljs.analyzer.api

do people prefer hiccup to s-expressions for representing html?

you’d have to quote everything if you used sexps, no? I always assumed that’s why vectors were preferred. (maybe that’s not what you’re talking about?)

you could use factory functions instead of data

(defn factory [el]
  (fn [& args] (apply react/createElement el args)))

(def div (factory "div"))

(def MyComponent
  (factory (fn [props]
             (div "Hello!"))))

macros make the MyComponent definition palateable

example: https://github.com/Lokeh/hx/blob/master/test/hx/workshop/core.cljs#L164

I guess I’d rather pass a vector and let factory sort it out rather than introduce a macro whose only purpose is to avoid quoting

:thinking_face: not sure those are the two options

I'm looking at removing the need of controlling the render tree in CLJS-land. so we should be just using regular ol' react components (functions or classes) that return react elements

in order to use hiccup, we have to use a macro to convert [:div "blah"] to (react/createElement "div" nil "blah")

we can avoid macros by using factory functions instead

defining components already needs some macro-ness to remove the boilerplate for converting props into clojure maps

so it's easy to also add, "create the factory for this component" to the macro anyway

I would avoid complications

I would argue - stick with Hiccup syntax and do this without macros

on a current project the benefit is it’s way easier to interact/debug hiccup then React stuff

for React just supply some tree walking fn that becomes a no-op in Clojure

then you can share templates, and rendering hiccup serverside is a middleware-ish thing

that’s how a current client project I’m working on is set up and it’s simple and gets the job done

in Om I opted for fn calls - due to thinking about perf - but from what I’ve seen over the past almost 5 years

there’s smaller population that needs the perf

and just implementing precise reconciliation will blow away any other perf stuff you could think about

that seems like a nice, simple setup

the only thing i would like to know is what does interop look like

to me Hiccup is a local maxima - you’re unlikely to come up with something better that’s as easy to work with

the #1 thing for me is that any "component" is just a React component. not a special CLJS-only thing

right that’s how Om works

but I don’t really think it’s that important

I suppose if perf is not important you could parse the hiccup in the render function?

anyways I’m just telling my opinion after doing this stuff for a while now 🙂

I do appreciate it. It is making me question myself

the React hook thing rules

I looked at your repo

I think everything you’ve done is fine

don’t do compile time stuff

no macros, just walk run time

and no-op in Clojure

OK, I'll explore that and run some experiments 😄

thought: offer a macro if the hiccup is really static and then just opt in if you need it (?). i just happen to work in an environment where this kind of overhead is never the performance bottleneck

my experiments are all in https://github.com/Lokeh/hx right now. currently, it's very macro heavy

yeah if you drop macros, I think everything will become simple and easy to implement

hx.react/c is the hiccup compiler macro. I could move that to runtime and it would probably simplify things

I also suspect with transducers the performance hit won’t be that meaningful client-side

remember that vectors < 32 items are inlined into the source

and transducers will just loop over that single internal array

I think that having a macro for defining components will still be needed. marshaling props into CLJS data structures is not fun

why do you need to marshal props with React Hooks?

unless I missed something

it's not specific to react hooks, but react components in general.

(defn my-component [props] ;; <-- props is a JS object
  (let [name (goog.object/get props "name")]
    [:div "Hello, " name "!"]))

I would prefer to shallowly convert it to a CLJS map so that it could be destructured, etc.

same thing for passing in props to components. you can't pass in just a map to a React component as props because it introspects & manipulates the props and expects it to be a normal JS object

yeah thats my concern about hooks as well. the inputsAreEqual function that checks the extra inputs argument doesn't support CLJS equality semantics which may be annoying to work around

hope they expose something more low level so we can create our own hooks

@lilactown hrm when do they introspect props? So hooks does or doesn’t support plain old fns?

I’m talking about plain react-component-as-a-function. no hooks yet

e.g. they add a children prop

but if the react component is a fn when do they have a chance to touch props?

(sorry I really don’t know, I didn’t see anything like this when I looked at what they wrote up)

I haven’t tried it myself - so missing details here

(defn example [props]
  (react/createElement "div" nil (prn-str props)))

;; rendering:
(react/createElement example {:name "Suzy"} "asdf")

#js {:meta nil, :cnt 1, :arr #js [:name "Suzy"], :__hash nil, "cljs$lang$protocol_mask$partition0$" 16647951, "cljs$lang$protocol_mask$partition1$" 139268, :children "asdf"}

it gets weird

react/createElement copies the object but you can just create the element object directly instead which skips that copy

:thinking_face: color me curious. what do you mean?

there was a babel plugin that did that. forgot the name though

@lilactown but does React actually need that children?

you props doesn’t use it

so even though it mutates the top level wrapper of the persistent data structure

doesn’t matter since nobody is ever going to look at field

if example did need to access children, though?

“if a tree falls in a forest …”

why would it need to?

you wrote it!

I think there are many times when people want to use the children prop 😅 unless I’m missing your point

in ClojureScript???

sure

I can’t think of any times where I needed that

the only time I dealt with children was when I was writing Om

and it was annoying

are you saying that you don’t see the point of being able to render an element passed in as a prop? or that you just don’t use React’s children prop to do that?

the former I can’t agree with. we do that a ton at work to share styling and logic

I just don’t understand what you’re trying to achieve?

[:div props children...]

that’s hiccup

since you want to walk this structure anyway

I don’t see why you cannot set up the transformations when you need them - if they’re required

I want to do this:

(defn example-2 [{:keys [name children]}]
  (into 
    [:div 
      [:div "Hello, " name "!"]]
    children)

(defn app [_]
  [example-2 {:name "Uma"} [:div "I'm a child"]])

that’s the API I want

well IMO that doesn’t really seem reasonable, since that’s not hiccup

hiccup doesn’t have implicit splicing like that

you mean children passed in directly into the vector?

but also you could do that with syntax-quote

I would argue for thinking harder about whether you really want children

it’s worth looking around at how people actually use Reagent or even Om Next, we don’t pass around children

feels like a JS-ism to me

into would work like you’ve changed it up there

I don’t want to get caught up with into/quote-splicing/etc.

but again, I’m skeptical

the point is that I want to be able to read props and pass in props to any React component just like in JS

this just seems more idiomatic and in line with what Hiccup intends

or into

I’m just saying I don’t know why you need to carry over the children pattern thing

I like that

my point is that it still requires some special marshaling of the props received by the function before we can destructure it like that

(defmacro defnc [name props-bindings & body]
  `(defn ~name [props#]
     (let [~@props-bindings (hx.react/props->clj props#)]
       ~@body)))

I still don’t follow that part either?

why do you want to convert JS to CLJ?

I guess, ultimately, I’m trying to maximize the ability to interop with the React ecosystem. I expect that the props# will be a normal JS obj. so I could e.g. pass this in to a HOC I installed from npm

likewise when I write [MyComponent {:foo "bar"}], MyComponent could be a React component written by me in CLJS or one I installed from npm and I don’t have to care

right but this seems backwards to me

you wrote it in CLJS first which is never “just going to work” with JS

so it seems to me you should write this stuff CLJ first

JS users 2nd

(unless of course you want to limit the audience to CLJS bootstrapped or something like that)

I’m thinking of it from the perspective of a CLJS user trying to consume JS components. adopting JS semantics I think greatly helps with the frustration I have had with reagent

and I don’t think it’s that costly. maybe I’m wrong

the React ecosystem has components, frameworks, new features, devtooling, etc. that I could be leveraging but there’s friction due to too many things that are “CLJ-first”

I’m trying to find a balance that allows me to be the most productive

I’d say I’m on the fence about the JS components

shimming them is generally a reasonable amount of effort

and a lot of times you need to think twice anyway - they’re huge dependencies

but ok

probably the only suggestion I would say would be to think about separating the couple of useful parts you will need to build

i.e. the fast runtime walker that converts hiccup -> React components - which is generally useful

and the sugary stuff

in the implementation you were talking about before, do you walk the whole tree? or just the body of a component?

I would just walk the body of a component

since that opens the door for someone who wants to do a reconciler with precise updates

gotcha.

React hooks definitely opens the door to doing a lot of stuff in a more lightweight way for ClojureScript

@lilactown out of curiosity, what react tooling and libraries do you find you can't do without, and which are frustrating to integrate with reagent? I ask because I've yet to start my first non-toy reagent project to get a feel for the real-world work experience with it, so I'm curious about the pitfalls, as so far I like the feel of it better than react itself

Anything involving HOC or render-functions

E.g. we wanted to use apollo

And react spring

clojure.spec.test.alpha/check gives me back a seq of map with keys: (:spec :clojure.spec.test.check/ret :sym) is this planned for clojurescript as well? I’d like to see if my num-tests argument propagated correctly (which does not seems to work in planck).

@borkdude We recently ported all of the Clojure spec changes to ClojureScript, so it may be worth checking to see if master has that new behavior

gonna try

For reacters here, would you consider the Redux store a kind of an atom? Or agent? Or something else?

it’s very similar to an atom. the difference is that your app automatically re-renders when it’s changed, and you (usually) dispatch a named action instead of a direct state manipulation

it’s quite easy to build the reducer pattern that redux popularized on top of an atom

re-frame is pretty much our “redux” for reagent codebases and it works off of a single atom, and you dispatch actions and subscribe to it much like redux