61–70 of 92 posts
Earlier quoted context omitted.
A GUI with n buttons and a button to add and remove additional buttons
Like this: http://evancz.github.io/elm-architecture-tutorial/examples/7... ?
I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…
You can have component local state in the Elm architecture. If you work through the Elm architecture tutorial ( https://github.com/evancz/elm-architecture-tutorial/ ), section 6 describes how to do it. You can also have both local and global state if you want. Just follow the tutorial and in your "model" type add a record called "global". Than let each component take and return both the local and the global model. I…
Earlier quoted context omitted.
Local component state is the new two-way data binding. Three years ago, two-way data binding was the gold standard for niceness. Then React came out, and there was buzz around unidirectional data flow, and a lot of (understandable!) skepticism came with it. If you listen to people who have spent a lot of time with two-way data binding and unidirectional data flow, what you hear are a lot of unidirectional data flow c…
@rtfeldman -- I think your response is a bit disingenuous since only yesterday you wrote, in response to a question about cursor state, this: "I wouldn't maintain cursor state in the model; I'd just implement the port like this: http://stackoverflow.com/a/14508837/2334666 In other words, you never use the value attribute on the input; rather, you give it a unique key and don't touch it directly. Whenever you want to…
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. ;)
Earlier quoted context omitted.
Local component state is the new two-way data binding. Three years ago, two-way data binding was the gold standard for niceness. Then React came out, and there was buzz around unidirectional data flow, and a lot of (understandable!) skepticism came with it. If you listen to people who have spent a lot of time with two-way data binding and unidirectional data flow, what you hear are a lot of unidirectional data flow c…
Actually, you do see a lot of questions and problems with the single state atom. In fact, I'd argue it's inherently a side step towards a future that has the best of both worlds: encapsulated state within components, but backed by some global state store invisibly. This is exactly what Relay is by the way. You component asks for state, and gets it from a server. The fact that it comes through props is actually just a…
Earlier quoted context omitted.
Maybe the answer is for elm-html to put a cursor-state attribute on textual input elements, and have event handlers for selection change? Then you can have the cursor state in your atom if you need it without ports....
That might solve the cursor issue, but it's a bigger issue than cursor state. The real issue is that Elm doesn't treat its programmers like grown-ups. That sounds harsh, so let me explain . . . I've drank enough of the Haskell Kool-Aid to realize that, despite the surface discourse, Haskell is not about religious devotion to purity and lazy-evaluation. It's about managing side-effects, and being honest about them in…
The <~ for Signal.map is a good example for a "clever" thing which makes languages hard to read for newbies. It looks like it's part of the syntax and not a function. It's not hard to understand, but it's another thing to learn. I am very happy that things are removed from Elm (or not added in the first place, like type classes) because design is not finished when there is nothing more to add but when there is nothing more to remove.
Earlier quoted context omitted.
Like this: http://evancz.github.io/elm-architecture-tutorial/examples/7... ?
Yes ... but with a more natural implemention. That style won't scale up to real dynamic programs though without significant routing infrastructure outside of Elm's typical constructs.
I'd suggest giving it a try. It's really nice. :)
Earlier quoted context omitted.
You can have component local state in the Elm architecture. If you work through the Elm architecture tutorial ( https://github.com/evancz/elm-architecture-tutorial/ ), section 6 describes how to do it. You can also have both local and global state if you want. Just follow the tutorial and in your "model" type add a record called "global". Than let each component take and return both the local and the global model. I…
Your solution redefines the word "local" to mean "global." Yes, you can store a component's intrinsically local state as field in your global model and then use a specialized update function that is reached by a switch from your global update function. The question we are addressing is: Is that a good idea?
Earlier quoted context omitted.
@rtfeldman -- I think your response is a bit disingenuous since only yesterday you wrote, in response to a question about cursor state, this: "I wouldn't maintain cursor state in the model; I'd just implement the port like this: http://stackoverflow.com/a/14508837/2334666 In other words, you never use the value attribute on the input; rather, you give it a unique key and don't touch it directly. Whenever you want to…
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…
> "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.
Earlier quoted context omitted.
Like this: http://evancz.github.io/elm-architecture-tutorial/examples/7... ?
Yes ... but with a more natural implemention. That style won't scale up to real dynamic programs though without significant routing infrastructure outside of Elm's typical constructs.
What I really would like to see is a counter example. Some GUI that just can not be done in Elm.
I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…