@currentoor like idents

ah i see what you mean

good idea

you can do: (prim/transact! reconciler [:my-ref "123"] ['(delete-package)]

then you get it in the key :ref in the environment

I have lots of generic functions that work using this abstraction

because the ref gets to be the "data address"

so I think as: "Im targeting this identity here, and my operation works from it"

and threat it like a graph, a node with other references, and the transaction ref gets to be the starting point of the operation

yeah that seems like a solid approach, i'm gonna do some refactoring now

cool, you can get some examples on those in fulcro inspect source, this is one I use very often: https://github.com/fulcrologic/fulcro-inspect/blob/develop/src/client/fulcro/inspect/helpers.cljs#L45-L48

I’ll toss in my 2 cents here…why aren’t those things normalized??? If they’re normalized, then they are always in the same spot, even in devcards. Oh, you mean you want to throw the component itself just in a devcard. To me, these are different mutation helpers that are composed into the mutation, and if you really intend to use the sub-component separately from the parent (as in a devcard or elsewhere in the UI), the I code a mutation in the devcard that just uses the mutation helper for the sub-component.

or write the helper that deals with the parent to be tolerant of the parent missing

At the core of your question, @currentoor, seems to be the notion of composition of components, and how that affects mutations. If I have a “reusable” component, and I want to compose it, then what do I do? The answer for parent-child relationships should always be the same: react callbacks. The parent should handle the delete, and the child should simply have an onDelete. The update-in in your delete-package is misplaced IMO. GC is another issue, but the fact is when you “delete” something from the UI, the main thing you need to delete it from is the “owner/parent”. Cleaning out the tables may or may not make sense depending on what else refers to it. If you happen to know that the item really is toast, then the parent’s mutation can clean that up, too. This, to me, means that the child is never an “active” component in a devcard-fulcro without either being in there with the parent, or having some local card logic written with the cards.

Hello. I'm trying to use material-ui with fulcro dom, I dont know exactly how to. I tryied something like this, but I'm getting problems with props.

(:require [material-ui :as m])
(def grid (prim/factory m/Grid))

See Shadow-cljs user’s guide, particularly the bits about how to require js stuff

I’ve not used material ui myself, but it really boils down to getting the require right

https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages

I think you want (:require ["@material-ui/core/Button" :refer [Button]])

and such

and you don’t use prim factory, that is for Fulcro components

see the Fulcro Developer’s Guide…search for factory-apply…essentially you’re going to need to invoke react’s createElement

@souenzzo http://book.fulcrologic.com/#_factory_functions_for_js_react_components

I will try this apply. The require part is already ok, I'm using the "webpack method"

Nice! Working. I will try to write a gist about how to use material-ui with fulcro, including the jss with-styles. 🙂

we would like to add error tracking to our app, to track when a mutation or read fails, is there a hook in the parser to track exceptions?

Hello, I need help with the following case I want to solve: 1. Client side fetch ids from an external API 2. Fetch entities based on those ids from my server 3. Perform another request to the external API to update a count I tried to solve this by writing my own remote which can read and mutate the external API. I used ptransact like so

(prim/ptransact! reconciler `[(fetch-ids-from-external-api) ; [1] does a df/load-action and sets df/remote-load for the external remote
                              (fetch-my-entities-based-on-those-ids) ; [2] does a df/load-action and sets df/remote-load for my remote
                              (another-call-to-the-external-api-which-updates-the-count)]) ; [3] only has a remote

@fatihict had you though about doing the count update on the server side instead?

and which version of inspect are you using? if you do 2.2+ you probably can use on iframe (since it's a devtool, I haven't tested so I would be glad to hear if works on iframe situations, but my guess is that it should work)

@wilkerlucio I chose to do the count update client side because I don't want my server to be busy with those calls (which can potentially be a lot). And I am on the latest version of fulcro-inspect 2.2.0-beta8. I can confirm that it does not work with an iframe with the message "Your client library is stale. Please upgrade to Fulcro Inspect 2.2.0-beta8" in the "Fulcro Inspect" tab

that warning doesn't affect the functionality, it's something I add to be sure the client is updated (since the chrome ext will update automatically anyway)

but thanks for reporting, can you please open an issue? that might be something solvable

@fatihict

and about ptransact, this needs some debugging, had you tried logging things, the mutation [2] isn't called at all?

I opened an issue for fulcro-inspect and the mutation [2] is being called, I do see logging I put there in my console, but no call in my network tab :thinking_face:

@wilkerlucio just wanted to check my understanding of this function, resolve-path https://github.com/fulcrologic/fulcro-inspect/blob/develop/src/client/fulcro/inspect/helpers.cljs#L29 it takes paths like [:tab :singleton :package] and gets the data at the end of them, if the result is an ident it will resolve it and get the actual data?

@currentoor it returns a path, but it resolves idents during the resolution, so you can walk the graph

ah i see

@fatihict Did you read the docstring of ptransact? The WARNING section about using it with things that only read, and using multiple remotes?

Fulcro discourages this kind of client behavior, but if you're going to do it, then I'd use post-mutations, and issue real loads from a setTimeout 0 (since post mutations don't do remote processing). I have not officially settled on a cleaner solution to this need, but it is a clear need that comes up on occasion. Partly it isn't "solved" because people are too used to using it where they shouldn't in Fulcro...I could easily add official remote support to post mutations from loads to solve this. Just know that it is perfectly fine to do a load with a post-mutation by having the post-mutation's action do: (js/setTimeout #(df/load ...) 0).

transact and ptransact are meant for mutations (writes) that can potentially return data of interest. ptransact!, in particular, is meant to use the returning function on the remote side to return data, not issue load-actions.

The common use-case for ptransact! is form processing where you want to be sure the server "has it" before moving on. This is the "mutation with returning" (read after write) with a post-processing step.

But at the end of the day, this kind of "load chaining" is something I discourage. Personally I'd prefer to send a query to the server, have it do the request to the external API to get the IDs, gather the entities, update the count, and then return the entities (and count if needed) to the client.

Then again, I know that criteria out of our control makes it necessary to sometimes do this kind of thing, in which case I use the setTimeout trick to issue "top-level" loads against the reconciler (which is in the load env).

@tony.kay I suggested @fatihict he can also just split the process in more transactions, so the loads can go in between instead of using load-action, the setTimeout problem is that it can't chain on a remote response, so I think ptransact! still needed in those cases

@wilkerlucio sure it can load :post-mutation with setTimeout