In this article I will present a simple reactive web application using Scala.js and ReactJS on the client side. It is based on sse-chat, an application I initially wrote for demonstrating the use of AngularJS with Play Framework. I then rewrote the client for an article about using ReactJS on the client side. In the latest version now, there is an additional client that connects to the same server and utilizes Scala.js to build the web client. I recently gave a talk about this at Ping Conference in Budapest, check it out if you’re interested. I discovered ReactJS through David Nolen’s blog and his excellent OM library which combines ReactJS with ClojureScript. His second article on Om also inspired me to try out an undo functionality with the immutable data structures that Scala.js has to offer. For learning more about ReactJS, I recommend going through the tutorial and also reading my last blog post.
Why would someone want Scala on the client in the first place?
Great question, I am glad you asked. A couple of things come to my mind:
If you work with Scala on the server side, you will be familiar with its powerful collection library. You will be able to use it instead of wrapping your head around stuff like underscore. Nothing wrong with underscore, it just adds to the things we have to think about when writing an application.
Immutable data structures are powerful and make reasoning about an application much more straightforward. Implementing an undo functionality becomes almost trivial with this approach.
Here is the new client in action. Note that undo will revert the application state by one step (including name changes and such). Undo all will go through all steps until the beginning of time at a fast pace.
The server side has stayed the same with the different clients. All clients (AngularJS, ReactJS, ReactJS and Scala.js) co-exist in the same project on GitHub. I would like to refer you to this article if you want to learn more about the server side. From the client’s perspective, there is a Server Sent Event stream of messages for a particular chat room that the client subscribes to via an EventSource object. New messages are POSTed using an XmlHttpRequest object (facilitated by jQuery). Users can change their names, they can select the chat room and they can submit messages to the chat room they are connected to. Romeo and Juliet are having a conversation in room 1, just to make it a little more interesting to watch.
Application state is represented by a Scala Case Class. A case class object stores the current name of the user, the name of the room and the last 4 messages. The undo functionality is modeled through a Stack. Each time information changes, a copy of the head of the stack is made and a new version of the application state with the desired change is pushed on top of the stack. Thus going back in time becomes easy: the combination of pop and peek will go back one step in time. Remember that a Stack is a LIFO (last-in-first-out) data structure that typically offers push for putting a new item on top of a stack, pop for removing the top element (with potentially consuming it) and peek or top for accessing the top element without removing it. In Scala’s stack peek is called head as a more general abstract term to get the first element of a collection.
Application state, in its current version, is passed to ReactJS for full render every single time something changes. This may sound like a lot of overhead if React completely re-rendered the DOM every single time. Luckily, it does not need to do that. Instead it utilizes a fast Virtual DOM. It then diffs subsequent version of this virtual DOM and only manipulates the actual browser DOM where changes have occurred. This is really fast. If you run the chat app demo above for a while (or interact with it multiple times) so that the stack contains sufficient elements (hundreds), you should see changes in the browser at a full 60 frames per second.
React’s rendering performance can still be optimized, ut it runs fine at 60 fps as it is. Tip: You want 60fps in your application all the time, otherwise the user may experience jerky and overall unpleasant scrolling if anything that happens takes longer than the time between each frame. For 60fps that means every action must be finished within 16ms, preferably faster.
So without further ado, let’s have a look at how to implement the client side chat functionality. What I suggest here is probably far from ideal, but it’s a start. Please let me know about improvements you think should be made, ideally as a pull request.
First we will look at the main application logic:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
First of all, the following is happening:
There is a case class for capturing each individual step of the application state.
A stack takes care of managing a history of application states. This stack is aware of changes. When such a change occurs, it will call the function specified upon initialization, in this case InterOp.triggerReact.
Undo pops the application state representation on top of the stack, causing triggerReact with the previous state.
UndoAll steps through the entire history until application startup.
Setters obtain the top of the stack, copy and modify it and push the result on top of the stack (again causing a re-render).
Finally, in main the application is initialized by starting the SSE connection.
Next there is the InterOp file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Let’s go through this file step by step:
ChatMsgTrait represents an individual message.
The InterOp object itself contains functions that are exported so that they are accessible from the outside world. We will look at the export mechanism below. As an example of such an exported function, setUser allows the ReactJS application to call the App.setRoom function.
Next we have the change-aware stack implementation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
This implementation is straightforward:
ChangeAwareStack[T] extends scala.collection.mutable.Stack[T] and takes a function that is called when the data on the stack changes.
push and pop are overridden, calling the function each overrides plus additionally calling the onChange functions.
peek is just another name for head.
Finally a companion object allows instantiation without using new.
Functions from the InterOp object are then exported with specified names; this happens in order to protect their respective names. Otherwise, the Google Closure Compiler would rename them. Without exporting the functions, they would also not be publicly accessible at all after the closure compiler optimization phase.
1 2 3 4 5 6 7 8 9 10 11 12 13
Besides naming the exported functions by putting them in an object on the global scope, there is also a call to the main method of the Scala.js application. Personally, I am not terribly happy with putting anything at all on the global scope. Right now I have two global objects, one for the React side of things and one for the exported functions from the Scala.js application. This could quite easily be brought down to one by exporting the functions as properties of the same object used by the ReactJS application. I am just too lazy to do this right now. Please let me know if you have any ideas on how to reduce this to zero objects on the global scope.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
UndoBox is one of the application’s components, handling the undo functionality described above. All it does is assigning handlers to the buttons, in which the functions passed in as props are called.
ChatApp is the main component of the application, it wires together the individual components and passes through the individual props.
tlComp is the rendered top level component. In this call, we specify where to render the component and we also pass in the handler functions as props.
SseChat.setProps is the function that passes props to the top level component. Once the JSX is compiled and initialized, this will replace the placeholder function inside react-interop.js.
At the end of the file, ScalaApp.triggerReact is called. This is done only to render the initial state (with a random name) independent of a message sent by the server. It just makes the initial rendering a bit smoother; otherwise it will not be needed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
listen is a function that is called for establishing a Server Sent Event connection to the server. Upon file loading, a self calling function closes over the ChatFeed variable so that it becomes accessible (and cancellable) on subsequent calls. This self-call then returns the actual function that allows establishing (and replacing) a connection to the stream for a particular room.
submitMsg POSTs a message to the server.
There are multiple functions setting props in the top level ReactJS component, such as SseChatApp.setMsgsProps. SseChatApp.setProps is a placeholder, it gets replaced once the JSX compiler has run and the ReactJS application has been loaded (see above).
Scala.js is an interesting approach for client side development and certainly a technology to watch, particularly when you are working with Scala on the server side anyhow. It is still in the experimental phase, so I probably won’t have the Next Big Thing depend on it yet, but it may get there if there is enough interest in the community.
ReactJS is a library I already fully recommend. Working with it has been a breeze so far and it took a lot less time to get familiar with its features in comparison to AngularJS. Its approach to immutable data is very natural for a functional programmer. It is great to only have to think about components and then be able to build your application around that in the way you like it, instead of being forced to stick to a prescribed way of doing things.
I hope you found this useful; as always let me know what you think.
Until next time, Matthias