Clojurians Log v2
fulcro
I'm having trouble figuring out the best way to achieve a load of my graph. At the moment i'm just thinking to do a full upfront load. I'm unsure how to apply the recursive examples to my current situation because I'm not doing any rendering and am recursing indirectly (i was thinking to seperate the components for loading and rendering to make things simpler to understand but i'm not sure if this is advisable). I'm thinking as an alternative to return references and then manually load from the global state or to somehow postprocess the load and massage the data so it's normalized properly. 🙈 clojure-spin Not really sure i'm groking it 🤔 Some input on the approach would be appreciated 🙏
(defsc ChorValue [this props]
{:query [:chor.value/id
{:chor.value/chor (comp/get-query Chor)}]
:ident :chor.value/id})
(defsc Chor [this props {:keys [render-depth] :or {render-depth 0}}]
{:query [:chor/id
`({:chor/includes ~(comp/get-query ChorValue)} {:type :include})
`({:chor/excludes ~(comp/get-query ChorValue)} {:type :exclude})
]
:ident :chor/id})
I had someone trying to do html as different component types. One per node type. The better way in that case was to include a node type and make it a single component called HTMLNode that had children as the recursive join. That worked well. You could even use a union query to split it out to multiple components, so there is a fourth option. There one more option: dynamic queries. You can change a component's query at runtime. So you can do option 3 to an arbitrary depth by autogenerating components at startup... Of course you could do the same with a macro.
But if 2 fits your case I'd do that
I’m sure someone’s written about this before. The question comes up periodically. Mutual recursion is not directly supported. In most of these cases where I’ve seen people trying this it wasn’t even actually a good idea.
Recursion in the query language requires that you self-recurse. So, you have a number of options:
1. Restructure your system so that you don’t need “subtypes”. E.g. combine the queries into a single level such that you can use …
2. Consider if normalization is actually needed. Perhaps the structure works just fine as a “chunk” of data. Are the normalized parts actually shared but different branches of the tree? If not, it might just make more sense to leave it as a tree. Normalization is just a tool, and just like in SQL databases, sometimes you choose to denormalize something for a particular purpose. Don’t get hung up on unbreakable rules 🙂
3. If you really need to give a unique identity to every CharValue, and they really are recursive and need normalization, then the workaround is to create N versions of Char and CharValue (one for each supported depth), and structure them accordingly (in other words unroll the recursion). Char ->CharValue -> Char1 -> CharValue1 -> …
a. Just give them all the same ident function
b. Yes, it’s a little ugly, and requires you define a “depth limit”…but programming languages have a limited stack size, so infinite recursion is never actually what anyone gets anyway 🙂
I'm surprised it comes up periodically. Mutual recursion that's the name. I think #2 is what i understand the most. Keeping references as data in the chunks of data that i can then access from the db
Hello! I'm getting started with a React Native project that uses shadow-cljs to compile CLJS to JS modules that I can then leverage in a TypeScript React UI. So basically state management is a Clojurescript concern and UI is Typescript. It appears as though I could minimally use Fulcro's raw capabilities and control rendering on the TS side, which I'm perfectly fine with. I did also see there are options for including JS React components in Fulcro components, but ideally I'm trying to keep the TS for UI and Clojure for state mgmt. divide. So my question is, is the raw approach the best option here or is there a way to leverage some of the Fulcro React capabilties in a TypeScript context?
Yes, chapter 19 is your friend
Actually this line here from section 19 in the book inclines me to believe raw is prob what I'm after since a decoupled UI is important to me: "This support also leads to cleaner support in Fulcro itself for creating components that are detached from the data tree"
oh wow I didn't know this is a thing now
exciting!