Hello! Does (def x) actually do anything, aka does it get translated to a line of code in Javascript?

what do you guy use for css-in-js in clojurescript?

I've had success wrapping emotion

oh okay.. I guess you didn't try cljss

would it be possible to create a Clojure namespace and intern a var at macroexpansion?

clojure yes, cljs no. see create-ns

hmm. I specifically want to do this when using a macro in a CLJS file

(ns my-app.core
  (:require [hx.core :as hx :refer [defnc]])

(defnc MyComponent []
  (d/div "foo"))

(defmacro my-component []
  `(create-element MyComponent))

it's probably way too complicated but I'm just trying to cut down on boilerplate

for that to work the user would need to have (:require-macros [app.core]) in app.core

yeah, and it's in a weird state because the macroexpansion would have to happen before resolving the macro ns which is... not how it works

I thought you are creating function components? why not defnc my-component emitting a (defn my-component?

the components are defined as functions, but you don't want to call them as functions. you need to create a React element from them

isn't that what you fragment macros does? I mean [my-component {:foo "bar"}]?

right, if you use hiccup syntax you don't really need to worry about it

I'm playing with getting rid of hiccup syntax and using factory functions or create-element directly

ah ok

($ MyComponent) or (defn my-component [] ($ MyComponent))

no matter what I try, I feel like I concede either interop, performance or ergonomics. I hate hiccup but going back to factory functions maybe isn't really better?

guess why I'm writing my own stuff? trying to make react happy sucks 😛

😂 yes trying to follow the JS ecosystem is painful

maybe I am suffering from sunk cost fallacy at this point

one thing I experimented with was a macro emitting a my-component defn which would be the factory fn. it would then emit a secondary "hidden" function that you could get to when needed by calling @my-component

basically using specify on my-component to implement IDeref

oh that's neat!

that kinda worked ok since you very rarely need the actual function for much

assuming of course no hiccup syntax 😛

yeah, the way I do factory functions right now is it specifies a custom protocol that does something similar

(hx/type my-component) ;; => the actual Component type (class/function)

the thing I am trying to avoid is defining a map that just gets thrown away

if I use a factory function, then the props that get passed: creates a map, turns it into a JS object, then React takes that JS object and copies when it creates the element...

I have a macro that, when used, will always emit a JS object instead of creating a map. but it's tedious to create factory macros in a separate file

geez no don't turn them into a JS object

mine would do (defn my-component [props] (react/createElement my-component* #js {:secret$props props}))

and the component would access that secret$props. never actually translating to JS object

that works, except when you are working with: 1. native elements 2. a lib that expects to be passed Component

native components don't ever go through those factory functions so thats not a problem

things that expect a Component would get @my-component which would do the js->clj

ah

let me see if I can find that code somewhere ... I'm sure its in some branch somewhere

can't find it but note that I opted out of that approach because it generated too much code

so it isn't exactly ideal to generate 2 functions with a bit of boilerplate per component

yeah good point