Some early experiments with "Golden Layout" (really with "FlexLayout", since that is recommended for use with React and we are using Reagent)

We are using shadow-cljs

Clone the repo locally with:

git clone https://github.com/cawasser/gl-playground

Run an npm install:

npm install

Use shadow-cljs to start the application for development purposes:

shadow-cljs watch app

Then open your browser to:

localhost:8081    

Open your IDE of choice and start working with hot-reloading. Additionally, if you would like to nRepl into the running app, configure your IDE to connect to the nRepl at localhost port 5555.

Note that this playground does NOT have a full-fledged Server at this time, we only use the minimal server (at port 8081) provided by shadow-cljs.

We have indication that some of our customers have standardized on Golden Layout, and we currently do NOT.

Additionally, we have chosen React as our baseline WebUI technology due to its great interop with Clojurescript and Golden Layout has abandoned support for React, apparently preferring Angular. Hence, FlexibleLayout.

We are starting to see signs of cracks in the underpinnings of the Vanilla UI in the Rocky-Road project.

The original Vanilla project was built from dashboard-clj, which was a very "batteries included" example of building "dashboard" and "dashboard-like" Single-Page Applications. But, it also burdens the developer with a number of explicit and implicit couplings:

1. Interactions between the server and the client were scheduled, using org.immutant/scheduling, not "event-driven" as data changed
2. The project is from 2016, so it predated shadow-cljs, instead using cljsjs to use React Javascript components.
3. It was built using Leiningen, not shadow-cljs, or clojure,cli and tools.deps.
4. It only provided examples using Highcharts, which is itself very complex (and "sort-of" but not "exactly" GG)
5. Highcharts is difficult to work with from CLJS, and incurs licensing fees.
6. Screen management is restricted to a single browser tab on a single screen by react-grid-layout

Further development by our team added more complications and "complecting":

1. UI Widget construction spans many namespaces and is difficult to understand, debug, and extend
2. Data subscriptions from the server often break re-frame re-draw containership, causing "over refresh" of the UI
3. Registering the different types of widgets (highcharts-based, non-highcharts, etc.) are all special cases

So what do we like about how things are done currently, at least from a UI/UX perspective?

• Pushing data from the server, using websockets and "subscriptions"
• Draggable screen organization (grids, etc)
• User ability to pick the data first from what is available, then the visualization technique
• Meta-data tagging on data sent by the server, documenting the structure of the data provided
• Meta-data tagging on the widgets, documenting the kinds of data they can "easily" present
• Meta-data tags can be used to support data->visualization conversions
• Complex and visually pleasing charts and diagrams, including Sankey diagrams
• Preserving screen layout per user (personalization) at the Server

• True "event-driven" updates from the Server (as the default)
• Support for query-driven updates as well
• Move to a true OSS graphics library, like oz
• User-buildable widgets (content), akin to Bret Victor's Drawing Dynamic Visualizations
• Inter-widget communications/sharing (of selections, configuration, etc)
• Support for all manner of React-based widget types, including Geo (WorldWind/Cesium), 3D (three.js), and others