This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (13)
- # beginners (12)
- # business (6)
- # cider (6)
- # cljdoc (9)
- # cljs-dev (1)
- # cljsrn (4)
- # clojars (4)
- # clojure (31)
- # clojure-dev (12)
- # clojure-uk (11)
- # clojurescript (16)
- # cursive (1)
- # datascript (4)
- # datomic (10)
- # editors (1)
- # figwheel-main (3)
- # graphql (10)
- # lein-figwheel (29)
- # off-topic (1)
- # pedestal (1)
- # re-frame (31)
- # reitit (3)
- # shadow-cljs (27)
- # slack-help (5)
- # spacemacs (1)
- # yada (5)
👋 Looking for a few medium-sized modern re-frame apps I can study. I'm doing some research/experimentation and would need a good specimen 🙂
Not sure it classifies as medium but surely modern in the sense that I'm working on it quite heavily https://github.com/AndreaCrotti/elo
gotchu. perhaps even without resorting to code splitting, having 3 separate apps served by a backend would perform better. (of course if the SPAs have rich interactions between themselves, that cannot be trivially substituted)
ace, thank you! 🙌 That's likely enough, but if anyone has a particular favorite feel free to reply in thread
I’m weighing options to implement a standard login flow using re-frame and React Native. The logic basically should work as follows: - check if there’s a stored access token in local storage - verify if it’s still valid (REST call to server) - navigate user to login screen or to home screen, depending on the result It’s pretty obvious how to implement this via effects as a result of user interaction. But this must be done on application startup, when subscriptions are not yet available. Any thoughts?
my standard bootstrap process happens as a result of the very first init-db event, which takes place after all the js has downloaded/parsed. i dont see any real advantage to doing it outside of the normal app code, since there’s often quite a few ways into an app and those too will need to be handled. think magic password links, invite links, masqeurading logins, admins, etc.
so basically the idea is to avoid dealing with any external data sources after app startup, populating app-db with everything we need in advance? I think it makes sense, especially with RN, when you need to use AsyncStorage which doesn’t have synchronous methods at all
> avoid dealing with any external data sources after app startup yes, but also creating a very fine funnel that ideally filters down to “one way into the app”. you might have 3-4 different ways a user can be navigated to the app (through various links), but they ultimately normalize into a single flow that’s easy to follow
think of it like adapters to your app’s interface --- you can have an invite link, an impersonation link, a magic password link, that all contain tight logic for authentication, but they eventually push you into the app through the same handlers
if you have many different ways to bootstrap the app it’s going to be a nightmare to maintain and extend down the road
also consider interceptors with some http interface. i program in an interceptor that checks for 401 http unauthenticated, and if it’s received, automatically emits a global
:unauthenticated event, which brings users immediately to the login screen (because they have now proven that they are unauthenticated). you can also use an interceptor to handle localStorage. for each http request check localstorage and send along the appropriate auth/token header.
a lot of repeatable auth/authorization logic can be orthogonal and pulled out of your app’s domain specific code
A couple of thoughts:
> - check if there’s a stored access token in local storage
I do this in
initialize-db event handler
> - verify if it’s still valid (REST call to server)
If it’s unencrypted JWT-token you could check
exp on client-side?
I don’t understand what do you mean by “when subscriptions are not yet available”. Do you mean that you’d want to make the AJAX call to backend before the app has been loaded? Could you make it instead right after the app has started and display spinner or some other temp view while the app is figuring out if login is valid or not?
design question. why doesn't re-frame allow us to eval subscriptions in a pure way, inside event handlers? why isn't something like this canonical?
(defn pure-subscribe "Use subscriptions inside event handlers in a pure way." [db sub-and-params] @((re-frame.registrar/get-handler :sub (first sub-and-params)) db sub-and-params))
@valtteri actually I think it’s possible to do that it right after DB initialization - active default controller in ReactNavigation will be some kind of waiting screen - once session check is completed, it’s switched to either home or login page (I actually implemented navigation action as a re-frame effect and it looks amazingly efficient)
I'm having trouble with a particular re-frame subscription. The
rf/reg-event-fx fn is handled, as seen by a
.log call, but the new state isn't displayed. Can someone please help me understand where my flaw is?
The code is available at: https://github.com/stephenwithav/knowledge-munchers/tree/having-trouble-with-end-of-game