Fork me on GitHub
#fulcro
<
2020-08-14
>
nivekuil03:08:40

I can't quite seem to figure out what ERROR [com.fulcrologic.fulcro.routing.dynamic-routing:454] - More than one route target on screen of type function ... is trying to tell me. It's coming from (dr/change-route! app path), but it's never being passed an ambiguous path.

tony.kay11:08:42

Hm, yeah, the message means more than one thing currently mounted on-screen (of the same type) is about to get a will-leave message, but I can’t remember why that;s a problem 😕

tony.kay11:08:30

well, let’s assume they are two different editors of the same kind of thing. One might be ok with leaving, and the other not…but even if they give different answers, it is an instance-centric call, so I’m not sure what the problem is

tony.kay12:08:32

I think I’ll remove that warning

souenzzo04:08:44

Hello I started to move the realworld app into Fulcro RAD Fulcro RAD is awesome. Thanks @tony.kay https://github.com/souenzzo/eql-realworld-example-app

💯 9
❤️ 3
murtaza5211:08:02

In rad is there a way to add a placeholder to a field ? I have gone through the com.fulcrologic.rad.form-options, but dont see a way to do that.

tony.kay12:08:28

That would be part of a given rendering plugin. the SUI rendering plugin does support custom props on some inputs, but you’ll have to use the source. Not well-documented yet.

tony.kay12:08:21

allows :input/props on form field style config

tony.kay12:08:47

I don’t think I have it set up for text inputs, but I should…you could send a PR by copying that pattern into the control you need it for

tony.kay12:08:38

meh…I’ve got the file open…hold on…

tony.kay12:08:04

0.0.13-alpha-SNAPSHOT

tony.kay12:08:22

::form/field-style-configs { :my/prop {:input/props {... raw extra props to set on input ...}}}

❤️ 3
tony.kay12:08:28

This was already mentioned in the docstring of field-style-configs as an optionally-supported thing, and now has a bit wider support for SUI at least

murtaza5214:08:07

@tony.kay thanks for the quick reply, that worked like a charm !

👍 3
Adam Helins13:08:11

When updates to the app state are local (network is not involved), one can directly modify the state atom, even use utilities like merge-component. Is it more idiomatic to defmutation nonetheless? At least, the mutation is centralized if one day the network becomes involved, I guess refactoring becomes a lot easier. On the other hand, meanwhile, would defmutation + transact! imply an unnecessary overhead?

souenzzo13:08:35

@UCFG3SDFV for simpler ones, you can use fm/set-value! helper Complex mutations needs a name. it will be used for debug, remotes and other stuff.

Adam Helins13:08:18

Could you expand a bit on "needing a name" please? (disclaimer: I am new to Fulcro) I tend to write (`action)` into a separate fn, so a basic defmutation which does not need any remote simply has a short action body acting as a proxy call to its separate fn. Would it still be useful to keep doing that instead of swap!ing on the state atom straightaway?

souenzzo13:08:36

as you do (defn action [params] ....body...) You will do (defmutation action [params] ...body...) And where you did (swap! state action params) you will do (comp/transact! this action params) You can just swap! the atom state inside the mutation, the mutation can't be just it Mutation include for example, "from where" the transact was invoked. you can use this ref erence to do more generic mutations

tony.kay13:08:25

Touching the state atom circumvents all rendering logic. You are allowed to do it, but then you’re “out of the model”. In general, you want mutations or UISM.

Adam Helins13:08:49

I see, one big benefit I understand from this is the access to the env, indeed. @tony.kay Oh, right, Fulcro does not watch the state atom if I recall correctly. So only utilities like merge-component! would be useful then.

✔️ 3
lgessler17:08:12

adding to what others said, transact! also has some helpful options like :after-render? that you wouldn't get with a direct swap!

Michael W16:08:57

Any hints on getting the fulcro-rad-demo working with VSCode and Calva? I got it all working using the terminal, but can't seem to make it work with VSCode for repl integration. When I try to jack in with Clojure CLI + shadow-cljs it just hangs with the message "Jacking in..."

jorda0mega17:08:35

have you tried jacking in with just shadow-cljs?

souenzzo18:08:32

shadow-cljs will start a nrepl at 9000 try to connect directily into it

Michael W21:08:47

Just using shadow-cljs gets me jacked into the cljs repl and the build runs with no issues. I don't have a clj repl to start the server from though. The shadow-cljs watch is good, but no luck on the clojure cli + shadow-cljs I would expect to work so I can start the server.

nivekuil21:08:13

I notice that load! does not actually log a diff in the transaction log (state before/after are the same). Then the next transaction has its "State before" include the thing that was loaded. Is this expected behavior?

nivekuil22:08:24

Ok, so I figured out the problem, but not the solution, with the duplication thing.. it turns out the state is actually incorrect: what appears to be a correct, unique :entry/id(list item) actually has the rest of its state (and therefore props to be rendered) conflated with other :entry/ids! I can only guess that this is on account of some dynamic query weirdness. It only happens when pathom isn't being hit. Is something wrong with my logic in :will-enter?

:will-enter (fn [app {:view/keys [id]}]
                 (let [view-id [:view/id (uuid id)]]
                   (if (get-in (current-state app) view-id)
                     (dr/route-immediate view-id)
                     (dr/route-deferred
                      view-id
                      #(df/load! app view-id View {:post-mutation `dr/target-ready
                                                   :post-mutation-params {:target view-id}})))))

nivekuil23:08:39

previously I did this logic inside an ensure-loaded mutation that was called by route-deferred (calling dr/target-ready instead of route-immediate) and it was still happening, so I don't think :will-enter's side-effect unsafetyness is the issue here

nivekuil22:08:29

in any case I'm leaning toward the legacy union routers as the way forward, unless you all think that UISMs are just strictly better for what basically amounts to HTML5 routing (and are there any examples of the latter use?)