Auth Event Handlers
In this chapter, we'll initiate the Reframe loop for our login form, dispatch form submit events and handle them, ie implement steps 1 and 2.
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md
file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
This lesson preview is part of the Tinycanva: Clojure for React Developers course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to Tinycanva: Clojure for React Developers, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

[00:00 - 00:40] In this chapter we will start implementing the reframe loop for the authentication process. There are two major parts to this chapter. Initializing reframe and setting up your project and then actually implementing the reframe loop. We will skip through the initialization process in the video and recommend that you use the notes to follow along and this screencast will only cover the reframe aspects of the authentication. Once you have installed reframe and set up the firebase namespace you can start with the dispatch process. The first piece of the domino is to dispatch a login event from the page component in the pages.login namespace.
[00:41 - 01:48] We built this component in the previous chapter but omitted the on click handler of the submit function. First let's import reframe.core in this namespace and then we can update the on click function to dispatch app domain firebase slash login with firebase event. We have not created a handler for this event yet. If you find the event theme to be verbose you can use a shorter version like fb login with email. We use namespace keyword because we chose to segreg ate reframe components by domain. Having a namespace keyword immediately lets you know where the handler of this event will be defined but again this is a personal choice. To test the dispatch function you can click the submit button manually or use inline evaluation with dummy values. You will see a warning message in your console saying that the dispatched event ID is not yet registered. Next we can create an event handler for this ID. We dispatched an event now we need to capture and process it using a pure function. For this we need reframe.core/ registereventfx function.
[01:49 - 02:58] Before creating event handlers it is a good idea to consider the plan of action . We need to call the login function with email and password in the form. We might need a loading indicator. If the login fails we need to show an error message and if the login succeeds we need to save the user to cache and redirect to some private route. The error handling and redirect happens after the login function i.e. the side effect is called so it is out of the scope of this handler. With this in mind let's populate the Firebase namespace. We first import all the required libraries and then we define the login with email handler. Notice the double colon. The double colon is a shorthand to add the current namespace as a prefix to the keyword. Reframe will call this handler function with the co-effects map and the dispatched event. The form state is a map of email and password since we dispatched the event with a direct state atom. Next we return a map of effects to be applied. The db key with the new value where we set the value of login loading in global app db to true.
[02:59 - 04:03] This flag will help us create a visual indicator and the Firebase email auth effect with the credentials entered in the form. Unlike db this is a custom effect that we will write soon. It is important for these handlers to be pure because that lets us snapshot the state of the app and go back and forward in time. It also makes testing way easier. Suppose this handler was impure. For example we dispatched another event to maintain the number of times a user tried to login. The code above will work but will cause issues in the reframe mental model. Now if these functions are pure and applied in order we can maintain a list of the incremental states and go back and forward in time. We can also write tests without considering the logging statement. With an impure handler like this one the effectful call to dispatch will be queued in the event queue and executed asynchronously. It might resolve before or after the current event leading to an odd state, breaking time travel abilities and becoming hard to test.
[04:04 - 04:36] The reframe authors also suggest that impure event handlers lead to an increased cognitive load for future maintainers since the event is no longer local. So in short you can get away with it but you should avoid it and stay pure. The right way to handle impure side effects is to use effect handlers. We have handled the event and returned the effects map. The effects will add a loading flag in the appdb and somehow log a user into Firebase. We have not defined the effects yet and we will do that in the next chapter.