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 😕

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

I think I’ll remove that warning

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.

For example: https://github.com/fulcrologic/fulcro-rad-semantic-ui/blob/develop/src/main/com/fulcrologic/rad/rendering/semantic_ui/text_field.cljc#L50

allows :input/props on form field style config

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

doing it here would get it to work on most things, I think, since this is a oft-used helper: https://github.com/fulcrologic/fulcro-rad-semantic-ui/blob/develop/src/main/com/fulcrologic/rad/rendering/semantic_ui/field.cljc#L14

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

0.0.13-alpha-SNAPSHOT

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

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

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

@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.

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?

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

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.

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.

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

have you tried jacking in with just shadow-cljs?

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

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.

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