Update on Fulcro 3. Spent the entire day on it. I’ve got a full-stack TodoMVC running. Still a long way to go to round out APIs, but it’s nice to see it dancing. In an advanced compile build my new rendering optimizations cause fulcro to take about a half a ms to get the targeted update data for 2 of components, and the setStates that do the targeted props (in the release build of react 16.8.6) take on the order of 0.5 to 4ms. Of course, some of that setState time is element generation, but since Fulcro does those at compile time to js, those are basically a wash. It’s a simple app, but the design of the optimization should theoretically keep those times on that order even with a lot of things on screen (since it only updates the ones that really change, and that tends to be very few at a time).

Also nice to know I can get an advanced compile to work on the first try….that was a nice change of pace…usually have to fight that one pretty hard

As a first step to building a custom remote, i'm trying to reproduce the "remotes as abstraction" code in my project

and i'm now moving parts of the code in their own namespaces

i get all kind of problems with symbol namespaces

so in my background-remote ns, i have this : (defmethod ls-mutate `set-some-key ...`

hum dunno how to escape the backtick in slack >>

in my page file let's call it namespace root, i have (defmutation set-some-key ...

and in the Root macro defsc onClick #(prim/transact! this `[(set-some-key...

it looks like the defmutation is correctly applying the action

but ut won't call the background-remote, logging an error in the console

No method in multimethod 'cark.tags.options.background-remote/ls-mutate' for dispatch value: cark.tags.ui.options-page/set-some-key

i can make it work by namespacing everything to my background-remote namespace, but that's obviously wrong

so my question is, how do i namespace everything so that it's both modular and working ?

for now i did (defmulti ls-mutate (fn [_ key _] (symbol (name key)))) in background-remote. and (defmethod ls-mutate 'set-some-key ...

Hi @tony.kay, I am trying to test ident queries, but somehow it does not work as I expected. Here is a sample code:

(defsc Ref1
  [this props]
  {:query [:title]
   :initial-state {:title "some-title"}
   :ident (fn [] [:ref 1])})

(defsc SomeData
  [this props]
  {:query [{[:ref 1] (prim/get-query Ref1)}]
   :initial-state (fn [_] {})}
  ;;;;; props contain {[:ref 1] {}}, not  {[:ref 1] {:title "some-title"}}
  (dom/p (str props)))

(def ui-some-data (prim/factory SomeData))

(defsc Root
  [this props]
  {:query         [{:ref1 (prim/get-query Ref1)}
                   {:some-data-list (prim/get-query SomeData)}]
   :initial-state (fn [_]
                    {:ref1 (prim/get-initial-state Ref1 {})
                     :some-data-list [(prim/get-initial-state SomeData {})]})}
  (map ui-some-data (:some-data props)))

you cannot have just a link query in a component

well, let me think abt that

actually, if you have initial state it prob should work…

if the init state is not a vec, it works.

So, in general link queries as a “way to walk the graph” are not recommended

in practice you won’t know that the ID is 1..so this is kind of a contrived example

The limitation is that components that query for NOTHING of their own (like SomeData) won’t work right

http://book.fulcrologic.com/#_a_warning_about_ident_and_link_queries

What you want to do is join Ref1 in initial state to SomeData

and just make up a kw for the “edge”

(defsc SomeData
  [this props]
  {:query [{:edge (prim/get-query Ref1)}]
   :initial-state (fn [_] {:edge (prim/get-initial-state Ref1 {}})}
  ;;;;; props contain {[:ref 1] {}}, not  {[:ref 1] {:title "some-title"}}
  (dom/p (str props)))

if Ref1 has a constant ident, that’s fine…this will join it always

ident queries in components are highly discouraged. Link queries (where the second element is _) are meant for things like “logged in user” and “load marker table”.

ident queries are really meant for talking to servers

e.g. I want to load person 1: [{[:person/id 1] (prim/get-query Person)}]

which is what (df/load this [:person/id 1] Person) sends

in a static component definition, you typically don’t want to embed a static ident. If it really is a singleton, the edge invention above hurts nothing.

The one exception that is reasonable is if there is a singleton that you really do need to dynamically get to from various instances of a component, then it’s OK, but you have to be careful that your query contains something besides just the ref join

Oh, your code has a typo, too

(map ui-some-data (:some-data props))

:some-data is not what you called it

😛

it might actually work if you fix that

haha. thanks for your prompt answer. As you just said, I have different kinds of components that refer a singleton component.

If you use props destructuring Fulcro will warn you abt that

I’ll try your suggestion using :edge, but I am curious about :initial-state (fn [_] {:edge (prim/get-initial-state Ref1 {}})}.

and :initial-state has a non-lamba version that also error checks (and auto-wraps get-initial-state):

(defsc Root
  [this {:keys [ref1 some-data-list]}]
  {:query         [{:ref1 (prim/get-query Ref1)}
                   {:some-data-list (prim/get-query SomeData)}]
   :initial-state 
                    {:ref1 {}
                     :some-data-list [{}]})}
  (map ui-some-data some-data-list))

The maps in the non-lambda initial state are automatically turned into what you wrote by looking at the query

even in to-many

the maps are the params

If I have that code, doesn’t it initialize the edge every time when an SomeData is created?

and those are also error-checked by the macro

initial-state means ON APP start

not on every mount

I see.

Fulcro creates your initial state database by normalizing initial-state using root query

that’s all it does

gives your app an “initial state”

it is not a component constructor

gotcha!

(though you can call get-initial-state yourself at any time, if you want, for your own needs)