Fork me on GitHub
#fulcro
<
2020-06-28
>
zhuxun204:06:45

Is there a way to have a UI component inlined in its parent but still have a query that works well with fulcro's normalization? For example, when Person in PersonList is trivial (e.g., just a simple div), I don't want to create a defsc just for that and would like to simply write (for [{:keys [id name]} person-list] (div {:key id} name)) in PersonList.

zhuxun204:06:48

But if I do that, how should I write the query for PersonList?

souenzzo11:06:02

@zhuxun2 there is "create a component just for queries" in docs.

zhuxun217:06:54

@souenzzo Thanks. I am aware of ui-less components, but that doesn't seem to be what I'm looking for. If I had to write a defsc with ident and query, which is going to feed to UI anyways, I might as well make a defsc with UI...

zhuxun217:06:35

In other words, I'm looking for a shorter inlined syntax for normalization hinting, if that makes sense ...

zilti18:06:12

I mean, an ui-less defsc is already very short to begin with... I use one for a filtering functionality in our product. I use that very same normalized data both for filtering and in another defsc for rendering the results

đź‘Ť 3
zhuxun219:06:28

@zilti I see your point. Thanks. BTW that's what I am doing right now and I was just unsure if I missed anything else.

zhuxun219:06:15

Are the remote mutations deduped on the server? I just made an experiment where I did (comp/transact! this [(my-mutation) (my-mutation)]), but judging from logs my-mutation only got run once on the server

zhuxun219:06:26

On the client it did run twice though... why is that?

tony.kay20:07:30

Two of the same mutation in one tx is not easily supportable, since the response is a map keyed by mutation name. Both mutations will run, and both will go to the server, but you’ll only see one remote response since there’s only one place to “put” the value. In practice this means you must call transact! twice so that they are separate submissions.

đź‘Ť 3
dvingo20:06:45

I believe that is currently not supported. I think the reason is that you can just make a new mutation that handles the logic of both

dvingo20:06:10

*the logic of running the mutation twice

Jakub HolĂ˝ (HolyJak)21:06:14

I think that it's because both are sent in the same transaction and <something> :)