This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-29
Channels
- # adventofcode (7)
- # announcements (11)
- # beginners (76)
- # boot (3)
- # calva (139)
- # cider (24)
- # clara (2)
- # cljdoc (11)
- # cljs-dev (90)
- # cljsjs (1)
- # cljsrn (3)
- # clojure (98)
- # clojure-austin (2)
- # clojure-brasil (2)
- # clojure-dev (16)
- # clojure-europe (3)
- # clojure-italy (55)
- # clojure-nl (37)
- # clojure-sweden (11)
- # clojure-uk (40)
- # clojurebridge (1)
- # clojurescript (107)
- # core-logic (10)
- # cursive (34)
- # data-science (9)
- # datascript (19)
- # datomic (48)
- # emacs (6)
- # figwheel (13)
- # figwheel-main (3)
- # fulcro (67)
- # jobs (1)
- # juxt (4)
- # lumo (8)
- # mount (1)
- # off-topic (29)
- # onyx (1)
- # reagent (7)
- # reitit (3)
- # ring-swagger (5)
- # shadow-cljs (39)
- # spacemacs (5)
- # tools-deps (1)
I just released Incubator 0.0.21 with nested trigger support in state machines. You can now trigger events on other state machines from within a SM handler. Docs updated and added a workspace example. https://github.com/fulcrologic/fulcro-incubator
Awesome! Would this also work for the same state machine?
yes, but since you can run code and activate a new state from a handler, not sure why you’d do that 🙂
Just a curiosity 😛
say, is it idiomatic to move logic to over to the state machine, or is it preferable to keep as much logic in mutations as possible (and then calling the trigger!
from the mutation)
I see state machines as a mega mutation…when I use them, I don’t end up with mutations much at all. I call trigger from the UI
I also recentlhy added apply-action
, which lets you use state-map functions (i.e. mutation helpers, which I generally annotate with a *
suffix).
the handler
is essentially the optimistic data update, and the trigger-remote...
stuff is for remoting
oh, that’s great! i’ve been wanting to move more logic to the state machine. I just read somewhere in the docs that the mutations handle the optimism
i took a look at the part where i thought i saw it
and it seems consistent with what you’re saying now. I must’ve misread it!
i wonder, is it sane to use the begin
event-data to transmit relevant classes?
i am aware that the docs suggest actors for it, but i have a lot of different classes for different purposes
last i tried to use it, it always complained if i didn’t include an ident
you could technically pass anything in the event data, but do not pass code unless you put it in metadata, since it can end up in your state, and affect serialization
yeah, that’s what i ended up doing. It felt like i was cheating haha
nah…just do something like (def CLASS-ONLY [:FAKE :IDENT])
, and then it will be clear in your code 🙂
so i have another question
given that all this machinery is to avoid circular dependencies, is there any story for functions?
for example, if i wanted a google map to change its view after some remote thing happened
and some function exists in that namespace that performs that job
rather than redefine that function, i’ve been passing it in event data, which i realize will put the function inside app state
so, part of that is just a need to organize your code well. I agree that in Clojure this is a bit of a pain. Mutation declarations were added in incubator as a way to help with this: you can declare your mutations in some “leaf” ns (and not require anything else), so that you completely avoid circular refs (and syntax quoting , for that matter). But if you’re getting circular refs on code, it indicates you need to refactor your code. Move the functions that have no deps to new leaf nses, then move the next layer to their own, etc.
that makes sense
If you feel you must pass things through fulcro like this, then at least do something like this: (with-meta {} {:some-fn (fn [] ...)})
for your parameter
ah yes
I do it in some implementation things when it is necessary (not usually for circ refs, but it does come up)
i think your first point is the way to go. I’ll just make yet another utility namespace 😛
thanks for your advice 😄
oh one last thing!
regarding aborting
there is mention of using abort-request
, but the said function has the application as a parameter
i’ve read both the sm and fulcro docs, however, and it seems i either need the app
or the reconciler
inside the state machine
if i want to use fc/abort-request!
from inside the state machine, i’ll need the app
. But that seems like an unavoidable circular dep, and i do get stack overflow errors when i attempt it.
right
thanks again 🙂
@tony.kay why can’t the actual UI root have an ident?
because then know do you know what the root is? you need something to point to that entity, I always use a helper to generate roots (my actual components are never roots, all of then are ident based, but when build I can run a function that generates a root for it)
maybe that helper could be included in Fulcro
here is the helper:
(defn make-root [Root]
(fp/ui
static fp/InitialAppState
(initial-state [_ {::keys [root-state] :as params}]
(merge
{:fulcro.inspect.core/app-id app-id
:ui/root (or (fp/get-initial-state Root (dissoc params ::root-state))
{})}
root-state))
static fp/IQuery
(query [_] [{:ui/root (fp/get-query Root)}])
static cssp/CSS
(local-rules [_] [])
(include-children [_] [Root])
Object
(render [this]
(let [factory (fp/factory Root)]
(dom/div
(factory root))))))
then you can turn any component into a root
or maybe this could be automatically done by Fulcro if the root component contains an ident :thinking_face:
@U066U8JQJ thanks for sharing
makes sense