Interesting! I was referring to the notion of taking a rendered html page and making selective parts reactive (without necessarily re-rendering the intermediate tree in cljs)
> a Matrix application is largely one tree of models, comprising all interesting application state. All models (other than the root node) know their parent, and of course they know their children, an ordered list, if any.
from https://github.com/kennytilton/mxweb-trainer/wiki/No-Widget-Is-An-Island#easy
Can 2 matrix reactive html elements be initialized on 2 separate branches of a (static) server-side-rendered HTML page, without having to (re)render in cljs all the elements in-between the reactive elements on the branches (the trunk, fork, etc). Yet have those 2 elements be reactive in a shared (global?) context, so that they could react according to the same formula changes?
This would allow me to make disparate small pieces of a pre-rendered static page reactive, in a shared context, and to each other, without having to re-write a large chunk of the page, just for connective tissue…
I think you said yes to this before, but I wanted to be more explicit..
I’m guessing that separate mx-instances, on separate elements, on separate branches of an html page could all still react together, to cells in the shared js context (namespace). But maybe the tree navigation functions, like fget are of limited use in this case…?
@chromalchemy asked:
"Can 2 matrix reactive html elements be initialized on 2 separate branches of a (static) server-side-rendered HTML page, without having to (re)render in cljs all the elements in-between the reactive elements on the branches (the trunk, fork, etc). Yet have those 2 elements be reactive in a shared (global?) context, so that they could react according to the same formula changes?"
(a) I am speculating, since I have never tried this.
(b) Yes,
If you look at the start-up code of the trainer, or any other mxWeb demo, you will see how a new matrix/app gets spliced into existing HTML:
https://github.com/kennytilton/mxweb-trainer/blob/31f051f466e15a54daefd0588173dc12c67e8c39/cljs-trainer/src/main/mxweb_trainer/core.cljs#L18
The code converts the matrix map to dom, looks for a dom element with the id "app", and sets that elements innerHTML to the Matrix DOM root.
You could do this with any number of static or dynamically generated dom nodes. That addresses part of your requirement.
"I’m guessing that separate mx-instances, on separate elements, on separate branches of an html page could all still react together"
Still speculating, but yes. Two cells will "link/unlink" happily as long as they are cells, without concern over which matrix they inhabit.
"But maybe the tree navigation functions, like fget are of limited use in this case…?"
Well, you would still use fget, or write your own variant (it is a fairly obvious tree search of parents and children), but in this multi-matrix scenario you would have to:
• maintain a dictionary of root dom nodes where each matrix dom got injected; and
• write a multi-fget function that continues "up" to search that dictionary when trying to find desired state; or
• I am guessing that, in this multi-mx scenario, you would know which other matrix has the state you are after, so you could just specify that matrix as the fget "where" parameter.
Mind you, I assume we are interested here in preserving fget's inside-out, naturally scoped search. I think that makes apps less brittle. If that is not the case, just use whatever info you have about which matrix to look in, find the model you want, and mget the desired property.
If you need multi-matrix for your project we can give this a whirl.
@chromalchemy asked: "Also on a more practical note. Could Matrix html-tags as cell work with htmx powered html attributes? https://htmx.org/ (edited)" I just glanced at the promo doc. (a) I do not know. (b) Now we are on thin ice. Just guessing that HTMX has lifecycle requirements that mxWeb might violate.
Is HTMX a requirement? We could give it a try.