Clojurists Together

March 2018 Monthly Update

Hi folks!

Welcome to the second monthly update for Clojurists Together.

Clojurists Together news

This month we had around 45 members sign up (we still need to process any signups at the end of this month), and one company member join. We've had a really strong response from individual contributors, but not so much from companies. If you work for a company that uses Clojure, please consider talking to your manager about supporting Clojurists Together. We recently conducted a survey of our members and will be publishing the results of the survey, and a request for proposals, for our second round of funding. More on that soon.

We continue to work on automating the sign-ups on the website, to make a faster and smoother flow for people who'd like to join.

clj-http updates

From Lee Hinman:

- March 1 - March 15

The last couple of weeks have seen the following changes in clj-http:

That's it for this block!

- March 15 - March 30

Here's what I've been up to for the last couple of weeks:

Here's to more improvements in the future!

Figwheel updates

From Bruce Hauman:

-March 1 - March 15

Figwheel Core

Today I published a figwheel-core project to the master branch of the lein-figwheel repository.

Figwheel-Core provides all the main code for determining what to reload and how to reload/notify the client. It is completely independent of the REPL and server implementations. It only has one real dependency and that is ClojureScript itself. It uses the established IJavaScriptEnv interface for communication with the client. This means it doesn't matter what your client is.

figwheel-core really feels like a Figwheel thesis project for me, a Rich Hickeyan distilling of Figwheel down to its essentials. It has been a very rewarding experience.

This figwheel-core work has been my focus for the first half of March. After this I'm going to tackle a figwheel-repl which is planned to be completely free of reloading code and will focus on a strong stable connection and sane multiplexing.

Much thanks to Clojurists Together and its fantastic supporters!

March 15 - March 30

Figwheel REPL

Much like 2 weeks ago, I have published a Figwheel-repl project to the master branch of the lein-figwheel repository.

Figwheel-REPL is only a ClojureScript repl-env and doesn't do anything specific to help with automatic file reloading. As such, it is more similar to Weasel in function than to Figwheel.

It is intended to be a single repl-env that will work on as many platforms as possible: including Browser, Node, Worker, ReactNative, etc. It is also intended to handle multiple clients, think browser tabs, much more gracefully than the current Figwheel REPL.

It is also different in that it only evaluates code on a single client by default. You will still be able to choose to broadcast an eval operation to all connected clients if you prefer. You can also provide a filter function when you create the Figwheel repl-env, to filter the connections to the set of connected clients you want an eval operation to be sent to.

Multiple REPL behavior

The new figwheel.repl namespace currently offers some ClojureScript functions to help you list and choose which connected client to focus on.

The figwheel.repl/conns macro allows you to list the connected clients:

For example:

cljs.user> (figwheel.repl/conns)
Will Eval On:  Darin
Session Name     Age URL
Darin            25m /figwheel-connect
Judson          152m /figwheel-connect
nil

The above figwheel.repl/conns call lists the clients available for the REPL to target.

All connections are given easy to remember session names. The intention is that this will help you easily identify which browser tab your, through the REPL client feedback in the browsers dev-tool console.

The Will Eval On: Darin indicates that the Darin client is where the next eval operation will be sent to because this is currently the youngest connected client.

This youngest client heuristic for choosing which client to evaluate on, allows for a simple understanding of which REPL is the current target of eval operations. Open a new browser tab, or start an new node instance and that becomes the new eval target.

If you want to focus on a specific client:

cljs.user> (figwheel.repl/focus Judson)
Focused On: Judson

From now on all evals will go to Judson unless the connection to Judson is lost in which case the behavior will revert to selecting the youngest connection.

You can confirm that the repl is currently focused with:

cljs.user> (figwheel.repl/conns)
Focused On: Judson
Session Name     Age URL
Darin            28m /figwheel-connect
Judson          155m /figwheel-connect
nil

I think this goes a long way toward solving a problem that has existed since the very beginning of Figwheel.

Attention toward embedding the figwheel-repl endpoint

The other problem that I'm currently trying to work out is how to best support embedding the Figwheel REPL endpoint in your server.

For larger projects it simplest to use figwheel connection as a side-channel, a separate REPL connection, that is distinct from your projects HTTP server. Figwheel's use of Web-sockets and CORS make this side connection a simple matter. But inevitably there are situations where you want to embed the Figwheel endpoint in your server. So I'm giving this some serious attention.

In addition to the Web-socket connection, I have implemented a simple HTTP polling connection which should allow anyone to embed figwheel-repl ring middleware into their stack. (Side note: I'm also looking at long polling).

It is too bad that as a community we haven't landed on an agreed upon Ring web-socket interface, as this makes it much harder to allow simple embedding of a web-socket endpoint into the server of your choice. But I'm going to do my best to facilitate this by making it easier to create a web-socket endpoint from the provided api.

On a side note: I'm also considering making the default server a the ring.jetty.adapter as it is such a common dependency.

Work for the last month of Clojurists Together

My work over the next month is to complete both figwheel-repl and figwheel-core.

I'm hoping that I can also finish a figwheel-main (a proxy for cljs.main) to tie it all together. My intention for figwheel-main is that it will the most important functionality of figwheel-sidecar but will follow the cljs.main arg conventions. It will provide solid file watching capabilities along with a solid figwheel-repl connection and make it trivial to turn on auto file reloading.

I'm excited by what amounts to a completely new Figwheel, which will be a simpler Figwheel minus a tremendous amount of complexity.

Minutes/Committee Communications

In our recent survey and in previous member communications, a few people have mentioned that they'd like to have more visibility into how the projects are chosen. We had chosen not to show the voting results for the projects that didn't get in, as we didn't want unsuccessful applicants to feel bad if the results were released showing that their project wasn't selected. We have a few changes planned to increase transparency without discouraging applicants:

These two measures should help backers understand how we voted. If you have any thoughts on this, either as a backer or an open source contributor, please get in touch.