Re: [elm-discuss] Re: Elm UI boilerplate

[Kasey Speakman]

I had the same thought... Elm's HTML components stand out as examples of 
self-contained components. But when I checked their implementations, they 
all turned out to be native. Their effects/state are managed by native code 

.

This unfortunately means that the way they work has no corollary in pure 
Elm. Maybe it's possible to build your own components by calling the same 
native functions. I haven't seen any guidance suggesting this approach. I 
would imagine a lot of the safety features are bypassed this way. I think 
even then, all the component's Elm messages would get send to the top of 
the program, not the component itself, the same way Elm messages work for 
standard HTML components.

The view function is pure in that: given the same inputs, the same output 
is generated. But the program on the whole is not pure. (Pure programs are 
generally useless since they can't interact with the outside.) The 
framework steps in to handle turning the rendered HTML into effect-ful 
elements (attaching event handlers, delivering messages, etc).

I, too, wonder if there is a way to bridge the Elm world to native in a 
safe way for building components, but I would be wary of losing the 
benefits of determinism. Currently Elm forces you to write your application 
bits as pure functions so that your code holds no accidental complexity. 
Then it handles the effectful complexity for you, or at least forces it to 
take place "outside" in JS where you're used to it.

On Thursday, August 18, 2016 at 4:47:53 AM UTC-5, Peter Damoc wrote:
>
> 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  > 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 

Re: [elm-discuss] Re: Elm UI boilerplate

[Kasey Speakman]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm UI boilerplate

[Oliver Searle-Barnes]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm UI boilerplate

[OvermindDL1]

On Wednesday, August 17, 2016 at 9:07:35 AM UTC-6, Peter Damoc wrote:
>
> The elm-parts Msg is defined as: 
>
> type Msg c = 
>   Msg (c -> (Maybe c, Cmd (Msg c)))
>
> This is why I consider the "without parts" the pure TEA. 
>

True, I can see that yeah, unsure of a better way off hand either...


 On Wednesday, August 17, 2016 at 9:07:35 AM UTC-6, Peter Damoc wrote:

> This is another reason to have this discussion. 
> Søren did the best he could with the technology he had at his disposal. 
> He has created something that removes some of the pain but introduces 
> other issues like the manual identity management that can lead to issues 
> like the one you describe. 
>
> There has to be a better solution. 
>

I keep trying different styles of things, but I can never seem to come up 
with one that works very well while allowing arbitrary expansion of view 
elements without huge amounts of highly duplicated but not-quite code that 
cannot be reduced due to lack of functionality in Elm as of yet.  Really do 
need 'some' method though...

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm UI boilerplate

[Peter Damoc]

On Wed, Aug 17, 2016 at 5:40 PM, OvermindDL1  wrote:

> I do not consider elm-parts to not be pure TEA, I just consider it to make
> view/state combinations that are ID'd for separation, but I still consider
> it pure TEA.
>


Evan said in the sortable table Readme
:

> One of the core rules of The Elm Architecture is never put functions in
> your Model or Msg types.


The elm-parts Msg is defined as:

type Msg c =
  Msg (c -> (Maybe c, Cmd (Msg c)))

This is why I consider the "without parts" the pure TEA.



> However, there is one niggle of irritant of elm-mdl/elm-parts that I am
> not sure can be worked around, and that is its 'ID', the fact you have to
> manually manage the number means that you can add in duplicates
> accidentally (such as duplicating a line to add something).  However we
> need the ID's to keep things not only distinct but to refer back to them as
> well.  What we need is some way to ensure there are no duplicates on
> generation and if so log a warning or something (there are also cases where
> duplicates are needed).  Currently this is not possible without having a
> parent view that walks the entire virtual node try via a to/from json hack
> or so again, which is painful and not done for possible breakage reasons in
> the future.
>

This is another reason to have this discussion.
Søren did the best he could with the technology he had at his disposal.
He has created something that removes some of the pain but introduces other
issues like the manual identity management that can lead to issues like the
one you describe.

There has to be a better solution.




-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.