Clojurians Log v2

Didn't look at this too hard, but it seems like calling uism/begin! inside hooks/use-effect doesn't properly set the actor class in the actor map. I had :actor/foo (uism/with-actor-class ident (comp/registry-key->class :my.component.foo)) in a componentDidMount before and uism/load worked ok, but it seemed to have lost the class metadata when I changed the component to use hooks. Easy workaround by just specifying the class in the uism handler though.

Is it reasonable to implement most mutations in two parts, the mutation (acting on the state atom) and the mutation helper which the mutation calls? My thinking is that it makes the main logic, stored in the mutation helpers, a bit more focused and easier to compose and test.

Hi there! I’m trying to get how mutation works and I have a question. If I have a mutation like this on a frontend

(defmutation 
  [something]
 (action [{:keys [ref state]}] ...updating state here ...)
 (remote [{:keys [ref state]}] ... send something from state-2 to backend...)
)

I believe that to be the case, but the behaviour can be changed from optimistic to pessimistic. See http://book.fulcrologic.com/#_pessimistic_operation

Thanks. I guess It should be some less confusing way to perform it. Something like explicitly call for remote in a body of action.

I think it basically comes down to:

(comp/transact! this [(f) (g) (h)] {:optimistic? false})

That's what I do - call st->st functions from mutations. There's a convention to put a star (*) at the end of the st->st function.

@cjmurphy do you also have much logic within the mutations?

It is a documented behavior, so I don’t understand the confusion. Yes, the remotes act after action for a given mutation. Yes, you are allowed to look in state and update the request if needed.

In-details doc: http://book.fulcrologic.com/#_stages_of_mutation

Thanks. I’m still noob in it

http://book.fulcrologic.com/#_recommendations_about_writing_mutations. I guess you've seen that. As a habit I'm always going st->st. But still some bigger mutations stay, but dealing with many st->st. Then some mutations so simple there's no point.

Do you ever call the built-in helpers (`targeting/remove-ident*`, etc.) in your st->st functions or do you keep that in the mutation?

For merge/remove-ident* I can see both uses! Both used in mutations and in st->st functions.

Cool. Thanks. I guess many of my questions are more about which way is the right way to do something, rather than just how to do something. The idiomatic approach is hard to figure out.

Is there anything built-in that's helpful for doing cascading mutations? For example, I have a Foo component which has a :foo/bar-list. Is there something that makes it easier to remove a Foo as well as all of its Bar nodes? I guess iterating through all of the idents in :foo/bar-list and dissocing them from the state map isn't that difficult, but it seems like a common operation.

The refactoring here isn't too time consuming so probably not a big issue. My biggest refactoring headache was going to using fully qualified attributes. But probably everyone uses :: for their entities from the outset these days.

Where do you need to auto-resolve keywords? Like in the core defsc options or something? I'm not doing that yet.

I do it for all attributes, so for example

defattr short-name ::short-name :string

Because :organisation/short-name is too global, might well clash. But it is a habit that really doesn't cost you anything much.

Yeah, makes sense. It's recommended by both Clojure Spec and Pathom but sometimes I hesitate about where to use the :: or not.

see normalized-state ns. it has helpers that can cascade @randumbo

hi, been gone for a couple months, am upgrading fulcro to 3.4.3 from 3.2.11--anyone got a quick tldr on new features? looking at clojurians-log it looks like 3.4 had enhancements around dev tools and 3.3 had some hot code reload enhancements (i should add (comp/refresh-dynamic-queries! app) to my refresh fn)... anything else anyone upgrading should know about?

also, I made a https://github.com/lgessler/fulcro-material-ui-template that uses Material-UI and has some basic code worked out for routing and user auth. It's kind of heavy on code for a "template" but when I was learning Fulcro I remember wanting to have a template with all the batteries I wanted included. Mostly made it for myself but sharing here in case anyone's interested--thanks to @danvingo https://github.com/dvingo/dv.fulcro-template I based it on

for anyone finding this later: see http://book.fulcrologic.com/#_synchronous_operation