Hi Kasey,
Take this code as example:
import Html exposing (..)
import Html.App as App
import Html.Events exposing (..)
main =
App.beginnerProgram
{ model = 0
, view = view
, update = \msg model -> model
}
type Msg = NoOp String
view : Int -> Html Msg
view model =
div []
[ input [onInput NoOp ][]
]
if you type in the input of this short program you will see characters.
Those characters are not part of the model.
Every time you press something, the view is called again with the exact
same argument and what you see on the screen is different.
In order for this input component to work, there has to be state. State
that holds the characters typed, state that holds the cursor position, even
state that animates that cursor.
So, if elm views are pure, what does this make `Html msg`?
The easiest answer I could come up with is that `Html msg` behaves like the
record you give to a `Html.App.program`
Given this record, the runtime could create some state if it hasn't already
done this and use the provided functions to update it / represent it.
Of course, elm-html is not implemented like this but, from a type
conceptualization point of view, this is the easiest way that I could find
to explain the *behavior* or elm-html and still maintain the idea that the
view is pure.
And this brings us back to the issue of boilerplate. If elm-html can do
this automatic state and avoid the boilerplate, how can alternatives to
elm-html do the same thing?
Another way to think about it is, how would a pure Elm ui be implemented if
there would not be the support of state management that the dom does?
(Imagine a cross platform UI implemented in Elm on top of something like a
canvas )
On Thu, Aug 18, 2016 at 11:32 AM, Kasey Speakman <[email protected]>
wrote:
> I've hesitated to mention this since I'm a newcomer to Elm, but I'll throw
> it out there and see what you think.
>
> The way Elm currently renders subcomponents is because the view is a pure
> function, so all subparts must be pure functions. That's what makes
> stateful subcomponents irritating to work with... the boilerplate of
> accounting for them in the parent.
>
> As a thought experiment, what if Elm were to bring in support for UI
> components that were independent of Main? They get wired to received
> init/update/view independently of the parent. They get avenues to send
> messages to the parent and vice versa. They get some state from the parent
> on init. Etc. That path has already been well-traveled by most every other
> front-end so we can know the answer. Doing that is basically bringing in
> object orientation and all the accidental complexity that comes with it.
> Right now Elm steers us away from those problems by forcing our code to be
> deterministic, but with the trade-off of the parent being responsible for
> everything underneath (requiring the boilerplate).
>
> That's not an answer to the issue at hand. It's just an observation that
> Elm does provide a (perhaps non-obvious) benefit with the current way it
> does things. It still definitely has pain, but it's clear-cut as opposed to
> accidental and pervasive. So I think that's why we hear the advice from the
> more seasoned folks to start from a place of having the parent manage
> everything with the child being stateless. Only once it becomes impractical
> for the parent to maintain the child's state, then take the lumps to make
> it stateful. The message is: yes, there's pain... just avoid it until you
> can't.
>
> Now don't get me wrong, I want the ability to use UI toolkits without
> impacting "my" code. And I want to eradicate boilerplate. We just need to
> be mindful of the trade-offs in how that's accomplished. Myself, I'm still
> thinking on it.
>
>
> On Thursday, August 18, 2016 at 1:41:57 AM UTC-5, Oliver Searle-Barnes
> wrote:
>>
>> In my experience every large SPA I've worked on has ended up building a
>> set of it's own components similar to elm-mdl. They've usually been used
>> alongside other components that have been provided by libraries such as
>> elm-mdl but they're still a significant part of the codebase. From this
>> perspective, and judging by the questions I've seen in slack, this is
>> something that pretty much every Elm developer is going to need to resolve.
>>
>> It would also be great to have a healthy selection of UX components
>> available at http://package.elm-lang.org/. To get a concrete idea of
>> some of the sorts of components this might be take a look at
>> https://emberobserver.com/categories/components.
>>
>> Making it easy to author, share and consume UX components will only make
>> building Elm apps even more pleasurable :) I'd caution against treating it
>> as a special case for advanced use or the select few.
>>
>>
>> On Thursday, 18 August 2016 08:25:29 UTC+2, Peter Damoc wrote:
>>>
>>> A small clarification that came up in an earlier discussion.
>>>
>>> This is a boilerplate example for the case where you have many small
>>> components that are unavoidably stateful as it is the case with UI
>>> toolkits.
>>>
>>> This is a topic that concerns very few people from an implementation
>>> point of view but stands to concern a lot of people from usage point of
>>> view.
>>>
>>> Most of the components needs are covered by current technologies.
>>>
>>> One more thing that might be worth mentioning:
>>> Adding a new field involves changing the code in 3 places for the
>>> with-parts version and it 5 places for the without-parts code.
>>>
>>>
>>> P.S. Many thanks to Josh for cleaning up the code of without-parts
>>> example.
>>>
>>> --
>>> There is NO FATE, we are the creators.
>>> blog: http://damoc.ro/
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
