This isn't really a solution because you might need a qty on this. E.g. a recipe needs four slices of bread, and you want to link to the bread recipe. You could add a virtual attribute to the recipe itself (e.g. include :line-item/qty via resolver tricks).

It would be nice to have an example of Categories/subcategories showing how that would be solved, or even a different recipe that you could link to.

[:ui/children-visible? :category/id :category/label :categoy/children ...]

Remember that the important point for this case, which is hard, is the intermediate "line item".

This is the tough one, and the way to classify this one is that the recursion is not like categories or filesystems because the recursion is offset by at least one. E.g. A file IS a directory, so directories containing files can be modeled as an immediate parent/child relationship and simple recursive queries work without any effort.

With the recipes, a recipe has line items which include a quantity, and the line item contains an ingredient or recipe...so the recursion is offset by an intermediate element.

Note that this one is doable with just recursive queries...no need for the fancy dynamism.

This is only partially accurate. It is true that props are relative, and that joins on keywords are relative, but any component that has a reified data path can query by ident or link ([:root-key '_]) to see anything at the root (tables, root keys).

Perhaps "such a graph query"

Perhaps: All of the critical features from network interaction to rendering optimization are easily customizable..

Sounds a bit over-stated, esp in writing.

awkward in written form...

You might consider talking about merge-component! first, since it is a load! without networking. Then it is easier to explain that load is just merge-component that obtains data from the remote.

Not quite correct. The call (m x) returns the expression itself as data. (m x) => (list 'm x)

Interesting note: Initial state is essentially the props you want to get passed on the first frame. The fact that we have idents on components means we can normalize such a tree to get what we need.

A mutation is always capable of both local and remote behavior. So, the Remote? decision isn't an "If" but more of a split where one side goes through a "Remote?" gate.

Diagram should have an arrow where tx puts things back in client db.

I'd note that this is not part of Fulcro's query engine, but instead a useful invention of Pathom. As far as Fulcro is concerned this are just normal joins. It has no knowledge of the magic.

Might want to point to the portions of the book that explain the merge behavior for this case. Most ppl have not thought about this scenario very deeply, and assume Fulcro just blindly merges or overwrites, neither of which are true.

So, my intention is for the transaction processing to be able to batch loads (which is a trivial upgrade to the current system). I consider writing a component to do that job to be a problem. I always issue separate loads in this situation. If you need request-combining, it could be a nice contribution to the lib. Be glad to explain how to do it.

This is only necessary if the component in question is part of the actual initial state. Components whose data is dynamically loaded typically do not have I.S.

Shouldn't this just be an empty array?

They actually are react components (or if you use hooks they're functions with added attributes at the js level). Really, the main thing this does is allow you to add an open-map of options that are carried around with the component, some of which are defined/used by Fulcro itself. Primary among them will be the query/ident/initial-state entries.

The concept you're looking for are Pathom connect inputs: Declaring what data you need in order to be able to run is the correct model. It is query-like. See Pathom Connect ::pc/input.

Pathom can then use the context of the items in context to resolve the data you need, even if it is not in the UI query.

Probably a good idea, since the server could be node, so CLJS/CLJ cond readers are insufficient.

This case is already handled by how I've modelled the controller/auth. You'll never reach a form route without first being force to authenticate.

This is an interesting case that I see utility in for a case like "I'm an employee that wants to give a customer a refund, but I need manager approval". But again, mixing this into a single model of things makes a mess. I'd rather see us extend the map of attributes to include this on special keys like ::authorization/promotable ...

Correct: This case is a pure security concern, and failure here indicates hacking more likely...having a server 500 is fine. Screw em.

Authentication (logging in) is a separate concern, which is handled by the controller/auth system in the UI. It analyzes the query for the authorities that own the keys, and auto-trggers login before any actual queries run.

Remember that queries will run on resolvers, which technically resolve an edge. A single resolver could resolve one attribute or a whole subtree. As a result these kinds of protections on the server are a post-processing step that walks the entire result and redacts information.

Validation happens at the attribute interaction layer...as events happen on the UI, or as triggered by other subgraph processing logic (full-form validation).

Save logic needs to be applied at the server layer on a delta (flat map keyed by ident, with attribute changes).

I'd much prefer that we avoid multimethods. They cause code bloat in CLJS because they do not allow DCE...so if you had a library of them it could make builds quite large.

I don't agree with this statement. They share some overlap in implementation, but are conceptually different. I'm game for considering an API that tried to eliminate boilerplate on implementation, but I'm not super excited about completely mixing these concerns.

I like this idea or having a set (and it should be a set) of the fields that are affected.

This para.....