Fork me on GitHub
#fulcro
<
2019-06-10
>
cjmurphy00:06:19

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

souenzzo00:06:50

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

cjmurphy00:06:33

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

cjmurphy00:06:14

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.

eoliphant00:06:23

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.

cjmurphy06:06:16

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?

tony.kay14:06:35

it starts capturing those redirected logs

tony.kay14:06:01

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

tony.kay14:06:03

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.

cjmurphy15:06:41

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.

cjmurphy19:06:09

Changing Clojure version may not have been it. I do get this excessive trace problem when use [org.immutant/web "2.1.10"], but not when use [http-kit "2.3.0"].

tony.kay15:06:26

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...)})
which was a bit of a mash-up. It eliminated a lot of redundant destructuring, but it made the lifecycle methods a bit confusing because none of them take the real props (but some get prior or next props). The use of a lambda notation implied they were lambdas, but in fact they are just syntactic notation (`fn` in 2.x can be any symbol in those). In Fulcro 3 I want to keep the special support for ident/query/initial-state, but I’m considering dropping the auto-inclusion of this on the lifecycle methods, since any library that wants to extend the options map will not have access to the same feature (there is no way for me to know if they are mean to be static or not). So, methods like componentDidMount would need to specifiy this under the new model, but static ones would not. In other words, you’d be writing them to match what would be expected from the React docs. The continues to be a little confusing because the eye (and IDE) will continue to resolve the “args” in the context of everything in the options map.

tony.kay15:06:34

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

tony.kay15:06:46

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

tony.kay15:06:55

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.

tony.kay15:06:59

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.

tony.kay15:06:24

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)] ~@body) around whatever you write. This has a runtime performance penalty, but makes the props arg closure look consistent across as much as possible.

2️⃣ 24
currentoor17:06:52

yeah option 2 seems like a nice middle-ground

currentoor17:06:09

3 is tempting but a more complicated macro is more likely to have compatibility issues as react evolves and corner cases arise

tony.kay19:06:44

Thanks everyone…glad to see that my intuition matches with general community desire.

wilkerlucio21:06:31

I like option 2 too

eoliphant18:06:17

+1 for 2 🙂. Mentally ’everything other than these 3 core fulcro keys is easy to keep track of

uwo19:06:26

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?

tony.kay20:06:02

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

🙏 4
tony.kay20:06:18

I probably should change that one to just get params period