> 1. and 2. are both pretty tough/opaque, as you either have to know perfectly which code will and won't be understood by the macro, or have to understand the macro to a level where you can rewrite all the refs by hand. 3. is kind of doing the work you're using a component to avoid. Yea, I think that's a fair point. I've improved on this a bit, but I think there's still more room for improvement. The most recent version of membrane now supports destructuring (inside both let and for ). There's also a list of supported forms in this https://phronmophobic.github.io/membrane/membrane-topics.html#Defui-Limitations of the docs. Ideally, membrane components should "just work". Are there any forms that are missing that you think should be included? There's an issue for adding better support for type of use case you're describing (https://github.com/phronmophobic/membrane/issues/61). It probably makes sense to add an example somewhere that explicitly wires components (maybe https://phronmophobic.github.io/membrane/membrane-topics.html#Explicitly-Providing-References).

> (4? :extra :$extra :context :$context) implicit ones Yes, that's right.

Do you have some code/psuedo code for how you would want to express your UI? Maybe we can have membrane support that.

I think I can work with the new "for" support, that plus the document are a great addition for me

cool. It's always hard to know what's missing or unclear. If you run into anything that's clunky or confusing, don't hesitate to ask.

There should also probably be a way to get feedback if you do accidentally use an "unsupported form".

So I was trying to reverse engineer an explicit binding to work out how to be able to pass explicitly to an arbitrary intermediate fn, maybe the biggest question was what happens with the four implicit parameters, the other complicating factor was how to pass the ^contextual focus pair of params as presumably the rules are different

I mean what you've built is a small compiler inside a cond statement right, I think that's kind of unavoidable and must have some implications

As in similarly to core.async, as described in the "deep walking macros" YouTube video

Yea, it probably makes sense to write it to use the tools.analyzer lib at some point.

Regarding the 4 implicit parameters, it's really 2 parameters and their references. extra is for the component's incidental state and context is used for the component's contextual state

One trick to avoid dealing with default and contextual parameters is to write a small wrapper component that takes care of that for you:

(defui my-wrapped-component [{:keys [text]}]
  (basic/textarea {:text text}))


(defui component-with-defui-call [{:keys [my-text my-component]}]
  (let [my-component-extra (get extra [:my-component-id])]
    (my-component {:text my-text
                   :$text $my-text
                   :extra my-component-extra
                   :$extra $my-component-extra
                   :context context
                   :$context $context})))

Here's a more "real-world" example of calling a dynamic component, https://github.com/phronmophobic/spreadsheet/blob/main/src/com/phronemophobic/membrane/spreadsheet.clj#L668

Ooh interesting thanks I'll take a look

I don't understand your code snippet, is there a typo where the my-component inside the let should be my-wrapped component, and do the extra and context symbols exist inside the macroexpansion in a kind of anaphoric way?

my-component isn't a typo. since components are regular functions, my-component is being passed as a parameter. However, the defui macro doesn't know that it's a component, so you have to manually wire the implicit extra and context parameters.

the extra and context symbols exist inside of defui implicitly

maybe the https://github.com/phronmophobic/membrane/blob/master/src/membrane/example/kitchen_sink.clj#L247 example is more approachable

the API for dynamic components like this could use some work because I haven't quite figured out the best way to expose it, but it's really useful in certain scenarios.

re your previous snippet: I see that is an interesting example of a pattern. I was just trying to think of a similar thing, can I write a fn that returns the state and component as a tuple then apply the first to the second in a defui so that it wires up. Your pattern shows how to get around the component being opaque but what if the params (in the map) are also opaque, ideally something like (apply c (merge m-with-params {:extra extra :context context :$extra...})) would work, but it won't because defui won't understand the merge call right

sorry my code is missing a square bracket should be [(merge...

Let's say you have:

(defui a-component ...)

(defui my-parent-component [{:keys []]
  (a-component (merge ...)))

it would almost be nice to be able to tag defui components with metadata, just tell the outer defui macro that this parameter is a component

if you had this instead:

(defui my-parent-component [{:keys [dynamic-component]]
  (dynamic-component (merge ...)))

yeah I'm with you so far

> it would almost be nice to be able to tag defui components with metadata, just tell the outer defui macro that this parameter is a component I think that actually works, but it's undocumented since I'm not totally sure what the API should look like for this

so something like (defui [{:keys [^some-component-tag component state]}] (apply component state))

(defui check-dynamic-call-with-meta [{:keys [my-component]}]
  (^{:arglists ([{:keys [text extra context]}]),
     :membrane.component/special? true,}
   my-component {}))

wow this is clojure syntax I haven't seen lol

it that extended metadata syntax

*is that

I guess it's less common, but yea

This is a bit of implementation detail, so I can't guarantee it won't break at some point, but just trying to explain some of the concepts.

this is very helpful, knowing that extra and context are what I'd call anaphoric is very useful and seeing this metadata to trigger treatment as a component

Thanks for sharing your thoughts. It really does help me think about some of the use cases so that I can work on a more permanent solution.

Adding a link to this discussion on the github issue before I forget , https://github.com/phronmophobic/membrane/issues/61

in your example, the text key is necessary? that means that the defui needs to know what the component is even if it's effectively wiring a pointer to a component to a pointer to an opaque map (which is knows the "location/path" of)

thanks so much for your help, fwiw I'm trying to use membrane in anger and imo the "edge/advanced" cases might actually where membrane has the most value as there's a venn diagram intersection of "want arbitrary control/flexiblity" "not using the DOM/react/a fixed java framework"

The text key is necessary for the current implementation. Right now, the caller does a lot of work passing incidental state along. It's probably possible to delegate that work to the defui implementation. As an example, if you call (textarea {:text my-text}), currently the caller will add the missing incidental state like the cursor position. However, as long as textarea receives the extra and context parameters, then the textarea implementation could probably look for missing state in extra automatically.

Some of the recent changes simplified the defui implementation a bit which would make that easier.

I think what you've given me is enough for my problem: wiring textboxes that come out of a long and opaque pipeline back into a defui component that connects them, I can use your metadata method, I and manually list the parameters

I think that should be a relatively small change to implement that improvement. Even though membrane is marked as beta*, I still try to avoid breaking changes. So even though it's a small change, it is a big enough change that I would want to check to make sure it's backwards compatible.

which improvement?

making it so that the text key wouldn't be required in the metadata

got you

Just realizing if I remove the need to have the text key, then dynamic calls could be supported just by using a single metadata key:

(^::component/component my-dynamic-component arg)

:arglists ([{:keys [text extra context]}])

It seems to work in my repl

I think since this is a reader macro, it's correct without the quote

you think you know a language lol

https://clojure.org/reference/metadata#_metadata_reader_macros

not you as in "one thinks", apparently I have much to learn

> Note that metadata reader macros are applied at read-time, not at evaluation-time

even kondo doesn't understand

oh, I didnt mean to get you in trouble with kondo 😛

😂

so the first part "producing" and second "consuming" works great:

(mapv (fn [_]
           [textarea {:text "text 3"}])
         (range 1))
   (vec (for [[c s] c+ss]
          (^{:arglists ([{:keys [text border? font focus textarea-state extra context]}])
             :membrane.component/special? true}
           c
           s)))

but when there's an intermediate defui it seems not to be working

(defui wrapped-textarea [{:keys [x y
                                 text]
                           :or {x 0 y 0}}]
  (translate x y (textarea {:text text})))

(mapv (fn [_]
           [wrapped-textarea {:x 0 :y 0 :text "text 4"}])
         (range 1))
   (vec (for [[c s] c+ss]
          (^{:arglists ([{:keys [x y
                                 text
                                 extra
                                 context]}])
             :membrane.component/special? true}
           c
           s)))

so the first example works, but the second doesn't?

if that makes sense, the mapv and vec fragments are in different parts of the code but they're corresponding consumers and producers

I've tried it passing through more or less parameters explicitly to the wrapped textarea

also as an aside not sure if textarea or buffer is more appropriate, buffer is backed by liquid and textarea more component-coded from what I can see but I don't know enough about liquid to know what will be the key difference

the buffer/liquid stuff is meant for clojure code whereas textarea is meant for text editing

I realize that a workaround would be to apply my translations etc explicitly in the "binding" defui which might be manageable but will get verbose pretty quickly, another workaround would be to tree-traverse the defui and expand a macro for doing that but a bit fiddly

let me try it locally.

I'm heading in, I'll check back tomorrow if you've gotten to it, thanks again!

This seems to work for me:

(defui wrapped-textarea [{:keys [x y
                                 text]
                           :or {x 0 y 0}
                          :as m}]
  (ui/translate x y (basic/textarea {:text text})))

(defui parent-wrapper [{:keys [c+ss]}]
  (vec
   (for [[c s] c+ss]
     (^{:arglists ([{:keys [x y
                            text
                            extra
                            context]}])
        :membrane.component/special? true}
      c
      s))))

(backend/run (component/make-app #'parent-wrapper
                                 {:c+ss
                                  (mapv (fn [i]
                                          [wrapped-textarea {:x (* 5 i) :y (* i 30) :text (str "text " i)}])
                                        (range 5))}))

The mistake I make a lot is using defn instead of defui when defining a component.

Which version of membrane are you using?

After a night's sleep the same code is working, sorry I must have gotten to the delusional stage

Or more likely wiping the shadow-cljs dir eliminated some compilation problem

I'm using the latest master on your GitHub but patched so that it loads on nodes main process whilst silently not loading audio or fonts or the main webgl driver but components etc work, also added rotation for webgl but haven't touched the core component code

Also for me this is sort of partly working, did you try in webgl, clicking the bottom textarea and entering text? I get this weird error something like the translation offset doesn't propagate inside the wrapped component so unless it's sitting on 0 0 or close I can't click it

;; works mode.translate-textarea7 [(rectangle 0 1000) (translate 0 300 (textarea {:text translate-textarea3}))] ;; fails :mode.translate-textarea8 [(rectangle 0 1000) (wrapped-textarea {:text translate-textarea3 :x 0 :y 300})] ;; works :mode.translate-textarea9 [(rectangle 0 1000) (wrapped-textarea {:text translate-textarea3 :x 0 :y 0})]

I was able to run my version with webgl:

(defui wrapped-textarea [{:keys [x y
                                 text]
                           :or {x 0 y 0}
                          :as m}]
  (ui/translate x y
                (basic/textarea {:text text})))

(defui parent-wrapper [{:keys [c+ss]}]
  (vec
   (for [[c s] c+ss]
     (^{:arglists ([{:keys [x y
                            text
                            extra
                            context]}])
        :membrane.component/special? true}
      c
      s))))

(defn -main []
  (defonce canvas-info (webgl/run
                         (membrane.component/make-app #'parent-wrapper
                                                      {:c+ss
                                                       (mapv (fn [i]
                                                               [wrapped-textarea {:x (* 5 i) :y (* i 30) :text (str "text " i)}])
                                                             (range 5))})
                         {:container canvas})))

Do you have the error?

I'm running a sightly more involved method but the key parts look identical, I'm clearing the cache each time now and ran enough tests to be certain that with my setup, nested translation is somehow stopping the ability to gain focus, I'll make a blank solution and do a truly minimal test

As in I'm using a cond statement etc it shouldn't be different in any other key ways

My suspicion is that it's not related to the position, but that either the :$extra, :$context, or another reference key isn't a path to an editable location

But my tests only modified position and made the difference between working and not working

Several times with a cleared cache, but I'll do the difference and make a totally blank project

And see

oh ok. hmmm

Maybe there's a difference buried in the fluff around this but I sure hope not, I'll also check membrane versions but I had bumped it

Also I'm using electron I also pray it's not that

another debugging trick is to use wrap-on to print out the intents and events that are going to the text area:

(defui wrapped-textarea [{:keys [x y
                                 text]
                           :or {x 0 y 0}
                          :as m}]
  (ui/translate x y
                (ui/wrap-on
                 (fn [handler pos]
                   (let [intents (handler pos)]
                     (prn pos intents)
                     intents))
                 (basic/textarea {:text text}))))

I don't think electron should affect it (hopefully 🙏 )

Is that an identity with a smuggled side effect

Nice I should make a note of that

I'll reproduce so you don't think I'm going mad although I gave up and moved the translation explicitly to the wrapper if that makes sense

haha. I use println debugging often 😬

And then it worked , as in my first example but pulling the numbers from the state

I use a central atom that I log things to by topic and sometime serialize but everyone loves portal and tap

I'll sometimes use https://github.com/phronmophobic/spreadsheet

I'll probably make my own version of portal/clerk/reveal at some point

I have the same ambition let me know if you do lol although I'm busy failing to make and sell a product

I saw you had something like that already

The thing I don't get about portal is it seems like the data representation is pretty sparse.

I use https://github.com/phronmophobic/viscous all the time. I feel like it should be the default printer everywhere, but I seem to be the only one.

I heretically think that Emacs kind of holds the community back and we're slowly reinventing a more useful light table with calva/joyride/portal

I say we, borkdude mostly