Fork me on GitHub
#fulcro
<
2020-12-03
>
tony.kay00:12:40

Fulcro 3.4.6 released with the patch ^^^ @mroerni

👍 6
Jakub Holý (HolyJak)14:12:15

@tony.kay I guess this is outdated > 3.5. Basic UI Components > Fulcro supplies a defsc macro to build React components. This macro emits class-based React components (hook support is coming soon, but does not work with defsc).  since hooks are already available?

tony.kay01:12:57

Thanks for the patches. published update book

tony.kay14:12:25

hooks are avail and working

tony.kay14:12:32

have been for a while

Jakub Holý (HolyJak)19:12:30

I see https://cljdoc.org/d/com.fulcrologic/fulcro/3.4.6/ has failed to import correctly and lacks namespace docs. Is that a known issue?

Björn Ebbinghaus19:12:01

There is a #js in com.fulcrologic.fulcro.components/factory for which there is a custom data_reader for the clj environment. Seems like the analyser can’t deal with it.

👍 3
Jakub Holý (HolyJak)19:12:44

@tony.kay have you discussed ☝️ with #cljdoc or should I ask for possible solutions there?

tony.kay19:12:17

I have…I’ve given up on cljdoc

tony.kay19:12:50

it just didn’t support enough general cljs, and it was eating my life trying to get it to work. I’m done with it. You’re welcome to try

tony.kay19:12:14

But I’m tired enough of it that it is officially unsupported 😉

Jakub Holý (HolyJak)20:12:40

Ok, understood. Thank you!

Jakub Holý (HolyJak)20:12:10

Is the underlying problem that it tries to analyze cljs code from Clojure? Do you perhaps have examples of other issues you experienced? Or perhaps I can just search #cljdoc archive for your messages?

tony.kay22:12:41

yeah, search. I don’t remember, but I did ask abt it. Basically if you do anything remotely unusual in cljc or cljs, it can’t handle it

👍 3
tony.kay22:12:20

So, I’m thinking: it’ll magically start working some day, and is “some else’s problem”

tony.kay22:12:32

I don’t want to have to worry about it every time I push a release

Jakub Holý (HolyJak)08:12:32

I understand. I will see what can I do.

Björn Ebbinghaus22:12:43

Is there a nice way to merge component data with an optional/missing key? I have a component, that joins with another component with an ident. This part is optional, but I get ugly warnings in my log because of it.

Adam Helins23:12:44

I guess the answer is 11, but on a scale from 1 to 10, how evil is this: passing a parent component (`this`) as a child to its own child so that this child can easily transact on the parent? I think I'm having a stroke.

Björn Ebbinghaus23:12:22

How about you pass all functions as computed-props to the child?

3
JAtkins00:12:32

Can we go with a 9? I don't want a matching stroke, and I'm doing the same for autogenerated forms

tony.kay01:12:02

This is a normal React pattern: callbacks, as @mroerni said. You don’t code a transaction for the parent’s data IN a child. That is a broken abstraction. You pass something like onClick or onDelete in computed props, and code the transact IN the parent.

tony.kay01:12:28

A parent MUST know something about children (because it lays them out, and gets thier props), but a child should not be explicitly coupled to knowledge of the parent. Technically passing this does not break that abstraction, but as soon as you use it, I bet it does…because you’re going to do things like call mutations (parent-thing-delete) (which can imply the type of parent, or introduce a type dependency)

Adam Helins11:12:13

Indeed, this little thing was more of an intellectual challenge. However, I typically have a quite a lot of grandchildren somewhere which have well-defined behavior and whose mutation also act on some "main" parent. They are specific enough to have the ident of that parent in their query or passed as props and act on their own. I consider that most of the time, a child should not know the exact type of its parent but it sure can expect it to conform to some contract. A child knows in what context it is supposed to be used.