@seancorfield @didibus @jackrusher thanks.
What we are trying to create at Notespace is a thin layer of connection between the REPL+Editor UI to the browser. Its aim is to enable literate programming, testing, data exploration and visualization by means of gradually editing a static html document. The editing is done through REPL+editor interaction.
The generated document is a static html page such as these examples by @generateme: (1) (2).
The main question, currently, is what kind of REPL+edtior interaction would make editing such pages into a comfortable and dynamic process of fun exploration.
This problem is similar in its scope to org-babel, which is of course a source of inspiration. However, we seek a solution that would work in different editors, and without leaving the usual Clojure experience of editing a Clojure namespace. It is also related to Marginalia, but we seek to explore a more lively way of interaction, with a more complete support for data visualizations.
The current screencast demonstrates one possible answer to this question (see mainly the behaviour starting from 12:40). In this form, notespace has been useful to a few of us (mainly @generateme, who has been using it extensively at clojisr-examples).
But these days, we are considering some breaking changes. They will probably bring the Notespace experience closer to editing regular Clojure code, with much less special notation. So please expect some different concepts to arise very soon. Of course, comments and opinions will help. Discussions take place at the #notespace-dev Zulip stream.
About my question here
So, we are talking about a single-user desktop application, where the UI is the REPL and the editor, with the additional view in browser showing an html page. That page might be interactive, but currently not in a way that feeds back to the REPL state.
The app state that we have at our REPL process is mainly, for each namespace, the collection of notes (basicly, code blocks which are to be rendered together with their evaluation result). For each such note, there is some metadata (location at the file, type of note, etc.), and a state holding the last evaluation result. There is also some user configuration per namespace, and some additional information such as the namespace currently being edited, the last time each file was read, etc.
User events are function calls that take place at the REPL (e.g., “read all notes at this namespace”, “update the rendering of the note at this line”, etc.). Typically, they will happen through some editor key binding.
Things are happening concurrently: we have editor and REPL user interactions, and we have REPL evaluations, possibly running on different threads, that we want the view to react on their completion.
Since at this stage we wish to experiment with different interaction concepts, we need to write code that is refactored and extended easily,
I hope that it answers some of the kind curiousity above.
For now, I will probably go with
Domino mentioned by @jjttjj. If it turns out complicated, then maybe
re-frame (on the JVM), or simple use of