opened
cryogenian
username_0
How do you think is it possible to add pseudoattributes for `HTML` like `clicked`, `focused` etc? And if it setted to `true` generate an event. Can be helpful to change focus or select texts.
Generate events
issue
created
paf31
username_1
It should be fairly simple to implement these in terms of `init`, no?
comment
created
cryogenian
username_0
Erm... Could you give a clue how to do it?
comment
created
paf31
username_1
Something like

```purescript
H.div [ A.init if shouldClick then yield ThingToDoOnClick else empty ] []
```

?
comment
created
cryogenian
username_0
Do you mean `initializer`? I can't find `A.init`
comment
created
paf31
username_1
Yes, sorry.
comment
created
cryogenian
username_0
I mean not to do something that we do when events are fired, but to fire those events. In example `e.focus()` or `e.select()`. I'm afraid it can be done only by `Widget`'s `init` not `A.initializer`.
comment
created
paf31
username_1
Sorry, I was thinking of the jQuery-style, where `el.click()` means "generate a click event", and assumed you just wanted to generate the input to the state machine without a click from the user. Maybe we do need #89 after all...
comment
created
paf31
username_1
Can we do this with hooks?
comment
created
paf31
username_1
@username_3 @username_0 I've put an (untested) sketch of a possible solution on the `hooks` branch. I think we can use this to define custom attributes like `focus`. I don't have time to work on this any more tonight, but I can take a look tomorrow if this approach looks ok.
comment
created
paf31
username_1
Here's a thought. What if you used a data attribute, and we did an effectful pass over the DOM after each render, to apply any custom attributes, using jQuery or `simple-dom`? I could add a hook to `runUI`, and it would probably be cleaner than hook attributes.
comment
created
garyb
username_2
That might be an option, but manipulating the DOM outside of virtual dom can really be asking for trouble when you're not doing it with hooks, widgets, etc. Or is that what you meant by using the data attribute? Use that as a marker for "make change here"?
comment
created
paf31
username_1
Pretty much. The case I was thinking of was focussing a text box. We could set a `data-should-focus` attribute, and then use jQuery to focus or blur that element if necessary after rendering.

We could do the same thing with a hook in an attribute, defining

```purescript
focussed :: Boolean -> Attr
focussed = attr "halogen-hook-focussed" <<< makeFocusHook

makeFocusHook :: Boolean -> Hook
makeFocusHook = hook ...
```

I have a sketch of the second approach in the `hooks2` branch.
comment
created
garyb
username_2
Sounds reasonable to me.

That general method is pretty much how I proposed widget initialisation should work in one of the many other discussions - although with the machinery hidden somehow. The idea being then we can delay init until the node exists, has size, etc.
comment
created
paf31
username_1
Sorry, which one?

Implementing widgets with the data-attribute approach seems possible, and even preferable, if we can cram arbitrary data into a data-attribute using `virtual-dom`.
comment
created
garyb
username_2
Well it's something I did in a JS project, so it might not translate directly, but the idea was using a hook that registered a "update me" request on `hook`, and then after render those requests were all processed. The registration part in that case was done with a global array, so that wouldn't quite be the way to handle it, but perhaps a data-attribute could be used to similar effect.

In my case it was for triggering animations on elements rather than doing anything widgety, but it seemed potentially workable?
comment
created
jdegoes
username_3
Note that this is really a symptom of the more general information flow problem I've been ranting about: which is that it's not possible to emit messages from an SF; rather, the SF can only emit stateless, declarative HTML, which is leading to questionable hacks like this (not that I have a good way of solving it, just remarking on why this issue is arising and why information is being forced through pseudo-attributes -- because that's the only way to get event-oriented information out).
comment
created
paf31
username_1
It seems what you're referring to is really a limitation of `virtual-dom`, or even React, or just the general "generate a pure virtual DOM element and patch" approach, unless I'm missing something.

Anyway, I want to nail this down so that I can implement something this weekend. Given everyone's current experience, which do we prefer?

- Support for hook-valued attributes
- Data attributes and support for custom post-render hooks

There's no reason we can't support both of course, but I think it would be good to pick one and stick with it. I prefer the second, since I think it actually subsumes the current widget implementation, and it is closer in spirit to the "push effects to the boundary" approach.
comment
created
jdegoes
username_3
I defer to @username_2, @username_0, and @puffnfresh, as they're the ones who have to use this. :smile:
comment
created
garyb
username_2
Custom post-render hooks seem like they'll be more useful given the requirements of widgets and Bootstrap-style functionality decorators, so my vote goes to the data attribute approach too.

Something to keep in mind is we need to preserve those when manually setting values via `dataSet`.
comment
created
paf31
username_1
I think this is handled by #106, shall I close?
comment
closed
cryogenian
username_0
issue