@souenzzo You can require: [com.fulcrologic.fulcro.algorithms.tempid :as tmp], then use (tmp/tempid).

I cant. It's on #?(:clj block only

tempid.cljc can be directly required from another (your) .cljc file.

In the source of tempid.clj there are two defn tempid, one in a clj block, and the other in a cljs block. By 'block' I mean #?(:clj: ...) or #?(:cljs: ...) form.

hi, anyone know how to provide a custom root for a workspaces fulcro-card? I want to have all my components wrapped by my theme provider.

Something about fulcro3 introduces a lot of trace, example: 16:51:18.237 [Datomic Metrics Reporter] DEBUG datomic.process-monitor - {:event :metrics/report, :phase :begin, :pid 29804, :tid 48}. How to change the trace level?

@cjmurphy Ah…Timbre

it starts capturing those redirected logs

either that or slf4j ended up as a dep with a real logger plugin

See the lein template on F2 for deps you can include to make sure everything gets sent to timbre, then you can do a timber/set-level! or blacklist certain nses.

In project.clj (this project uses just lein) I changed to [org.clojure/clojure "1.10.0"] (was [org.clojure/clojure "1.9.0"]), and all the trace went away.

ok

So, I want some feedback about a particular issue, esp from long-time users (@currentoor @wilkerlucio @mitchelkuijpers etc.). The defsc macro in 2.x tried to close over this and props where it made sense in the things it directly supported (e.g. ident, componentDidMount, etc) so you can write:

(defsc Comp [this {:keys [some-id]}]
 {:ident [:table some-id]
  :componentDidMount (fn [] ...this...)})

but dropping any “special” support except for the core query/ident/initial-state also means that you can use new React ones as they appear over time in that library without needing me to change anything in Fulcro

(actually, that’s already true…it would just be consistent)

There’s one other thing I could do that would be undesirable in my opinion, but would at least make things more consistent: I could rewrite the bodies of the lamdas to expand props with your arg list destructuring so you could actually use the args…I like that for the consistency aspect, but dislike it from the “extensible” and “did you really pass this as the first argument to that???” aspect…so I don’t really like that option very much.

I could also just make the thing non-magic. Make a new macro that looks more like plain def (no args list) and you repeat things in the various places. I dislike that because it is uselessly repetitive, and requires a lot of porting effort to use.

So, if anyone has addl suggestions let me know, but perhaps ppl could vote for their preference of these options with Slack reactions: 1. Make it work exactly like it does in 2.x (arg list of defsc is used “as much as possible” in lifecycle methods…mostly this) 2. Keep functionality of query/ident/initial-state, but make everything else unrelated to the defsc arg list (e.g. you’d write :componentDidMount (fn [this] …)) 3. Expand the defsc arg list support into non-static react lifecycle methods so that the defsc props arg/destructuring is available whenever possible (e.g. rewrite your lifecycle bodies to have a (let [props-arg (comp/props this)] [email protected]) around whatever you write. This has a runtime performance penalty, but makes the props arg closure look consistent across as much as possible.

does the initial-state lamba have access to this from the defsc. The syntax makes it look like it closes over, but I'm thinking initial-state is run before the component instance is available, no?

correct. :initial-state is a static…it is passed the class, not the instance

I probably should change that one to just get params period