it looks like :trello-list/cards is denormalized; it should be a vec like [[:trello-card/id "abc"] ...], aka edges to idents like [:trello-card/id "abc"]. what does your trello-card component look like, and how are you loading that data?

IOW an ident is a place to which data is loaded. an edge is a pointer to that place. right now it looks like you've got the data itself under that attribute instead of a vec of pointers

Huh…. I see what you’re saying about the shape of trello-list/cards not being right. Not sure what’s happening — it’s loaded in by this:

(comp/defsc Card [this {:trello-card/keys [id dateLastActivity idList idBoard
                                           pos name desc due]
                        :as props}]
  {:query [:trello-card/id :trello-card/dateLastActivity :trello-card/idList :trello-card/idBoard
           :trello-card/pos :trello-card/name :trello-card/desc :trello-card/due]
   :ident :trello-card/id}
)

Which is loaded in via this component: SelectedListCards:

(comp/defsc SelectedListCards [_ {:trello-list/keys [id name cards]
                                  :as                    props}
                               {:keys [on-select selected]}]
  {:query [:trello-list/id :trello-list/name :trello-list/cards]
   :ident (fn [x] [:component/id ::SelectedListCards])}

Oh!!! The problem is right there in the :query for SelectedListCards! It’s missing the comp/get-query. This works! Thank you @U797MAJ8M!!

Yay, now you’re at 80% - celebrate. I’m about to dig into Fulcro like you and enjoy your comments along the way.

If you use Card inside the SelectedCardList then https://github.com/holyjak/fulcro-troubleshooting would have warned you about the omission, I think

Yes, indeed, @holyjak! I used your fantastic guide to zero in on the problem! Thank you!

Good to hear, though in this case I didn't mean the guide but the tool (of the, confusingly, same name) :)

Which gets me to the other thing I noticed — also diagnosed using @holyjak’s fantastic guide. When I click a button to call the mutation that calls remove-entity, the UI updates. Hooray. But when I manually call the function in a REPL that does the remove-entity (which the mutation calls), the updated DB shows up in Fulcro Inspector, but the UI doesn’t change. ??? As @holyjak recommends, when I call force-render!, the UI updates. I’m trying to figure out who the UI doesn’t update w/o that force-render!… (Part of me doesn’t care, but I feel like I need to understand this to truly understand the Fulcro way. 🙂

I think that when you transact! (unless you transact!! ) then Fulcro schedules a render afterwards. Could that be it?

Thank you! I'm not sure how serious problem this causes to React. We have somewhere nil where we should instead have a value such as false. I'll have a look.

Here is the fix https://github.com/fulcro-community/fulcro-exercises/commit/e63ff226b6e62251535fbae450b32fe704c5ae9a I forgot that and can return nil 🙂

I know the others have answered your question, but just an add. I can tell from the code you posted that you have not yet understood the tree of initial state and how props are fed to the UI. The way I can tell this is you said nothing about how the component is composed into the app. A lot of people have this misconception. Standard Fulcro components are normalized and easily refactored, but they are not stand-alone. They must be composed into their parent correctly. This is the #1 misunderstanding (about 95% of problems people have is with this misunderstanding). The data for a component ends up AT the ident in the db, which is how they can tell that your mutation is wrong (swaps in mutations will almost always be a swap on an update-in of a path of length 3 (the ident is 2, and the prop you want to change has a name, which makes 3).

Try reviewing the basic materials in the YouTube video..if you haven't yet watched those

Another quick note: If you transact! on this (the component), then the env of the mutation will include ref , which will be the ident of the component that invoked the mutation. That is how general mutations like m/set-value! are written.

Thank you @U0CKQ19AQ !, I have fixed it. The main problem for me was to understand that I should `collect`  initial state from children in the root component and then to feed `props`  to children

I think you read and write at different places. You mutations sets DB -> :ui/number while the component reads DB -> :component/id -> ::Rom -> :ui/number . Check again the sections on idents and normalization, perhaps.

I had trouble with the same thing — check out how I was able to implement this in the RAD template here: https://github.com/realgenekim/rss-reader-fulcro-demo/blob/gene-stories/src/shared/com/example/ui/button_toys_form.cljc#L18 I think the problem is the ident in your bump-number — the ident should be [:component/id ::Rom :ui/number]. Right now, you’re incrementing something outside of the “lexical scope” of the Rom component. (Exactly the same mistake I made, before talking with @U0CKQ19AQ.) (I see now that I’m saying exactly the same thing as @holyjak is. 🙂

Noteworthy - there are better solutions than a dedicated mutation, namely https://cljdoc.org/d/com.fulcrologic/fulcro/3.5.1/api/com.fulcrologic.fulcro.mutations#set-integer! (beware - just call it, do not wrap in transact). This will ensure you change the right place. See its impl.

Thank you guys! I have fixed it. The main problem for me was to understand that I should collect initial state from children in the root component and then to feed props to children

If you have ant tips how to make that easier to understand in the https://fulcro-community.github.io/guides/tutorial-minimalist-fulcro/index.html, pls let me know! This is essential.

I didn’t even know about this mini-guide, I need to read it first, thank you for the link

BTW, we're you aware of the Fulcro Community site? If not then how to make it more visible?

As I see now there is the link in the Fulcro book at the beginning. But I rarely look at that section, I look at the left content navigation part for particular things. So maybe it would be useful if there would be a section, for example, "Useful links" or "Other tutorials" or even directly "Fulcro Community Site" (And in the Fulcro RAD book as well). Also I think the problem is that "googling" "fulcro" doesn't show the community web site at first page.

Fulcro does NOT watch the db atom (Inspect does). Fulcro is a strict transactional system. If you don't run a transaction, as far as it is concerned there is no UI to update.

So, if you want to run something in the REPL, the thing you want to run is transact!, or something that wraps it (as does load!, merge-component!, set-value!, etc. Everything you call that changes something to do with the state db in Fulcro results in a transaction underneath...just trace the source and you'll quickly reach where it is doing a transact. load! for example, defines an internal-load mutation and when you call load! it submits a transact on internal-load.

https://clojurians.slack.com/archives/C68M60S4F/p1627327328105600?thread_ts=1627258680.097100&cid=C68M60S4F Oh, that’s interesting! From Fulcro book: “comp/transact! The central function for running abstract (possibly full-stack) changes in the application. Can be run with a component or app. If run with the app, will typically cause a root re-render.” Huh. I now see that merge! doesn’t force render, either. Just comp/transact!. And df/load!, too, right? (ah, thanks for answer — `load!` forces a transaction.) THANKS!!! Another Fulcro mystery solved.

merge! should be a transact! as well.

oh...no, it isn't

ooops. That's right. Some of the merge functions are meant to be used as utilities within a mutation.

merge! isn't really meant for public use...it's a very old function that was part of the original implementation mixed with Om Next, and I could not remove it without breaking external code (because it was public). So, even though I didn't really want it to be public still, I was stuck doing so because I don't like to break existing code if at all possible. It does not hurt anything, but as you noted it does not force a render. These functions are part of the implementation of the load logic (which is already running in a mutation) which is why they are not, themselves, written as transactions.

The ! versions should probably all schedule a render.

FWIW, that sounds like a great change, and hopefully harmless — it was a bit puzzling to not see the re-render. Thx!!!

Pushed as Fulcro 3.5.2

Woot! Delightful! Thank you!