Clojure is a functional hosted LISP known for its expressiveness, which has excellent interop with Javascript, Java, and Microsoft's Common Language Runtime (CLR). 

Many developers praise the elegance and productivity Clojure allows, but for many it seems like an esoteric language with an "ugly" syntax that is impossible to get started with. This course will change that view and show you how to be productive with this marvelous language.

In this course, we'll build a web-based graphics editor similar to Canva. We'll explore Clojure from the perspective of a JavaScript developer. Along the way, we'll also explore state management, authentication, API integration with Google Firebase and interop with NPM.

This course takes you from zero to an understanding of Clojure semantics, LISP tools, and building a production-ready React application in just a few hours. 

We'll start with the basics and build up to writing a fullstack app with both frontend and backend in Clojure. 

The frontend, built using ClojureScript (Clojure that runs on JavaScript) will be a single page React application with routing, key-based authentication and API integration, which will save, list, edit and delete graphics.
 

The backend is hosted on Google Firebase. 

Throughout the course, we'll learn about tools like REPL that aid development. Towards the end, we'll learn about advanced concepts like code splitting and end-to-end testing.

Clojure is unlike other languages as it is hosted on, and can leverage, existing VMs. This means that you can learn Clojure once and write it on the backend with JVM or CLR, and the frontend with JavaScript. If a new technology like Rust takes over the world tomorrow, you will probably be able to continue to write Clojure because a Rust port is already in the making.

By the end of this course, you'll have a superpower: the ability to write fullstack Clojure applications.

Build a Fullstack Web Graphics Editor in Clojure and React

This is a course on Clojure for React developers in which we'll build a web-based graphics editor similar to Canva.

Tinycanva: Clojure for React Developers

---
title: Introduction to React State Management
slug: tc-intro-state
description: Reframe is a flux-like library for uni-directional data flow. In this chapter we'll study the six-step Reframe loop.
privateVideoUrl: https://fullstack.wistia.com/medias/7rqpa9rstf
---

# Introduction to state management

State management in React is a controversial issue. There are multiple competing models like MobX, React Context, and Flux.

In this chapter, we'll walk through the concepts and terminologies of two ways of managing the app state: **Reframe** and **reactive atoms**. The focus right now is to form a mental model, but in later chapters we'll realize the models.

We have already seen `r/atom` [in action](https://www.newline.co/courses/tinycanva-clojure-for-react-developers/tc-reagent#local-state-using-reactive-atoms). Ratoms are a simple yet powerful way to store state. We can have one or more ratoms, and components that listen to them. But as your app grows, keeping track of these atoms get hard. Performance will suffer as we have little control over the re-render cycle. If anything in the ratom changes, all listener components will be re-rendered.

## Reframe

[Reframe](https://day8.github.io/re-frame/) is a Redux-like framework with a uni-directional data loop. It allows you to structure application state and enables optimal rendering. First released in 2015, it is now one of the most starred Clojure projects.

The authors of Reframe explain it as a [6-step process](https://day8.github.io/re-frame/a-loop/#six-dominoes). Let's walk through the steps with an example.

Imagine you have a form with two input components - email and password - and you want to re-render the form each time a user types something. The skeleton of the component might look something like this:

```clojure
(defn login-form []
	[:input#email {:value "" :on-change #()}]
	[:input#password {:type "password" :value "" :on-change #()}])
```

(This component won't work because the `:value` is fixed and `:on-change` is not implemented - just focus on the outline for now.)

### Step 1 - Dispatching events

The first step of the Reframe loop is to dispatch or emit an `event`. This event could be:

-   a keystroke in an input field
-   a click of a button
-   a message on a WebSocket
-   mouse motion
-   etc

In the example above, the user typing in the `input` field is the event we wish to capture.

To set the loop in motion, we use the `reframe.core/dispatch` method:

```clojure
(rf/dispatch [:event-id argument1 argument2 ...])
```

`dispatch` accepts a vector where the first element is the id of the event we want to dispatch. Data that we wish to pass along can be passed in the vector.

In more concrete terms, in the `login-form` component, we wish to save the state in Reframe. We can modify the `:on-change` handlers to `dispatch` change events:

```clojure
(defn login-form []
	[:input#email {:value ""
	               :on-change (fn [e]
				                  (rf/dispatch
								     [:handle-email-change (.. e -target -value)]))}]

	[:input#password {:type "password" :value ""
	                  :on-change #(rf/dispatch
					                 [:handle-password-change (.. % -target -value)])}])
```

We used inline functions to `dispatch` events each time the input changed. This is not the ideal approach but is easy to understand.
Both `(fn [])` and `#()` have the same behavior - both call `dispatch` and set the Reframe loop in motion.

### Step 2 - Event handlers

For a `dispatch` to be useful, we need to handle the dispatched event. This can be done using `reframe.core/reg-event-fx` method (AKA register event effect method). `reg-event-fx` takes two arguments: the **event id** and a pure **handler function**. Event ids are keywords and generally namespaced.  `:handle-email-change` and `:handle-password-change` are examples of events that change the state of the app. 

```clojure
(rf/reg-event-fx
  :handle-email-change ; event-id
  (fn [_ _] ; handler function
    ...))
```

This handler function is called with two arguments each time the event is dispatched.

The first argument is the co-effects map - you can think of this as the current state of the universe. The second argument is the vector we passed to `dispatch`:

```clojure
(rf/reg-event-fx
  :handle-email-change
  (fn [cofx event]
    ...))
```

[comment]: <XGM: the rest of this section and Effect Handlers section - I reread this many times but just couldn't get a grip on what was happening! Maybe because I am not familiar with this, but could you have another look and consider if the explanation of the various steps with different maps and effects is as clear as it could be. A diagram might help or possibly a set of numbered steps incorporating the event and effect handling. >

This is a good time to disclose that Reframe keeps the entire application state in one large map. This is generally referred to as `app-db`. Internally, this map is a ratom.

Reframe is a flux-like library for uni-directional data flow. In this chapter we'll study the six-step Reframe loop.