Fork me on GitHub
#fulcro
<
2022-05-19
>
danieroux15:05:47

Mental model check, for Fulcro-RAD, and Pathom3: • We have an attribute, marked ao/required? false. It is listed as part of fo/attributes, so it is part of the EQL query that Fulcro sends. • For some of our Datomic entities, that attribute has no value. The generated (pathom3) resolver fails, because Pathom can't find a path for that attribute in the query. So what I want to understand: What is the expectation here? Should we fill in default values for that attribute so that Pathom3 has an answer, (we really don't want to)? And since we don't know Pathom2, is this a Pathom3 issue?

wilkerlucio15:05:00

hello Daniel, what is the exact error from Pathom 3 here? because cant find path is around the planning, so it happens even before Pathom tries to run any resolver, but if its something different saying it couldn't get the value, then it could be a case to make the pathom 3 driver makes this optional at query level, I'm not super familiar on how RAD drivers works there, so trying to figure with you

danieroux15:05:30

Hmmm. Let me double check, I thought it was happening on run. I am now suspicious.

wilkerlucio15:05:08

just did a quick run to confirm here, when the path is available but the data is missing you should get a Required attributes missing ... error

wilkerlucio15:05:05

this little demo shows the difference:

wilkerlucio15:05:06

(ns com.wsscode.pathom3.demos.missing-data-demo
  (:require [com.wsscode.pathom3.connect.operation :as pco]
            [com.wsscode.pathom3.connect.indexes :as pci]
            [com.wsscode.pathom3.interface.eql :as p.eql]))

(pco/defresolver miss-result []
  {::pco/output [:not-here]}
  {})

(def env (pci/register [miss-result]))

(comment
  ; planning error because can't find a path
  (p.eql/process env [:not-in-graph])
  ; Execution error (ExceptionInfo) at com.wsscode.pathom3.connect.planner/verify-plan!* (planner.cljc:1615).
  ; Pathom can't find a path for the following elements in the query: [:not-in-graph] at path []

  ; runner error, because it expected to get it, but result wasn't there
  (p.eql/process env [:not-here])
  ; Execution error (ExceptionInfo) at com.wsscode.pathom3.connect.runner/check-entity-requires! (runner.cljc:804).
  ; Required attributes missing: [:not-here] at path []
  )

danieroux15:05:51

Right. Triple-checked. The error is indeed Required attributes missing. Apologies for the mid-debugging information 😕

danieroux15:05:28

:com.wsscode.pathom3.error/error-message "Required attributes missing: [:entity/attribute] at path [[:entity/name \"BD10\"]]"

wilkerlucio15:05:51

I think in this case we need to consider what the semantics of ao/required? false means, because it can depend on context (not required on read? on write? on a specific scenario?)

danieroux15:05:10

An entity that does have a value for that attribute, returns fine

wilkerlucio15:05:37

IMO, during read time, the required vs optional should be dictated by each individual context

danieroux15:05:38

How in Pathom3 would I say :entity/attribute is optional in this run?

wilkerlucio15:05:04

(p.eql/process env [(pco/? :not-here)])
=> {}

wilkerlucio15:05:12

this is how you tag something to be optional in Pathom 3

1
wilkerlucio15:05:27

in your case, you write the query or its getting generated by RAD?

danieroux15:05:06

Nice. Thanks. Both, I am getting the query generated by RAD, and I wrote the code to do so. I get to fix it! Yay.

wilkerlucio15:05:37

another option that's common for UI's is to use Pathom 3 in lenient mode, this relaxes the constraints and will tolerate errors, getting you everything it could get, and providing error information for the things that didn't work

tony.kay16:05:46

In the attribute model ao/required? is aimed at the final storage layer: that is to say that it is required when saved. Wilker is right in that the context of a form MAY be able to deal with its absence. Therefore, validation at the UI layer is configurable on a form-by-form basis.

danieroux16:05:01

@U066U8JQJ lenient mode got me there. Thank you!

danieroux16:05:41

@U0CKQ19AQ - that mental model is very useful. Thank you.

tony.kay16:05:44

For example, I often use an ownership model for entities where the entity has something :thing/account that points to the owner. The form never needs to fill that in, because I know it in the session and can do it in save middleware

tony.kay16:05:03

but, given that required is meant to mean it is really part of the data model, then being unable to resolve it from the data store means that you’ve got data corruption (from RAD perspective): such an attribute is actually missing (should have never been saved that way. How you handle that case depends on your app…but can be a real concern with legacy data.