Fork me on GitHub
#fulcro
<
2020-11-13
>
nivekuil10:11:42

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.

Buidler13:11:14

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.

cjmurphy14:11:59

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.

Buidler14:11:08

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

cjmurphy14:11:43

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.

Buidler14:11:40

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?

cjmurphy14:11:14

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

Buidler15:11:44

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.

cjmurphy15:11:54

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.

Buidler15:11:57

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

cjmurphy15:11:00

I do it for all attributes, so for example

defattr short-name ::short-name :string
inside a namespace that is like org.mycompany.model.organisation . So there's an ::organisation/short-name .

cjmurphy15:11:23

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

Buidler15:11:04

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

Yuriy Zaytsev13:11:20

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...)
)
on a remote part did I get the changes on state from action part? From documentation it said that remote part run after the action has run. Does it mean that remote waits for action to be executed?

Buidler14:11:48

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

Yuriy Zaytsev14:11:33

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

Buidler14:11:53

I think it basically comes down to:

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

tony.kay14:11:09

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.

Yuriy Zaytsev14:11:14

Thanks. I’m still noob in it

Buidler15:11:41

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.

tony.kay15:11:29

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

👍 3
lgessler18:11:20

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?

tony.kay19:11:54

In general I have changed over to making accurate and descriptive commit messages, so you can look at the commit history between those two versions and see the changes. I kept forgetting to upgrade changelog.

👍 3
lgessler22:11:10

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

❤️ 15