This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-03
Channels
- # announcements (11)
- # atom-editor (8)
- # aws (16)
- # babashka (34)
- # beginners (59)
- # calva (32)
- # cider (8)
- # clj-kondo (43)
- # cljs-dev (52)
- # clojure (26)
- # clojure-europe (11)
- # clojure-italy (2)
- # clojure-nl (5)
- # clojure-spec (16)
- # clojure-uk (44)
- # clojurescript (5)
- # core-async (21)
- # cursive (14)
- # datomic (53)
- # figwheel-main (4)
- # fulcro (5)
- # graphql (6)
- # java (3)
- # kaocha (5)
- # leiningen (6)
- # local-first-clojure (1)
- # malli (25)
- # off-topic (40)
- # other-languages (1)
- # pathom (5)
- # pedestal (3)
- # re-frame (4)
- # reitit (2)
- # reveal (8)
- # rum (21)
- # sci (16)
- # shadow-cljs (90)
- # spacemacs (8)
- # tools-deps (10)
- # vrac (6)
- # xtdb (12)
Relative noob here: I am seeing a class of bug in which it turns out app-db
holds stale state from an earlier context. In one extreme case one user logged out and another logged in (same person, QA testing jumping between users) and the second "user" ran into old state in app-db
. Is this a Known Thing(tm)? If so, does it mean we are missing some clean-up idiom? Some initialization idiom? Mistakenly using app-db to pass state between events? Other______? Thx!
It's a known thing because app-db
is an atom that doesn't clear its values by itself. If you want new state, you have to set it yourself, that's it.
I can't say anything more specific without seeing an example.
Also, regarding user authentication - now I just treat that part of the app and not being a part of the SPA. I.e. if a user clicks on the "Log In" button after filling the login information, the page is refreshed. There are two main advantages to this approach: - You guarantee that the state is fully reset - there's just no place for a mistake here - You make the website much friendlier for web password managers that monitor form submissions
Awesome. Thx! I am sure we can find a "kickoff" event where app state can be reset.