This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-03
Channels
- # admin-announcements (1)
- # beginners (4)
- # boot (1)
- # chestnut (2)
- # clara (1)
- # cljs-dev (8)
- # cljsjs (50)
- # clojure (40)
- # clojure-austin (3)
- # clojure-brasil (3)
- # clojure-canada (1)
- # clojure-gamedev (2)
- # clojure-italy (3)
- # clojure-russia (19)
- # clojure-spec (14)
- # clojure-uk (1)
- # clojurescript (60)
- # core-async (4)
- # cursive (4)
- # datomic (3)
- # editors-rus (2)
- # emacs (4)
- # events (1)
- # figwheel (2)
- # flambo (4)
- # hoplon (94)
- # jobs (4)
- # leiningen (3)
- # om (9)
- # onyx (64)
- # re-frame (86)
- # reagent (52)
- # spacemacs (4)
- # test-check (1)
- # yada (31)
How is a login generally implemented? As a remote read
or a remote mutate
?
this isn’t an om specific answer, but its common in graphql / relay type things to keep login separate — reasons being: local state can be very user specific — easier to just blow it away — and many of the times your server parser assumes a user.
so I generally do a basic login page that posts / redirects into an om / relay / etc app
I just came of a project with graphql/relay 😄
I'm trying to follow the same flow, but
I think I need to post process remote mutate stuff to merge it under the right keys
so in relay there is no invalidate concept (in om you can make one — you control the cache) so its hard to switch users because you can’t clean the cache
I haven’t done vanilla om.next in awhile, but yah, we have a custom remote merge function
In relay I mutated the viewer between an 'anonymous' role & an 'authenticated' role.