Clojurians Log v2
fulcro
@tony.kay I made a pull request to fix this.
good catch, thanks for the patch!
Fulcro 3.4.6 released with the patch ^^^ @mroerni
@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?
yep
hooks are avail and working
have been for a while
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?
I understand. I will see what can I do.
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.
@tony.kay have you discussed ☝️ with #cljdoc or should I ask for possible solutions there?
I have…I’ve given up on cljdoc
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
But I’m tired enough of it that it is officially unsupported 😉
Ok, understood. Thank you!
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?
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
So, I’m thinking: it’ll magically start working some day, and is “some else’s problem”
I don’t want to have to worry about it every time I push a release
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.
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.
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.
How about you pass all functions as computed-props to the child?