3 ms·

Model change listeners are the anti-pattern, not events. Mouse and key events are essential complexity. -- MVVM: model change listeners on each state mutation

Model change listeners are the anti-pattern, not events. Mouse and key events are essential complexity. -- MVVM: model change listeners on each state mutation: response to state mutation is immediate, never batch multiple listeners, requires dependency tracking (if the collection changed, then the count also changed). change listeners fire immediately and can trigger more change listeners. Lots of callbacks to keep track of and easy for things to get out of whack. (Backbone, Knockout, Knockback) Angular ("MV-whatever"): state changes detected by dirty checking, but changes are immediate (digest loop), never needs dependency tracking. Digest loop runs until the state settles (no more change listeners fire) to ensure consistent views. Magic data binding. Facebook React: state w/ dirty checking: state changes are always batched, views are a pure function, reconciliation step to merge desired view with existing view, no events or change listeners. Render process is a lot like a 3D game - draw the buffer, whack the buffer, loop. No magic. Facebook doesn't call it MVC but in my eyes it is. -- The more complex your view and state, the more events/mutations/callbacks, the more you need React.

jcampbell1 13y ago
You seem to know what you are talking about, but I just don't understand what you are saying. Can you explain the React thing a bit better? > Mouse and key events are essential complexity. I disagree, but probably not with what you mean here. Mouse and Key events are the first thing I want to abstract away, and are an example of the pitfalls of events. The majority of internet connected devices have neither a mouse nor keyboard. I don't want to care about key events or mouse movements, but rather user intent. "submit" and "change" describe user intent; I don't give a shit about clicks and keydowns, or blitting glyphs into an input box or moving the cursor on command-a. What does keydown mean when a Chinese person is swiping chinese characters? I think of events as chemotherapy. It is one hell of a powerful tool, but should be avoided for most problems. If every problem looks like cancer, then your worldview is missing simpler and less powerful but better tools.
- wmeddie 13y ago
  For anyone wondering how Chinese/Japanese/Korean input works interms of DOM events check out the W3C's working draft of the IME API [http://www.w3.org/TR/2013/WD-ime-api-20130815/ http://www.w3.org/TR/2013/WD-ime-api-20130815/]. Specifically the sequence diagram near the end of the page.
  - janjongboom 13y ago
    Technically speaking it's the Google proposal, Mozilla is working on a counter proposal at https://wiki.mozilla.org/WebAPI/KeboardIME https://wiki.mozilla.org/WebAPI/KeboardIME.
- underwater 13y ago
  React probably closer to being just the View than MVC or any other paradigm. It doesn't even have any model layer. Components in React take a set of properties and implement a render function that transforms those properties into a view (usually by rendering other high-level React components rather outputting plain old HTML). Instead of manually maintaining view state you just render from scratch each time; hence the description of pure functions in parent comment. Usually this would be a terrible idea because it would kill browser performance and lead to extra complexity in registering/unregistering event handlers, etc. but React implements a framework that ensures the minimum number of DOM interactions happen.
- icambron 13y ago
  I think the idea is that instead of having a bunch of DOM elements waiting around for individual events that tell them to change state ("your text should now be this"), you get a whole rendered view ("here's what the DOM looks like now"), which is then merged with the current one. That cuts out of a lot of the weird interconnected events that fly around everywhere in MVVM, because the DOM is mostly just an output. That's the DOM mutation side of it, anyway. I'm don't think I understand how the dirty check/batched event thing works for information going the other direction (user changed the value of a dropdown), and I'll abstain from guessing. Personally, I don't mind events so much, so react's probably not the framework for me.
616c 13y ago
I get the feeling someone has been listening to the Elm language talk? http://elm-lang.org/ http://elm-lang.org/
acjohnson55 13y ago
What's wrong with model change listeners?

jcampbell1 13y ago

You seem to know what you are talking about, but I just don't understand what you are saying. Can you explain the React thing a bit better? > Mouse and key events are essential complexity. I disagree, but probably not with what you mean here. Mouse and Key events are the first thing I want to abstract away, and are an example of the pitfalls of events. The majority of internet connected devices have neither a mouse nor keyboard. I don't want to care about key events or mouse movements, but rather user intent. "submit" and "change" describe user intent; I don't give a shit about clicks and keydowns, or blitting glyphs into an input box or moving the cursor on command-a. What does keydown mean when a Chinese person is swiping chinese characters? I think of events as chemotherapy. It is one hell of a powerful tool, but should be avoided for most problems. If every problem looks like cancer, then your worldview is missing simpler and less powerful but better tools.

wmeddie 13y ago
For anyone wondering how Chinese/Japanese/Korean input works interms of DOM events check out the W3C's working draft of the IME API [http://www.w3.org/TR/2013/WD-ime-api-20130815/ http://www.w3.org/TR/2013/WD-ime-api-20130815/]. Specifically the sequence diagram near the end of the page.
- janjongboom 13y ago
  Technically speaking it's the Google proposal, Mozilla is working on a counter proposal at https://wiki.mozilla.org/WebAPI/KeboardIME https://wiki.mozilla.org/WebAPI/KeboardIME.
underwater 13y ago
React probably closer to being just the View than MVC or any other paradigm. It doesn't even have any model layer. Components in React take a set of properties and implement a render function that transforms those properties into a view (usually by rendering other high-level React components rather outputting plain old HTML). Instead of manually maintaining view state you just render from scratch each time; hence the description of pure functions in parent comment. Usually this would be a terrible idea because it would kill browser performance and lead to extra complexity in registering/unregistering event handlers, etc. but React implements a framework that ensures the minimum number of DOM interactions happen.
icambron 13y ago
I think the idea is that instead of having a bunch of DOM elements waiting around for individual events that tell them to change state ("your text should now be this"), you get a whole rendered view ("here's what the DOM looks like now"), which is then merged with the current one. That cuts out of a lot of the weird interconnected events that fly around everywhere in MVVM, because the DOM is mostly just an output. That's the DOM mutation side of it, anyway. I'm don't think I understand how the dirty check/batched event thing works for information going the other direction (user changed the value of a dropdown), and I'll abstain from guessing. Personally, I don't mind events so much, so react's probably not the framework for me.

616c 13y ago

I get the feeling someone has been listening to the Elm language talk? http://elm-lang.org/ http://elm-lang.org/

acjohnson55 13y ago

What's wrong with model change listeners?