Fork me on GitHub
#fulcro
<
2021-09-04
>
Timofey Sitnikov12:09:50

If I need to load some data by using df/load! in defsc, where is the right place to kick it off? For example, borrowing from minimalist tutorial:

(defsc FriendsList [_ props]
  {:query [:list/people [df/marker-table :friends-list]]    ; 
   :ident (fn [] [:list/id :friends])}
  (let [marker (get props [df/marker-table :friends-list])] ; 
    (cond
      (df/loading? marker) (dom/div "Loading...")           ; 
      (df/failed?  marker) (dom/div "Failed to load :-(")
      :else (dom/div
              (dom/h3 "Friends")
              (map ui-person (:list/people props))))))
Should I add {:initial-state (df/load ... would that make sense?

Jakub Holý (HolyJak)12:09:02

Could you explain why you think you need to do this? Load typically happens 1. At app start, there where you mount your app (an init function?) 2. Upon user action, ie in onClick or similar or from a mutation 3. When you a component is first displayed - here optimally you'd use Fulcro dynamic routing but can also use React's componentDidMount life cycle method

Timofey Sitnikov12:09:06

I send an email to the user with the link to verify email like so: http://localhost:3000/verify?token=fa76c76e-b765-41d5-89de-2a8fc73ef932

Timofey Sitnikov12:09:14

So when user clicks on it, I want to grab the token parameter and attempt to verify the email, then provide success or failure notice.

tony.kay15:09:23

Some ideas: • Since this is a pure verification (which you stored on the server), you could make a server-served HTML page for that URL, process the token, then show them a static result with a link to log in. • During app init, look at the URL and do the interaction. Track the state of that interaction and use a top-level root key to track progress, which you render via Root component

tony.kay15:09:08

If you do 2, then I'd recommend a UISM to make it easier to code the sequence...and integrate it with your login/signup/password change parts of the app.

Timofey Sitnikov23:09:29

@tony.kay, thank you for advice, 2 is similar to normal methodology, will explore it.

Jakub Holý (HolyJak)19:09:15

@tony.kay Hi Tony! Regarding https://github.com/fulcrologic/fulcro/issues/484#issuecomment-911967463, the last line in this snippet confuses me:

(defn global-eql-transform
  "Returns an EQL transform that removes `(pred k)` keywords from network requests."
  [pred]
  (fn [ast]
    (let [mutation?     (symbol? (:dispatch-key ast))
because, given the query '[(my-mutation)], the AST we will get here will be
{:type :root, :children [{:dispatch-key my-mutation, ...}]
i.e. the node we are checking in the fn is always the root and never the mutation itself. So it seems the code is wrong and it should map over the (:children ast) to add tempids to all... Or perhaps I am just missing something??

Jakub Holý (HolyJak)19:09:36

FYI here is my proposed solution https://github.com/fulcrologic/fulcro/pull/486/files?diff=split&amp;w=1 (I have to undo the unnecessary whitespace changes, therefore this diff ignores them)

tony.kay21:09:18

It's because this function is handed an AST node from the middleware, not the entire AST

tony.kay21:09:25

Try logging while using the transform in a live app . I don't remember what all you can get, but I do know that what was coded there works

👍 2
Jakub Holý (HolyJak)19:09:56

A bonus question: Is for some reason the check (symbol? (:dispatch-key ast)) preferable to (= :call (:type ast)) ?

tony.kay21:09:40

:call is probably more logical 🙂

👍 2