This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (11)
- # arachne (4)
- # beginners (7)
- # boot (21)
- # clojure (41)
- # clojure-greece (2)
- # clojure-japan (7)
- # clojure-poland (4)
- # clojure-russia (25)
- # clojure-sg (1)
- # clojure-uk (3)
- # clojurescript (23)
- # cursive (2)
- # datomic (2)
- # devcards (2)
- # euroclojure (6)
- # hoplon (101)
- # immutant (4)
- # leiningen (4)
- # mount (8)
- # off-topic (2)
- # om (34)
- # onyx (2)
- # planck (1)
- # re-frame (4)
- # reagent (16)
- # spacemacs (6)
- # untangled (19)
Are we supposed to define mutation functions in the root component? Like so https://github.com/Jannis/om-next-kanban-demo/blob/master/src%2Fkanban%2Fapp.cljs#L27
@iwankaramazow: very true but I was also hoping to understand why, could be I’m doing something wrong that will come around to bite me later?
@currentoor: it's more of a syntax style, more like the classic React components which are a 'declarative' description of some UI part
@currentoor: in terms of coupling, with this approach, there is coupling between a component & some mutation
@iwankaramazow: yeah that is what I’m worried about. But if I move the mutation definition down one level the UI breaks (then fixed by another mutation from root).
I’d like to know why it breaks and then decide what the best architecture is for the particular situation.
om/update-state! in an onChange handler for a material
TimePicker component prevents the change from actually being applied to the component. ideas?
@anmonteiro: Have you ever encountered a scenario where you have to run a bunch of mutations after a remote mutation has completed?
I'll try it that way, I probably can't hook into the reconciler's send to supply a custom merge! as callback?
@currentoor: it is because the component you pass into trasact influences the read that gets triggered
I’d like to use this function to retrieve a previous state from history, https://github.com/omcljs/om/wiki/Documentation-%28om.next%29#from-history But how do I programmatically get the uuids of the previous states?
i'm trying to send
(om/get-state this) as the params in a
om/transact! but it errs "is not ISeqable" - anyone know what's up with that?