@flyboarder the (cell= (and data value)) was something i tried too. yes, it evaluates any time either data or value changes but it only ever returns value, the do! will only trigger on the return value, not simply cell execution

that's just because and only returns the last truthy value, but even if it returned the whole thing, we don't want data to get serialized into our input value...

@thedavidmeister yeah I see your point

@flyboarder i'll try to write a nicer version of my proposed fix

i haven't used alts! before, but i think this is what it's for

(and (sequential? value)
               (every? cell? value))
          (let [vs (apply javelin.core/alts! value)]
           (do-watch vs #(do! elem this (first %2))))

seems very close to what i want

but for some reason the initial value of vs created by alts! drops the first value in the sequence so that (first %2) sees data rather than value

i'll play around with it more later 🙂

conceptually it's very close to the (cell= (and data value)) approach

I’d rather there was something explicit to serve this issue, e.g. (input :value (hoplon/two-way :cell value-cell :depends [data]))

then you can add either your own do! multimethod on top which will implicitly create that from [value-cell data] or abstract any other way you like

@dm3 but it's not 2-way, that's the point

it's avoiding 2-way

yeah, maybe not the best name

but we somehow need to express what it’s about

i thought alts! more or less did what you're suggesting, right?

creates a cell that evaluates when any of a list of other cells changes

well, when you see (input :value [x y]), what would you think?

what’s the value of that input?

or (input :value (alts! x y)) for that matter

what, if i know hoplon or don't know hoplon?

because if i don't know hoplon i have no idea what the value is

value is an attribute on input, no?

sure... initially

so i'd be wrong

because cells have a time model

yeah, but [x y] isn’t a cell

x and y both are though

what if y isn’t?

(and (sequential? value)
               (every? cell? value))

what I’m trying to say - I think this deserves a more explicit treatment

rather than encoding its type into a sequence

ok maybe

i see what you're saying

but the current behaviour is implicit based on whether something is a value, function or cell

what do you think (input :focus x) does?

as you said - we already have 3 types supported

but if x is a function, it doesn't even trigger do! it triggers on!

yes

I don’t think adding a 4th implicit option is a good idea

so, when i was first learning hoplon, this was 100% something i had to learn

but now that i know hoplon it makes perfect sense

i don't think having 3 implicit options and 1 explicit option is a good idea

it should be internally consistent either way

hell, i'd probably support a proposal that if you pass a list of functions, to bind them all as event handlers 😛

or maybe there's an explicit api and an implicit one and you use whatever is comfortable

e.g. :on/click vs. :click and passing anything other than a function to the former is an error

well, I’m not a fan on overloading this thing even further

i don't necessarily disagree with your criticism of how it works

but this bug is actually really bad for what i'm trying to build

and i don't want to deal with the implicit/explicit can of worms if i can avoid it

like what if you want to intepret a sequence of cells as and instead of or

it's neither

it's the first value of alts!

it’s or

no it isn't

because a falsey value in the first slot will still trigger

it's alts! 😛

right 🙂

;; Creates a formula cell whose value is a list of changed values in the cells cs.

imo that seems like the most natural fit for interpreting a list of cells anyway

because and and or already exist and work better inside a cell than outside

the only "trick" that i'm using is extracting the first item in the list as "the value"

that bit i'll admit is a bit of hand waving

have you explored mutation observers?

well that is 2-way data, right?

and, no, to answer your q

i assume it would work though

worst case scenario you get an infinite loop where "changing" the value to the same thing triggers another "mutation"

potential scenario is that there are weird bugs where you type stuff and the keys you press flicker in/out of existence as data propagates around javelin and back into the DOM

best case scenario is that you're reading from the DOM, so it's 2-way i think

not sure how it’d work

if Hoplon defined some known attributes as being mutation-observed

like input:value

well...

then on mutation you’d call the callback

i put this up https://github.com/hoplon/hoplon/issues/176

i'd like to see more support in hoplon for the various *Observer APIs that are maturing in general

but i don't know if it's a solution for my current problem, or even if it is, whether it's a good idea in this case

seems like we have to pick the least bad option out of:

- have a known bug that is pretty bad in some situations

- add to the implicit api for do!/on!

- have an implicit/explicit split in that api

- do something with 2-way data

I’d have to play around with this issue to actually completely understand why we get the result that we get

and explore mutation observers as a possible solution once I understand

only then I’d consider adding something to Hoplon core

so you might be a step ahead

otherwise I’d use a separate attribute with a special do! which understands a seq of cells

the issue is that i cannot sort inputs on their value

so, for example, if i have a form with a table layout and i want to click sort, i can't do that 😞

is it because your inputs are encapsulated and set :value to something you pass through?

I mean - why doesn’t the custom attribute solution work in your case?

why should i need a custom attribute for such a basic need?

you shouldn’t! 🙂

i mean, sorting elements is hardly advanced UI-fu

but I somehow feel that the problem/solution space isn’t explored sufficiently. I may be wrong!

oh sure

so... the short version

after days of investigation

is that the thing that makes do! work at all is a do-watch on whatever cell gets associated with :value

so if that cell doesn't change its value, which is possible during sorting operations when you have multiple elements with the same value, then the do! is not triggered

so it looks like values are "copied" after the sort rather than "moved"

e.g. 1 1 2 should becomes 1 2 3 if you change the first 1 to a 3

but it looks like 3 2 3 in the UI because the first input retains the value 3 and hoplon changes the last input to 3

when hoplon sets the last number to 3 it must also set the first number to 1 to "move" it

so a mutation observer can probably detect that you typed the number 3, but so does the :input event, so what next?

what we can do though, is trigger do! when either the value cell changes for a single element or on all the elements whenever the overall sort order changes

ok, so we have to have a sequence of input -> reset! cell -> sort -> apply do!

yeah basically, so the sorting "redos" all the elements

which we have now, but apply do! happens only where the value did change

uh not quite

something in between

yeah

it’s tricky to explain succinctly

yes it is

which is probably why the bug has survived so long

it's basically because when you have elements in a for-tpl it doesn't actually re-order elements in the DOM

it just binds values to DOM attributes

which simulates a sort

but the simulation is not perfect 😕

yeah

i actually wrote a test for the issue, so if you want to mess around with mutation observers i can plug it into the test and see how it goes 🙂

would love to, but not sure if when I’ll have the time 😞

mmm, i know that feeling

actually my fix doesn't totally work anyway because alts! doesn't quite do what i expected

so i've still got work to do on this

oh, alts! is not what i want at all!

hah

or at least, not the way i'm using it

(and (sequential? value)
               (every? cell? value))
          (let [vs (apply javelin.core/alts! value)]
           (do-watch vs #(do! elem this @(first value))))

this works

@micha @alandipert either of you have thoughts on ^^?

also, what is the process for reviewing/merging PRs? https://github.com/hoplon/hoplon/pull/189/files should be a lot less controversial

@thedavidmeister #189 doesn't seem controversial, I can merge that, it's safe enough 😝

@flyboarder @thedavidmeister yes looks good to me too - merge at will

🚀

Just going to put this here....

https://twitter.com/degree9io/status/885280570204315648