api/init should call gn/reset-notes

[behrica]

I cannot see the need to "init" the notespace, without wanting to "clean" the browser.

[behrica]

Hmm.
I get some dead-locks combining api/init and gn/reset-notes

Maybe not that simple.

[daslu]

notespace.api/init,
which is actually notespace.lifecycle/init,
calls notespace.renderers.gorilla-notes/init,
which calls gorilla-notes.core/reset-notes!.

[behrica]

I am maybe confused, what api/init is supposed to do.

Maybe I miss a "reset" function on api level.
Which should

• "reset" the note-list too initial stage
• re-read the clj file
• clear the browser

So that a following "evaluate-notespace" starts as much "from scratch" as possible.

[daslu]

notespace.api/init,
which is actually notespace.lifecycle/init,
does the following things:

notespace/src/notespace/lifecycle.clj

Line 7 in 71c04bd

(defn init [& {:keys [open-browser?]

(1) resets the Notespace state, except for the config (so if the user has redefined the config, this part stays redefined)
(2) resets the renderer (which is based on Gorilla-Notes)
(3) makes sure the renderer is mount (exactly once) to reflect the system state changes

Step (1) makes sure the system information about notes is emptied. In order to fill it back, we need to ask it to evaluate namespaces, etc.

Step (2) is calling the init function of the renderer (based on Gorilla-Notes):

notespace/src/notespace/renderers/gorilla_notes.clj

Line 19 in 71c04bd

(defn init []

• It makes sure that the Gorilla-Notes server is set (serving a page and talking with it through websockets).
• Makes sure its list of notes is empty.
• Sets some options.
• Watches inputs (this is not in use at the moment).
  The browser view is reflecting the list of notes of the Gorilla-Notes renderer, all the time. So emptying this list empties the view.
  The list will start filling again when the renderer reacts to changes in Notespace.

So, of the tasks you mentioned

• "reset" the note-list too initial stage
• re-read the clj file
• clear the browser

.. the only one which does not happen here is re-read the clj file. But that will happen anyway when we evaluate the namespace through the notespace api -- because it is called in this function:

notespace/src/notespace/actions.clj

Line 69 in 71c04bd

(defn act-on-notes! [anamespace actions]

Does it makes sense?

[daslu]

Maybe the confusing thing here is that there are two states here:

• The Notespace state.
• The Gorilla-Notes state.

The Notespace state is managed through the Cljfx events and context system.
https://github.com/cljfx/cljfx#subscriptions-and-contexts
It contains, for example, the user config, and also the vector of notes per namespace, with all their metadata and evaluation results, etc.

The Gorilla-Notes state is just the list of hiccup elements that should appear in the browser at a given point in time.
(My apology: it is confusing that Gorilla-Notes called these hiccup elements "notes", while they are nothing but (extended) hiccup data structures, a much simpler notion than Notespace Notes.)
This state is updated by the renderer, which is a function in Notespace.

notespace/src/notespace/renderers/gorilla_notes.clj

Line 60 in 71c04bd

(defn renderer [old-ctx new-ctx]

This function's responsibility is to interpret the Notespace state and decide how to update the Gorilla-Notes state (that is, the list of hiccup elements).

Does it make sense?