Clojurians
#hoplon
<
2016-05-08
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

thedavidmeister06:05:06

@micha yeah, i was just saying that i think it’s good simple_smile

thedavidmeister06:05:25

although, “fixing” things with a timeout always feels like a bit of a hack

dm307:05:43

in javascript land it's a little more deterministic

dm307:05:20

settimeout places a function to run into the queue

dm307:05:33

which will happen after all of the other things already in the queue

dm307:05:47

such as other keyup handlers

dm307:05:19

(.setTimeout 0) I mean

thedavidmeister07:05:29

@dm3: sure, but as soon as you fix 2+ things in a single event with a timeout, you run the risk that those two things are only working because they happen in a specific order

thedavidmeister07:05:04

maybe if you remove or temporally move one of them, “something unrelated breaks"

thedavidmeister07:05:52

it may be deterministic, but it may also be complicated and hard to predict the “real world” ramifications of

thedavidmeister08:05:27

like, is there a problem if i trigger a keydown for another key using similar logic in the exact moment between the first keyup and when the timeout is queued?

thedavidmeister08:05:36

the order of events should be

thedavidmeister08:05:45

1. process keyup

thedavidmeister08:05:49

2. process keydown

thedavidmeister08:05:52

but we’d end up with

thedavidmeister08:05:56

1. process keyup 50%

thedavidmeister08:05:12

2. process keydown 50%

thedavidmeister08:05:20

3. process keyup 100%

thedavidmeister08:05:24

4 process keydown 100%

thedavidmeister08:05:27

will this cause problems? i dunno.

dm308:05:43

yeah, if several handlers are interdependent

dm308:05:48

it can lead to issues, I see

thedavidmeister08:05:53

interdependent is bad, but it can also be bad if two things are just clobbering each other’s data/DOM because they aren’t aware of each other and you can’t co-ordinate the order that things happen in beyond “add to queue please"

thedavidmeister08:05:45

i pretty much assume everything I “fix” with a timeout is just a bug waiting for future me to “fix for realz” 😛

leontalbot12:05:05

Hi guys! I think I read that @micha made a boot task to concert html to hlisp. Where can I find it? Thanks!

micha13:05:32

@leontalbot: it's the html2cljs task that's part of the hoplon/boot-hoplon jar

leontalbot13:05:54

Thanks! hmmm. Wrong number of args (1) passed to: cli/argspec->cli-argspec

micha15:05:39

@thedavidmeister: yeah timeouts are not great

micha15:05:11

this <input> situation is like the lifecycle protocols in react really

micha15:05:21

lifecycle protocols are queues like that

micha15:05:41

but worse because they're at the component level

thedavidmeister15:05:45

i haven’t actually used react yet

micha15:05:24

the correct solution here is to engineer the <input> state machine

micha15:05:28

and implement that

thedavidmeister15:05:29

i will also try the thing that you posted turning the value to nil before removing it so it triggers an update, or similar

micha15:05:06

i think the browser's input implementation isn't a good design, probably

thedavidmeister15:05:01

i think that’s it

thedavidmeister15:05:12

but also, the way that keyboard events work

thedavidmeister15:05:20

would make it pretty tricky to override the behaviour

micha15:05:32

cells can act like timeouts, but with dependency graph

thedavidmeister15:05:34

with numeric keys, and only up/down events to work on...

micha15:05:39

so perhaps there is something there we can do

micha15:05:54

the dependency graph would make the queue unnecessary

micha15:05:40

the processes would always happen in the correct order

micha15:05:58

javelin does include functions and macros to mutate formula cells

micha15:05:04

change the formula and stuff

micha15:05:15

so maybe that could be used instead of attaching event handlers

micha15:05:45

like maybe the input has one or more cells to hold its internal state

thedavidmeister15:05:03

(d/transact!  state/conn (add))
    (d/transact!  state/conn
                  (if-not (item-data/raw? v)
                          (retract)))))

thedavidmeister15:05:35

(d/transact!  state/conn
                  (if (item-data/raw? v)
                      (add)
                      (retract))

thedavidmeister15:05:53

and now i think i have a workaround that will be OK for me

thedavidmeister15:05:01

… it was pretty confusing

micha15:05:19

i think javelin was doing the right thing though, and loop-tpl

micha15:05:28

like in 99% of the cases that's the behavior you want

micha15:05:31

and expect

thedavidmeister15:05:45

yeah, i dunno about 99%

micha15:05:46

i think we need a better <input> implementation

thedavidmeister15:05:56

but i can see “set to empty, then remove” being an important hoplon pattern

micha15:05:26

you will only ever need that with the input things

thedavidmeister15:05:39

you say that, but i’ll find something, someday 😉

micha15:05:49

yeah i guess you will see this problem whenever you have a formula cell that is bound to a property that can be changed by the browser arbitrarily

micha15:05:16

so you'd see the same issue if you had a formula cell bound to the css width for instance

micha15:05:39

(div :css (cell= (:width w}) ...

micha15:05:56

if you resize the window for example

micha15:05:02

that's like typing in the input

micha15:05:18

the formula doesn't know that the window was resized

micha15:05:30

but that causes the width of the element to change, possibly

micha15:05:36

same kind of thing

micha15:05:55

so i guess it's a 2-way databinding problem really

micha15:05:30

yeah this might be the place to use mutation observers

micha15:05:00

if you know that a property can be arbitrarily changed by the browser underneath you, you use some special annotation when you set the attribute

micha15:05:31

and hoplon would install a mutation observer that will trigger the update whenever something modifies that property

thedavidmeister15:05:34

well, we were talking about something like this the other week

thedavidmeister15:05:44

“trigger when something is in the viewport"

thedavidmeister15:05:52

i don’t remember who was doing that...

micha15:05:59

yeah that's another use for mutation observers

thedavidmeister15:05:54

mmm, actually that would be a really easy way to implement breakpoint classes

micha15:05:23

yeah that's what jumblerg was working on

micha15:05:06

oh nm, he was going to use the mutation observers for layout constraints