@micha, @alandipert: I tried to make javeline-like (in sense of being glitch-free) reactive expressions, but with two differences: * child cell/formula register itself in the parent one on deref (i took this idea from freactive.core, but implemented in glitch-free manner) * if you call a function which produces formula inside of creating another formula, it still will be interpreted as reactive input, not literally (no need to do tricks like that (snippet from one of my hoplon projects):

(defn t [k] ((formula (fn [lang] (t* lang k))) lang))

;; NOTE do not inline `c`, it prevents `text` from recognizing it as a cell
(defn ttext [k] (let [c (t k)] (text c)))

hi @ul!

are you using this with hoplon?

ah, forgot link

https://github.com/ul/carbon/blob/master/src/carbon/rx.cljs

no, not yet

i'm testing it with simple home-grown ui lib

it requires some thinking how to integrate to hoplon

snippet was from hoplon project demonstrating javelin which confuses me

because i need to create cell first and then pass it to text

s/cell/formula/

if i call function creating formula in-place, it is not picked up by text

this tricked me several times, so i decided to experiment with alternative implementation of frp

hm

i don't understand the snippet

it was an attempt to integrate tower (i18n lib) with hoplon

t takes a key of message to be translated ans returns formula, which contains translation depending on lang cell value

and ttext is like text, but takes a key and returns text element with dynamic content

and when I do (defn ttext [k] (text (t k)) it doesn't work

only if I do like in snippet, with let

oh right

the tradeoff with marking cells in formulas with deref is that you need to know which things are cells

consider for example:

(defc= f1 (+ x y))

any of those can be cells

+, x, and y

or none

this is useful when you're making components

yep, i understand, but as far as you are using f1 in handlers or in making formulas like in my snippet, you anyway should care about its nature

and sometimes being explicit is even better

i'm interested to see if you can make the autodetatchment work in a ui with async stuff

my autodetachment is kind of high probability, not guarantee

if watch removed — let's try to detach, if nobody care about cell anymore

the problem comes when you have an async process that derefs the cells without a watch etc

like a form submit handler

simple deref outside formula will not create any gc-preventing links

that's the problem, no?

oh i guess there will be references in the closure that will prevent gc

no, because if you pass formula to handler, you have your own link to it

yes

but not autodetatch

so that would be bad

i perform autodetach on every updated cell

after walking graph

you'd stil have the thing in memory but it won't be updating anymore

consider:

(let [c (cell nil)]
  (form :submit #(doit @c)
    (input :keyup #(reset! c @%))
    (input :type "submit")))

ok there we go

would c be autodetatched?

ah but c is an input cell

from what? it does not participate in any formula and can be gc'ed. in my implementation source cells not linked from anywhere

yes this makes sense

but let replace c with lens

give me a moment to think

so, if c is lens (like (formula #(@source-cell) #(reset! source-cell %)) then it will be not autodetached automatically on form disappear. It will be detached only if and when source-cell will be next time updated

it is the weak place, yes, but it is known to me from the beginning — it is why i call it high-probability autodetach, not guarantee

as far as i can see in my apps, this case is rare — if formula has unupdatable sources for a long time and is used just in closure

i like this!

man, thanks for showing me this

thank you for discussion! if some kind of cross-pollination with javelin will happen, i will be happy

i feel like about 10 lbs of cobwebs have fallen out of my brain

i guess the tricky part is to correctly remove watches when things are removed from the dom

doable though, i'm sure

if the removal is done via the ui framework

yes, i'm thinking exactly about the same

in most cases ui framework should care about that

yeah totally

i think it's doable for sure

even in the presence of external libraries like jquery plugins

you could do the detatching then, too

follow back from the cell the watch was removed from, detatching cells that have only one reference left

yes, i'm doing it recursive:

(clean [this]
    (when (and (empty? sinks) (empty? watches))
      (doseq [source sources]
        (remove-sink source this)
        (when (satisfies? IReactiveExpression source)
          (clean source)))
      (set! sources #{})
      (set! state ::thunk)))

that's what flapjax did, i think

yeah the sinks are a sort of reference counting scheme

and the watched cells are like GC roots

if you remove a watch you can then detatch any cells that have only one sink

recursively

and what is good, that if one of the detached formulas is referenced somewhere in the code and reused again later

it will just compute and attach sources and to sources again

that's interesting

seems like magic

haha i know what i'm going to be doing tomorrow

)))

if I get (let [x (li (a))] ..) where (li (a)) is out of my control, how can I apply e.g. :href "#" to the a part via x?

you'd need to use jquery, like this

((-> (js/jQuery e) (.children "a") (aget 0)) :href "")

that should work

where e is the (li (a ... element

does that work for you?

you should be able to even have the :href value be a cell and it'll update reactively

sure, thanks @micha