[rtfeldman]

That's not at all disingenuous; the two are completely unrelated. :)

The DOM uses local state extensively, and sometimes you need to interact directly with its API. When you do, you can either do more work to translate it into your preferred architecture, or not.

In this case I didn't think the extra work required to wrap the DOM API for cursor position would be worth the trouble.

That's certainly not an endorsement of the DOM's architecture. ;)

[ablesearcher]

> "The DOM uses local state extensively, and sometimes you need to interact directly with its API. When you do, you can either do more work to translate it into your preferred architecture, or not."

> "Local component state is the new two-way data binding. . . If you listen to people who have spent a lot of time with both systems, what you hear are a lot of single state atom converts and not a lot of people saying "yeah it wasn't awesome so I went back to local component state."

> "I wouldn't maintain cursor state in the model . . . Whenever you want to change its value, just send the desired new value to that port and let the JS snippet do the "stash cursor position, set the new value, restore cursor position" bit."

The question we were addressing is where your state should live. @boubiyeah questioned the wisdom of storing all component state (e.g., the current position of a cursor) in a global atom. You responded that "[l]ocal component state is new two-way data binding." Yet yesterday you advised that component local state should live outside of the global atom.

Maybe it wasn't disingenous, as perhaps you've simply changed your mind. But then you should make clear that your opinion today is different from what you advised yesterday, as it bears on the credibility of your current advice.

[rtfeldman]

Hm...my response was the exact opposite of that. Maybe I need to rephrase?

In bullet points:

1. Yesterday someone presented a case where they needed to interact with a DOM API that used local state.

2. I didn't think it would be worth the trouble to wrap that API.

3. That is not an endorsement of local component state.

Hopefully that clears things up. :)

[rlander]

Don't feed the troll. While @ablesearcher's obviously part of the Elm community, he's using a throwaway account to vomit angry rubish on HN.

[ablesearcher]

When did evidence-backed criticism become synonymous with trolling? Also, which statement exactly was angry? (Let alone rubbish? Or, gasp, vomit?)

It seems you want all Elm news to be positive Elm news. So does the language's author. In fact, when addressing the announcement re: Hacker news, he wrote this:

"Just an FYI, if you go to a HN post via direct link and vote on it, those votes either do not count or are used as demerits because it indicates that people are trying to artificially boost things. I guess getting a kickstarter to the top of HN can be worth a lot of money, so they try to protect against voting rings."

(See https://groups.google.com/forum/#!topic/elm-dev/NQxML4HA4X8 )

Civility is important. But so is the honest, unfettered exchange of ideas.

[rlander]

Well, for starters, use your real name, like the rest of us, not a throwaway account.

I guess if your issues were legitimate, we'd see a post on the mailing list, not an open attack on Richard's credibility.

For the record, this is evidence-backed criticism:

https://news.ycombinator.com/item?id=10081955

Yours is just trolling.

[ablesearcher]

Let's proceed in reverse order:

1. You don't get to define evidence-backed criticism to be only the criticism that you appreciate.

2. I didn't "attack" Richard. I pointed out an inconsistency with other recent statements that he has made, that bear on the credibility of his current advice.

3. I'm not sure how my identity is relevant to my ideas. But the reason I don't post under my own name has to do with requirements of my job. (I'm not a programmer by trade.) I can't have social media accounts. In any event, this isn't a throwaway account. These are, in fact, my first posts to HN.

[tomp]

Not everyone disagreeing is a troll.

[nwienert]

So basically you think it's ok to use local state, but only for DOM related stuff?

[rtfeldman]

Nope, just that the effort required to wrap something in a nicer architecture sometimes outweighs the benefits you'd get from the upgrade. This was one of those cases.