Clojurians Log v2

@tony.kay I created a gist on github, https://gist.github.com/carrete/fd98413cd3fb1a6b1ea649f5814e437f. This includes a portion of the actual component source, and two screenshots of the inspector showing two different server responses to the same query. The problem is triggered based on the server response. When the response to {:drawing/editor-session-ref [:editor-session/id :editor-session/pid]} is missing completely from the response map, things work as expected. But when the response is :drawing/editor-session-ref {:editor-session/id "..."} :editor-session/pid is rendered as ::merge/not-found, i.e. the function editor-session-link at the top of example.cljc in the gist returns "/svg-editor/::merge/not-found/". This is with fulcro v3.4.22 and pathom 2.3.1. This project is about a year and a half old. I'm not sure what you mean by "customized anything in the app." We didn't start with a template, though I took a lot of inspiration from the youtube videos (and my prior experience with om.next and reagent/re-frame). This has evolved quite a bit in the past year and a half, but other than including server-side rendering, I don't think we're doing anything out of the ordinary. Please let me know if there's anything else you'd like me to provide or do to help with this, perhaps create an issue on github if you think this could be a bug. Of course, I won't be surprised if you say I've done something wrong. This is also working for us now that we know how to work around this so please feel free to ignore this too. Thanks!

I can guarantee this isn’t right: https://gist.github.com/carrete/fd98413cd3fb1a6b1ea649f5814e437f#file-example-cljc-L89

you’re passing the props of one component to another, didn’t compose the query properly, and therefore the load cannot possible do the correct merge.

If the SVGEditor has a query, and is joined ot the component above it, it better darn well have a join in the parent query

This falls into the 90% category: most questions on this channel are incorrect query/ident/initial state. 😄

Thanks @tony.kay. I’ll go back to the documentation and try again.

@tvaughan perhaps https://github.com/holyjak/fulcro-troubleshooting can help to catch these problems earlier? Also https://blog.jakubholy.net/2020/troubleshooting-fulcro/ should be helpful in troubleshooting.

Thanks @holyjak

I’m curious about the right composition approach here when the parent seems to be the same entity (and perhaps the same/similar query?) as the child component. I know pathom placeholders are one option, but that doesn’t work with form state.

Same. I thought it was recommended that components which are simply different views of the same data should share the same ident, and therefore props.

I don’t think thats inherently true, as two views of the same data may expect different data (via different queries) For example, PersonView may only care about :person/name and :person/age But PersonDetailed may care about :person/name and :person/description We wouldnt want to pass PersonView props to PersonDetailed, because it’d be missing :person/description , even if they share the same ident However I’ve ran into a few situations where I’ve had multiple views on the screen all showing different fields of the same ident, and haven’t figured out a great way to modularize this in a way that plays nicely with form state + loads

Two components that use the same data should use the same ident, so that they co-exist in the db, but all component should query for their own props. If I have a row in a PersonList called PersonRow, and a form called PersonForm those two very definitely would have the same ident. That does change the fact that they would have their independent and reified path in the database One lives in a table, the other lives on a screen for editing. If you have some weird case where you want a child, but that child is using the same props as the parent, then you have two options: 1. The child is a stateless component or just a plain function. It does not have a query or ident…if it purely a function used by the parent to render some content. It doesn’t participate in I/O, etc. It is a pure rendering concern. 2. Join the child in. That is fine as well, BUT the child must be properly joined, have its own query/ident/initial state SUCH that the parent joins the child in. Now, in this case since the parent and the child are the same, it means the state of that in the db will just be a loop:

{:thing/id {1 {:thing/id 1 
               :thing/parent-fact initial-parent-fact
               :thing/child-fact initial-child-fact
               :thing/child [:thing/id 1]}}}

and the components would be:

(defsc Child [this props]
  {:query [:thing/child-fact]
   :ident :thing/id
   :initial-state {:thing/id 1
                   :thing/child-fact initial-child-fact}}
  ...)

(defsc Parent [this props]
  {:query [:thing/parent-fact {:thing/child (prim/get-query Child)}]
   :ident :thing/id
   :initial-state {:thing/parent-fact initial-parent-fact 
                   :thing/id 1
                   :thing/child {}}
  ...})

Thanks Tony > That does change the fact that they would have their independent and reified path in the database One lives in a table, the other lives on a screen for editing. Similar to the example above, how would you handle loads in this case? I feel like I end up mixing up UI-concerns (edges in my UI database) with server concerns (pathom resolvers that can resolve those edges) So I can use my UI component composition to handle my loads. I can choose to use a separate component all-together for loads, but then now I have to remember to update this LoadComponents query any time I update any of my sub-components. Is that just a trade-off we have to make for ourselves?

If you are going to load this from a server, then you have to make a resolver that understands that :thing/child is just a loopback. This is what placeholders are for in Pathom (plugin that allows you to use them without having to write a special resolver)…so whatever naming convention you use for placeholders (often > as a prefix) will make pathom work with this nesting full stack

and in that case, of course, no need for initial state since it all comes from the server.

got it Only downside of pathom resolvers is i believe form-state doesn’t understand it, but perhaps thats too much of an edge-case. (For example, I have a view where the left-side panel is a form of an entity, and the rest of the screen contains many different views / graphs of that entity)

and yes, if you want to split your UI up and have the localized queries then you have to add the pathom placeholders plugin to get it to work well. But notice you cannot even imagine doing that in stock GraphQL (well, you could add it to the schema, and the add resolvers, etc…but being able to arbitrarily do this kind of magic from the client with no backend coding is kind of magical IMO)

Ah, form state. So, I did not design form-state with this in mind, no, but that isn’t to say that it shouldn’t be capable of dealing with it

That said, in my experience you can just break it apart with case (1) (stateless children/functions) and not nest the queries.

to get around this, I added a true edge in pathom that I use for the form, and use the original edge for the other views (split up with pathom placeholders)

But I’ve also experimented with the stateless approach like you’ve mentioned

Thanks, this was helpful to talk

sure. I don’t really see how your case involves form-state? The rest of the screens has many different views?

Lets say the parent component is the whole screen The left-screen child is a form of entity A The right-screen child consists of various Views of entity A

So my query on the parent looks something like:

[{:parent/editable-A (comp/get-query FormA)}
                          {:parent/view-A [{:>/view-1 (comp/get-query ViewA1)}
                                           {:>/view-2 (comp/get-query ViewA2)}
                                           ]}]

parent/editable-A and parent/view-A point to the same entity in pathom

oh and I think form-state was involved here because the form started from the parent

otherwise it may have worked as a pathom placeholder?

Oh, I see, so your question was “how to handle loads”. There are several possibilities: 1. Issue loads for both. The merge is built to handle that correctly. This, in fact, is what the merge/not-found marker is about 😄 2. Issue loads for a side that is “complete” and then use targeting to patch the loaded data into the other side. 3. Generate a component (with no UI) that has a unified query for all data needed, load that, and then use targeting/post mutations to rework the graph as needed. 4. Generate pathom edges that mimic your UI shape so you can load from the parent. I find this least desirable just because it requires a lot of UI-related stuff coded into your back-end. Placeholders are nice because they don’t require addition code that is UI-related on the back-end, just a plugin. In terms of form-state that is more just initializing it correctly one the thing is loaded. That can be pre-merge, post-mutation, etc.