Clojurians Log v2

I looked first at the stack overflow. Let me play with your example a bit. btw, yesterday @lidorcg had a similar question, and I with his kind permission I will turn our exchange into a new bit of doc. Now let me try your example. brb.

Ah, OK, the correct make syntax would be sth like

(make :test 
   :a (cI 1)
   :b ....etc...)

(div {}
  {:name :todoapp
   :a 1}
  (div {}
    {:d (cI 3)}
    (button
       {:placeholder "placeholder"
        :class "edit"
        :onclick #(prx :button-parent-is me)})))

What the original code did was make a model instance with one property, :test, and the value: {:a (cI 1) :stuck_out_tongue:... etc

Disclaimer: me and @aviv846 are working together on the same project (so our questions might not represent statistical significance 😅 )

Doh! My first guess was that @aviv846 had worked off yesterday's thread! Thx for clarifying. 🙂

@hiskennyness thanks, the complete example for the first question is:

(defn matrix-build! []
  (reset! matrix
          (make :todoApp
                :c {:d (cI "Aviv")}
                :dom (cF
                      (with-par me
                        (div
                         (str "hey " (mget (mget (mget me :parent) :c) :d))))))))

Well, we have quite a few things to sort out. You should not have to code with-par, or :dom or :c {:d (cI...)}. That said, your code creates a model of type :todoApp with one of the two properties being :c, which gets the value {:d (cI "Aviv")}. Cells does not look inside a property value for cells such as (cI "Aviv"), and the map {:d (cI "Aviv")} as you surmised is not a model` to which you can apply mget. Are you planning on changing :d to see the div change?

Ah, you mentioned "nested object". Are you exploring what it is like to code MX with a searchable model space?

I am starting to see why we have :c {:d (cI 3)}. As we discussed yesterday, MX includes the family API that supports a nice, well-tested way of assembling individual models into a "matrix" of inter-reacting models. If you do not want to use the family API, that is fine, but we should talk about various implementation issues. In any case, your example would be better as sth like:

(make :todoApp
  :name :todoApp
  :a 1
  :c (make :d (cI 3)
           :dom (cF ...not sure...))
  :dom (cF (with-par me (button
                          {:placeholder "placeholder"
                           :class "edit"
                           :onclick #(print me)}
                          "Log it"))))

btw, are you using:

[com.tiltontec/matrix "5.0.1-SNAPSHOT"]
[com.tiltontec/web-mx "2.0.2-SNAPSHOT"]
[com.tiltontec/mxxhr "2.0.0-SNAPSHOT"]

We changed that on our workspace 😄

You know what this does to your warranty, right? 🤣 But soldier on, have fun, I will support as best I can. 🚀

🤣 I got confident playing around with the shadow build

@hiskennyness 1. Yes i was going to change the :d you mentioned before 2. adding another make to make it work was solving it, but the issue with another make is that it creates another hierarchy, we are looking for some way to keep the me in the same level, so that accessing me from the :d will point to the todoApp

Specifically:

make won't create widgets for the nested object?

{:d (cI 3)
          :dom (cF (with-par me (div (mget (mget me :c) :d))))}

so the whole “nested object” will be belong to the todoApp, no matter how nested :c

If you do :c (make :d (cI 3)) then that nested MX will be in its own world.

If you wrap :c in a formula, the nested object can see the :todoapp (untested):

(make :todoApp
      :name :todoApp
      :a 1
      :c (cF (let [todo-app me]
               (make 
                 :d (cI 3)
                 :dom (cF (with-par me (div (mget (mget todo-app :c) :d))))
      :dom (cF (with-par me (button
                              {:placeholder "placeholder"
                               :class "edit"
                               :onclick #(print me)}
                              "Log it"))))

(make :todoApp
      :name :todoApp
      :a 1
      :c (cF (make 
               :d (cI 3)
               :dom (cF (with-par me (div (mget me :d))))}
      :dom (cF (with-par me (button
                              {:placeholder "placeholder"
                               :class "edit"
                               :onclick #(print me)}
                              "Log it"))))

So the way to create nested reactive objects is through cF + make?

You do not need the cF, but if you want the created matrix to have a reference to the outer matrix, cF provides that as me. Without that, the outer matrix of course sees its own property :c, and the matrix it contains, so it can interact with that.

Is there any way to have a notion of dependency nested deep inside a matrix (like our example) or is the granularity of dependencies coupled with the notion of this (i.e me) The first example @aviv846 shared is really good: We're trying to have [:test :b] depend on [:test :a], and that me will still point to the root, in this case example. Is there a way to have our cake and eat it?

I'll note the inconsistency with that example: :b should not address directly to :a as in the example (mget me :a) but rather (mget-in me [:test :a]) P.S Let's pretend mget-in exists

(def example (make :test {:a (cI 1)
                          :b (cF (str "a value is:" (mget me :a)))
                          :c {:d 3
                              :e (cF (mget (mget (mget me :test) :c) :d))}}))

No, no second model

Just deeply nested one model

Where one leaf depends on another

OK, no, a model has properties which we can make reactive. The values of those properties are out of reactive scope, even if a value is {:a (cI...)} or {:b (cF...)}. To get what you are after, create a model as a property of the original model, or even a separate model.

But you have me thinking. I have played with standalone cells, and you can see them in the MX test suite. Let me refresh my memory. brb

Alright, so models dictate the reactive scope + the binding of me Is my understanding correct?

Actually my first impression was that your atomic building blocks are standalone cells style javelin

There are examples of standalone cell in here: https://github.com/kennytilton/matrix/blob/main/cljc/matrix/test/tiltontec/cell/core_test.cljc I never use them. 🙂

So model only wraps first level properties in cells am I correct?

And binds me

Javelin and MX are alike in spirit, esp. transparency, which is why I am a big fan of Javelin, but not much more.