This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-03
Channels
- # adventofcode (151)
- # asami (34)
- # babashka (43)
- # beginners (111)
- # cider (2)
- # clj-kondo (6)
- # cljdoc (12)
- # clojure (140)
- # clojure-australia (10)
- # clojure-europe (14)
- # clojure-france (5)
- # clojure-gamedev (5)
- # clojure-nl (4)
- # clojure-uk (10)
- # clojurescript (20)
- # community-development (9)
- # conjure (1)
- # core-async (4)
- # cryogen (3)
- # cursive (2)
- # datomic (17)
- # emacs (9)
- # events (1)
- # fulcro (27)
- # juxt (8)
- # kaocha (2)
- # lambdaisland (14)
- # off-topic (23)
- # pathom (37)
- # pedestal (2)
- # re-frame (8)
- # reagent (8)
- # reclojure (9)
- # reitit (5)
- # reveal (34)
- # shadow-cljs (27)
- # spacemacs (10)
- # tools-deps (123)
- # vim (28)
- # xtdb (17)
@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?
My pleasure
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?
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?
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
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 understand. I will see what can I do.
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.
Can we go with a 9? I don't want a matching stroke, and I'm doing the same for autogenerated forms
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.
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)
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.