Clojurians Log v2

My mind goes BOOM! 🤯

Would be sweet if plain data was supported as event handlers. So you could have [[::increment this]] there instead of (fn [] [[::increment this]]) . Like #replicant. It is so liberating with data only views. However, I say this without knowing what this is, and if the rest of the views are data.

Yea. In my mind, there are at least two parts to the question: 1. How do we represent the event handler? 2. How do we build tools that make it easy to provide event handlers for common use cases? I'm not sure which question you're more interested in. I've been working on the features required for the 7gui demo, but I now want to spend some time on some low hanging fruit. One piece of low hanging fruit is to build an autocomplete selector that let's you quickly choose from existing intents like ::increment. That would make it easy to add event handlers for most common use cases.

The other problem is that there's so much low hanging fruit that I'm not always sure where to begin!

Sounds like an awesome situation.

I don’t know which question I asked, really. But Replicant lets you register an event handler and will call it whenever there’s an event to process, handing you some meta about the event, and the return value of the event function, or the data if it is not a function. I have only used the data variant and I love it so much!

I may allow using value like a vector or keyword as syntactic sugar, but there are cases where a function is required so it will always need to be supported. For example, any event handler that responds to a mouse event and uses the mouse position.

Replicant sends the event as meta data to the event handler. So it works great with pure data even for those cases. Replicant also supports using a function, but so far I have never needed that.

I think that makes sense for replicant, which is relying on the underlying DOM event handling. I'm not sure it makes sense for membrane: • membrane tries to make a more distinct separation between events -> intents -> effects. Making the effect handler require both intents+events introduces coupling • An element event handler receives event data in local coordinates, but the actual event is usually a window event in global coordinates. Which event data do you include? • The DOM event handling makes it awkward to deal with a single mouse event that generates multiple intents from multiple child elements. This isn't usually necessary for application code, but is extremely valuable for building interactions like drag and drop. • Including the event data with the effect call doesn't really work well with event wrapping and bubbling which the DOM event handling only sorta exposes in a procedural way. So I agree that having a simple data representation that works for common cases is great (eg. all of the 7 tasks in 7gui could just use the data version), but it doesn't seem to be sufficient for more complex interactions. I would be interested to see how replicant would deal with more complex cases, https://clojurians.slack.com/archives/C06JZ4X334N/p1741312782861049.

I’m building a drag and drop design app right now. So far I’ve been having a great time. We’ll see what I say when I’m done with all the mechanics.

Neat! It would be interesting to see your take.

Let me know if you wanna screen share and I can show you where I’m at. Even though there are some crucial mechanics I haven’t started with yet.

That would be great. I'm pretty flexible for the next few hours if that's convenient.

So… now? 😃