Pauan

@fitzgen To be clear, a "controlled component" means the `value` of the `` is *always* synchronized between the app and the DOM. In order to actually accomplish that, it must...

> Unfortunately, such disadvantage appear big to me. I thought so too at first, but in practice it's not a problem. For better or worse, Rust is not a pure...

@chinedufn If your framework allows for closures with event listeners, then you can always completely bypass the framework's state mechanism and create your own: ```rust fn render() { let my_state...

Also, you might dismiss my above argument by saying, "well, that's outside the framework, so it doesn't count". But because of interior mutability, it's possible to have mutation *even with...

> @Aloso I think dodrio handles it pretty well That's not really any different from dominator though, since you can still mutate the state inside of the event listener. So...

I'm not really sure how to handle `FnOnce`. It's easy enough to just provide a `once` function, but... there are some events (like `load`, `DOMContentLoaded`, etc.) which *only* make sense...

Yes, I mean that `load` event. I'm sure there's many more `FnOnce` events (I just can't remember them off the top of my head). > I wonder if at this...

@yoshuawuyts Sure, and that's handled by https://github.com/rustwasm/gloo/issues/10. Are you suggesting that all uses of `FnOnce` event listeners should get specialized ad-hoc APIs like that, rather than a generic mechanism for...

@OddCoincidence asked whether we need the `

> I suspect that for mid-level APIs it's acceptable if we fail to completely constrain all interfaces, because we get a chance to do that at the high-level APIs (if...