This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-16
Channels
- # babashka (48)
- # beginners (72)
- # calva (65)
- # cider (10)
- # clerk (11)
- # clj-kondo (14)
- # clojure (85)
- # clojure-austin (11)
- # clojure-czech (1)
- # clojure-europe (26)
- # clojure-nl (1)
- # clojure-uk (6)
- # core-matrix (1)
- # cursive (8)
- # datomic (20)
- # docker (38)
- # emacs (2)
- # events (1)
- # fulcro (6)
- # funcool (6)
- # hyperfiddle (79)
- # introduce-yourself (1)
- # lsp (131)
- # malli (32)
- # off-topic (11)
- # pathom (3)
- # re-frame (11)
- # reagent (15)
- # releases (2)
- # shadow-cljs (49)
- # sql (3)
- # tools-deps (36)
Learning reagent and re-frame for the first time, and have a question about state. https://day8.github.io/re-frame/application-state/ say that "re-frame puts all application state into one place, which is called app-db". However, a book I am following is using a separate r/atom for tracking the state of the fields in a form. Which is the correct way to do it?
I'd say the reagent.core/atom is a more lower level construct than the app-db re-frame provides. Both are "correct" but I feel r/atoms are often used for more ephemeral cases (e.g. is this dropdown menu open or closed) while app-db stores the proper "what's the state of my app" data. Of course nothing stops you from writing your whole app with just reagent and r/atom
When answering similar questions, I usually say that it depends on whether you consider that state as a part of your app's state. Some put even animation transition progress into app-db, some put only something persistent in there.
Alright, that's really helpful. I think the form fields in my app should be part of the "application state" as e.g. checkboxes should be cleared after the form is submitted, and the dropdowns in my app have dynamic list of options which can change depending on other stuff that's happening.
I'm trying to build Auto Save for my app.
• Some values changing in my app-db is not considered "save-able" (ie panning or zooming) but other changes do require saving.
• I can create a subscription to the subset of data in the db that I consider save-able data.
• My strategy is to keep a copy of the save-able data, compare that with any new values of the subscription, and then if (not= prev-value subscription) trigger an event to do the save.
• I don't want to have save button; actually there's no UI to speak of here. I want this auto-save feature to run "in the background".
Is this obviously wrong?
My question is, how can I tie a subscription to an event-dispatch, without using UI/component for it? How can I trigger an event when a subscription changes?
lol - thank you, that sounds perfect. I've been looking for this clue in the docs and googling and somehow did not encounter this concept...
if I understand this strategy; I should have an :after fn that does the db comparison which, if db has changed enough, add an fx for saving?
wonderful, thank you 