Re: [elm-discuss] Build iOS apps with Elm

[Duane Johnson]

(Note from list admin: Rudolf, I didn't approve your second message because
it seemed like a duplicate attempt. We've had problems with spam in the
past, so first-time posts require moderator approval. Your future posts
will not need moderation.)

On Wed, Jan 25, 2017 at 4:13 PM, Rudolf Adamkovič 
wrote:

> In case anyone is interested, I set aside 2 days and created a small
> framework that allow to build iOS apps with Elm:
>
> https://github.com/salutis/swift-elm
>
> It can drive both 100% native and web UI. One can also mix and match the
> two.
>
> P.S. It's very early and there're no unit tests yet.
>
>
> --
> 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.
>

-- 
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.

[elm-discuss] Build iOS apps with Elm

[Rudolf Adamkovič]

In case anyone is interested, I set aside 2 days and created a small 
framework that allow to build iOS apps with Elm:

https://github.com/salutis/swift-elm

It can drive both 100% native and web UI. One can also mix and match the 
two.

P.S. It's very early and there're no unit tests yet.


-- 
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.

[elm-discuss] Re: Html.Attributes.none

[Robert Lee]

The following fits in good enough for me.

...

filterDiv : List (Maybe (H.Attribute msg)) -> List (Maybe (H.Html msg)) -> 
H.Html msg
filterDiv a n =
H.div (List.filterMap identity a) (List.filterMap identity n)

...

measurements : Maybe (Int, Int)
...

isNotClicked: Bool
...

let
  styleHeight m = 
 ...

  content =
...
in
  filterDiv
[ Just (class "classy")
, when isNotClicked (onClick Submit)
, Maybe.map styleHeight measurements
]
[ Just content
]
  

On Wednesday, January 25, 2017 at 9:15:01 PM UTC+10, Rupert Smith wrote:
>
> On Tuesday, January 24, 2017 at 10:21:31 PM UTC, Robert Lee wrote:
>>
>> Would anyone else find --Html.Attributes.none-- useful?
>>
>
>
> +1 Yes. 
>
> Also elm-mdl has a 'when' function which is very useful, and a version of 
> it for Html.Attribute would be very handy:
>
> Button.disabled |> when (not model.isRunning)
>
> In a similar way to optional attributes, I find that when building the 
> children of a dom node I end up having to code list manipulations that a 
> 'when' operator could help with:
>
> div [] 
>  [ someInnerDiv,
>someOptionalDiv |> when model.isSelected ]
>
> If there was an Html.none.
>
>

-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Robin Heggelund Hansen]

Uglify essentially removes functions that are not added to objects (how you 
export functions from "namespaces"). Since Elm adds all functions to a 
single local-scope, and then only exports ports and the main function, it's 
very easy for uglify to see what functions are unused, and can therefore 
remove them. Google Closure can do the same thing but, as you said, breaks 
on advanced compilation. Fortunately, advanced optimization doesn't give 
you that much in Elm due to the way it compiles to JS. The difference 
between uglify and google closure (w/advanced opts) was perhaps 3-4kb last 
I checked. Advanced opts breaks because of four lines in Elm's runtime that 
checks for a specific key in certain cases (string tagging). More 
information here: https://github.com/elm-lang/core/pull/734

onsdag 25. januar 2017 16.56.12 UTC+1 skrev OvermindDL1 følgende:
>
> I use browserify for some code via brunch, rollup for others, I run both 
> of those through uglify + closure when building a 'prod' release. 
>  browserify and rollup and both blazing fast in compile time with very 
> large bases of code, but rollup prunes based on functions called (meaning 
> it can break on dynamic name access, but that is rare) and browserify just 
> prunes based on module importing (which can break on dynamic module name 
> access, but that is also rare).  uglify is just a minimizer but it does few 
> optimizations but runs fast, however Google's closure runs *very* slow, but 
> optimizes well, however higher optimization levels will ruin any code that 
> does any kind of dynamic key access that is not dict-like (it breaks elm 
> pretty hard last I tried it, but it works on my bucklescript code 'so far').
>
>
> On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote:
>>
>>
>>
>> On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>>>
>>> Sent too soon.
>>>
>>> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>>>
>>>
>>> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:

 Tree Shaking as implemented by Brunch and Webpack default setups at 
 least only prune based on if a module is accessed or not (which is also 
 why 
 it is easy to fool if you use a non-static string for the name).  I've not 
 seen any tree shaking yet that does otherwise.  Although the fascinating 
 rollup.js does a lot better by pruning functions very effectively, I need 
 to try that one with Elm.  :-)


 On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund 
 Hansen wrote:
>
>
> Actually tree shaking will do absolutely nothing for Elm code as Elm 
>> compiles everything into a single module that all highly indirectly 
>> references itself.  It would help with bucklescript as it outputs 
>> modules, 
>> but bucklescript already tree-shakes as part of its compiler 
>> optimizations 
>> anyway.
>>
>
> This is false. You are correct that Elm compiles everything into a 
> single module, but this means that tree-shaking becomes *easier*, not 
> harder. It also makes name-mangling much easier, as everything is 
> local-scope. With Elm code, tree-shaking can be done with Uglify.js. Just 
> tell uglify to warn you when it removes a function, and you'll see it 
> removes *a lot* of code.
>

>> I see there is the old Google Web Compiler, Browserify, Uglify, Rollup 
>> and I don'e know how many others.  Has anyone compared them all and has any 
>> recommendations on which to use?  If some such as Uglify and Rullup do so 
>> much more than just Tree Shaking, what are the disadvantages in their use, 
>> speed of "compilation"?
>>
>

-- 
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: Emphasizing /r/elm more

[Rex van der Spuy]

On Monday, January 23, 2017 at 9:45:56 PM UTC-5, Richard Feldman wrote:
>
> Worth noting that the top thread on elm-discuss for several weeks 
> 
>  
> has been largely about languages other than Elm, and the Elm-specific parts 
> have primarily consisted of lobbying Evan for reprioritization through a 
> frustrating mix of misinformation and wild speculation. I don't see a way 
> to avoid beginners clicking through and being misinformed by what's being 
> said there, other than responding myself, which further contributes to its 
> being bumped to the top of the list.
>

I totally agree, elm-discuss is a really, really scary place for beginners! 
And, it's impossible for beginners (... or even me sometimes!...) to 
distinguish fact from fiction.

-- 
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.

[elm-discuss] Re: Audio Library?

[Rex van der Spuy]

You could just use an  element for simple playback, but if you want 
anything more sophisticated you'll probably have to use ports to access a 
JS library, like this one:

https://github.com/kittykatattack/sound.js

-- 
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: What do you think about Types/State/View split?

['Rupert Smith' via Elm Discuss]

On Wednesday, January 25, 2017 at 3:25:56 PM UTC, Alex Barry wrote:
>
> we tried to stick to generally Module.View, Module.Update, and 
> Module.Model. We had a few instances where we had to break out sub-update 
> messages (ie the union type typically used in Module.Update) because we had 
> messages that passed messages.
>

Thanks for your thoughts. I presume your Model/Update/View split is very 
similar to the Types/State/View split? or perhaps you put more than the 
Type definitions in your Model.elm?

I'm definitely moving away from this pattern for reasons already stated.
 

> Also for methods, only pass what you need, even if it means passing and 
> returning more data. I eliminated a handful of circular dependencies just 
> by doing that.
>
> Only break things out if there is a reason to.
>

Yeah, I'm not turing things into TEA component unnecessarily. Often I won't 
go as for as making a complete component - more often that not its the view 
that grows in size, and I end up pulling out bits of view code into 
functions, so that is often the first thing to get split out into modules. 

Passing only what is needed is the way to do this :-) Typically I am lazy 
the first time round and just pass the whole Model down the view, then a 
bit of refactoring to make functions only consume what they need.

-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

I use browserify for some code via brunch, rollup for others, I run both of 
those through uglify + closure when building a 'prod' release.  browserify 
and rollup and both blazing fast in compile time with very large bases of 
code, but rollup prunes based on functions called (meaning it can break on 
dynamic name access, but that is rare) and browserify just prunes based on 
module importing (which can break on dynamic module name access, but that 
is also rare).  uglify is just a minimizer but it does few optimizations 
but runs fast, however Google's closure runs *very* slow, but optimizes 
well, however higher optimization levels will ruin any code that does any 
kind of dynamic key access that is not dict-like (it breaks elm pretty hard 
last I tried it, but it works on my bucklescript code 'so far').


On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote:
>
>
>
> On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>>
>> Sent too soon.
>>
>> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>>
>>
>> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>>>
>>> Tree Shaking as implemented by Brunch and Webpack default setups at 
>>> least only prune based on if a module is accessed or not (which is also why 
>>> it is easy to fool if you use a non-static string for the name).  I've not 
>>> seen any tree shaking yet that does otherwise.  Although the fascinating 
>>> rollup.js does a lot better by pruning functions very effectively, I need 
>>> to try that one with Elm.  :-)
>>>
>>>
>>> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund 
>>> Hansen wrote:


 Actually tree shaking will do absolutely nothing for Elm code as Elm 
> compiles everything into a single module that all highly indirectly 
> references itself.  It would help with bucklescript as it outputs 
> modules, 
> but bucklescript already tree-shakes as part of its compiler 
> optimizations 
> anyway.
>

 This is false. You are correct that Elm compiles everything into a 
 single module, but this means that tree-shaking becomes *easier*, not 
 harder. It also makes name-mangling much easier, as everything is 
 local-scope. With Elm code, tree-shaking can be done with Uglify.js. Just 
 tell uglify to warn you when it removes a function, and you'll see it 
 removes *a lot* of code.

>>>
> I see there is the old Google Web Compiler, Browserify, Uglify, Rollup and 
> I don'e know how many others.  Has anyone compared them all and has any 
> recommendations on which to use?  If some such as Uglify and Rullup do so 
> much more than just Tree Shaking, what are the disadvantages in their use, 
> speed of "compilation"?
>

-- 
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] Composing Things in Elm

[Peter Damoc]

On Wed, Jan 25, 2017 at 8:17 AM, Maksim Demin  wrote:

> Thanks for the response, it totally works, and I definitely think it is
> cleaner than having to Html.map everything! I am still trying to fully
> understand what is going on, pretty new to Elm. I kinda get what you are
> doing in the update to map the command,
>
> ( { model | field2 = "2" }, Cmd.map cfg.lift pageTwoCmd )
>
> but how does that happen in the view? How does this cfg.lift which is lift
> : Page1Msg -> msg work here?
>
> div [ onClick (cfg.lift <| DoSomething1) ] [ text model.field2 ]
>

Sorry about that, my bad. It should have been

div [ onClick (cfg.lift DoSomething1) ] [ text model.field2 ]

basically, the view receives a function that knows how to lift the messages
of the SubModule to the message of the parent. If you have type defined as

type Msg
= Msg1 Page1Msg

Msg1 is also a value constructor, in other words, a function that takes a
Page1Msg and outputs a Msg. This is why you can use it as cfg.lift


Now, the reason my code looked like that was because it started as:

 div [ onClick (cfg.lift << DoSomething1) ] [ text model.field2 ]

and when I saw that not working, my mind produced the version with the <|
(my mind is weird sometimes)

You need << (function composition) when the event handler receives a
function.
So, if you have a submodule message like `type Msg = UpdateNameField
String` and in the view you have an input event, it would look like

input [onInput (cfg.lift << UpdateNameField)] []

if cfg.lift is *f* and UpdateNameField is *g*, then (cfg.lift <<
UpdateNameField) is *h* so that h(a) = f(g(a))

I remember being new to Elm and finding function application (*<|* and* |>*
) and function composition ( *<<* and *>>*) mystifying.
After seeing few more examples and reading through these functions
documentation
 my
mind clicked and now I love them.
They can make the code very very readable.




-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[GordonBGood]

On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>
> Sent too soon.
>
> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>
>
> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>>
>> Tree Shaking as implemented by Brunch and Webpack default setups at least 
>> only prune based on if a module is accessed or not (which is also why it is 
>> easy to fool if you use a non-static string for the name).  I've not seen 
>> any tree shaking yet that does otherwise.  Although the fascinating 
>> rollup.js does a lot better by pruning functions very effectively, I need 
>> to try that one with Elm.  :-)
>>
>>
>> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund 
>> Hansen wrote:
>>>
>>>
>>> Actually tree shaking will do absolutely nothing for Elm code as Elm 
 compiles everything into a single module that all highly indirectly 
 references itself.  It would help with bucklescript as it outputs modules, 
 but bucklescript already tree-shakes as part of its compiler optimizations 
 anyway.

>>>
>>> This is false. You are correct that Elm compiles everything into a 
>>> single module, but this means that tree-shaking becomes *easier*, not 
>>> harder. It also makes name-mangling much easier, as everything is 
>>> local-scope. With Elm code, tree-shaking can be done with Uglify.js. Just 
>>> tell uglify to warn you when it removes a function, and you'll see it 
>>> removes *a lot* of code.
>>>
>>
I see there is the old Google Web Compiler, Browserify, Uglify, Rollup and 
I don'e know how many others.  Has anyone compared them all and has any 
recommendations on which to use?  If some such as Uglify and Rullup do so 
much more than just Tree Shaking, what are the disadvantages in their use, 
speed of "compilation"?

-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[GordonBGood]

On Wednesday, 25 January 2017 19:25:40 UTC+7, Bob Zhang wrote:
>
> elm is a reasonably fast language, I think it might run even faster than 
> purescript, enjoy your work!


Yes, Elm is reasonably fast for some programs such as the functional primes 
generator but is inconsistent and not very fast for others; whereas 
BuckleScript is pretty fast for everything and when it isn't, it is fairly 
easy to understand why.

For now, I'd like to try to understand what makes Elm slow in some 
situations and see if there is anything I can do to make it reasonably 
consistently fast in all situations.

For one thing, it looks like Elm's implementation of Lazy in elm-lang/lazy 
is very slow (it resembles Fable's) and thus currently the use of 
LazyList's is very slow.  BuckleScript's lazy is very different under the 
covers and is of expected (fast) speed of about five times faster than Elm. 
 Now this is true for Chrome, but now Edge is the browser running Elm Code 
at about BuckleScript speed.

I need to better understand what makes some types of JS code (in this case 
deferred execution using CIS's or memoized Lazy's) run well optimized on 
some browsers but not on others.

Most people probably don't use Lazy or LazyList in Elm as they are fairly 
new additions to the elm-lang libraries so this isn't likely commonly 
experienced, but using them can produce some very elegant implementations 
for some types of problems.

-- 
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] Composing Things in Elm

[Maksim Demin]

Thanks for the response, it totally works, and I definitely think it is 
cleaner than having to Html.map everything! I am still trying to fully 
understand what is going on, pretty new to Elm. I kinda get what you are 
doing in the update to map the command, 

( { model | field2 = "2" }, Cmd.map cfg.lift pageTwoCmd ) 

but how does that happen in the view? How does this cfg.lift which is lift 
: Page1Msg -> msg work here?

div [ onClick (cfg.lift <| DoSomething1) ] [ text model.field2 ]






On Tuesday, January 24, 2017 at 7:18:29 AM UTC-8, Peter Damoc wrote:
>
> You can use Config objects for both the update and view functions from 
> each page and just lift everything to the top message. 
> I have commented on your gist with how this would look. 
>
> Please note that I have removed the Navigate cmd from your Pages, if you 
> want, you can put it back. 
> I also added a couple of typed Cmds to show how to use the lift in 
> `update` 
>
>  
>
>
>
> On Tue, Jan 24, 2017 at 5:31 AM, Maksim Demin  > wrote:
>
>> Hi,
>>
>> I am trying to figure out the best way to build up pages that have very 
>> little in common, but need to share something, i.e. a nav bar. The pages 
>> don't share messages or models, what would be the best way to implement a 
>> nav across both pages, and perhaps more pages in the future. 
>>
>> I came up with two approaches. 
>>
>> The first is to put the navigation messages at the top Msg and have all 
>> the pages map their Html to return the top level Msg's. I think this is 
>> cool because it avoids replicating the messages across the pages, but you 
>> end up with a bunch of Html.maps to convert everything to the top level Msg 
>> (The docs say "This should not come in handy too often." which got me 
>> thinking of how else to do this) . 
>>
>> The second approach is to have each page implement all the messages for 
>> the nav and in the pages respective update. This seems like a bunch of 
>> duplication as the nav grows and does not seem like a good approach. 
>>
>> Is there a better way to do this kind of thing? 
>>
>> Here is some example code of what I mean 
>> https://gist.github.com/mdemin914/0baf793dce856ffe57ce31979ad600d6. 
>>
>> Any thoughts are appreciated.
>>
>> -- 
>> 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...@googlegroups.com .
>> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

Sent too soon.

Also, uglify is a minimizer, it does a *lot* more than tree shaking.


On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>
> Tree Shaking as implemented by Brunch and Webpack default setups at least 
> only prune based on if a module is accessed or not (which is also why it is 
> easy to fool if you use a non-static string for the name).  I've not seen 
> any tree shaking yet that does otherwise.  Although the fascinating 
> rollup.js does a lot better by pruning functions very effectively, I need 
> to try that one with Elm.  :-)
>
>
> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund Hansen 
> wrote:
>>
>>
>> Actually tree shaking will do absolutely nothing for Elm code as Elm 
>>> compiles everything into a single module that all highly indirectly 
>>> references itself.  It would help with bucklescript as it outputs modules, 
>>> but bucklescript already tree-shakes as part of its compiler optimizations 
>>> anyway.
>>>
>>
>> This is false. You are correct that Elm compiles everything into a single 
>> module, but this means that tree-shaking becomes *easier*, not harder. It 
>> also makes name-mangling much easier, as everything is local-scope. With 
>> Elm code, tree-shaking can be done with Uglify.js. Just tell uglify to warn 
>> you when it removes a function, and you'll see it removes *a lot* of code. 
>>
>

-- 
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: What do you think about Types/State/View split?

[Alex Barry]

Just to pipe in with my experience, I'm working on a medium sized project
with a lot of inter-related data between my modules, which is dictated by a
database structure. We started the project as a single file elm project,
but the code was starting to get unmanageable, so we broke it out into
modules. When that was done, we fixed the elm error reports until it worked
again. That meant that in some cases, we broke out some modules into
multiple files, and we tried to stick to generally Module.View,
Module.Update, and Module.Model. We had a few instances where we had to
break out sub-update messages (ie the union type typically used in
Module.Update) because we had messages that passed messages.

Also for methods, only pass what you need, even if it means passing and
returning more data. I eliminated a handful of circular dependencies just
by doing that.

Only break things out if there is a reason to. If there is a circular
dependency, then either see if there is a way to use anonymous types, or
break out the files. Things like update messages might be okay to use
anonymous types, as long as elm is able to infer the types properly.

On Wed, Jan 25, 2017 at 9:41 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, January 25, 2017 at 12:11:46 PM UTC, Rupert Smith wrote:
>>
>> I think a better approach would be to put build a TEA component like this:
>>
>> module MyComponent exposing (Model, Msg, update, view, init,
>> subscriptions) -- and perhaps also OutMsg
>>
>
> So I think I understand where the tempation to put Model and Msg in
> Types.elm comes from. As the codebase grows I may end up with lots of
> functions for rendering the view, which are of the type Model -> Html Msg.
> Or it may be the update function that grows and I end up with lots of
> helper update functions of type a -> (Model, Cmd.Msg). So these functions
> cannot simply be pushed down to a sub-module as they need to import the
> type, but that is in the main module that is using them - a circular
> dependency.
>
> Just grabbing some random function from view code I was working on today:
>
> slideButton : Model -> Html Msg
> slideButton model =
> div
> [ class "slide-button"
> , Events.onClick ToggleMenu
> ]
> [ div
> (Animation.render model.slideButtonStyle
> ++ [ class "slide-button__inset" ]
> )
> []
> ]
>
> I could push this down into a child module by not passing the whole Model,
> but just the bits it needs, and by passing a 'tagger' for building the
> messages:
>
> slideButton : Animation.State -> msg -> Html msg
> slideButton slideButtonStyle clickTagger =
> div
> [ class "slide-button"
> , Events.onClick clickTagger
> ]
> [ div
> (Animation.render slideButtonStyle
> ++ [ class "slide-button__inset" ]
> )
> []
> ]
>
> Interestingly by removing the Msg and Model type from this piece of view
> logic I have also made it re-usable (with other Models and Msgs, that is,
> other components). So I think if I structure my code this way, as groups of
> related functionality emerge and files get too long, the tidying up
> activity will be to introduce re-usability into code as it it organized.
>
> So some good rules about modules with Types only might be:
>
> * A module that declares Type only cannot take responsibility for
> implementing some functionality, so modules like this should be avoided.
> * A module that declares Type only can introduce too much coupling when it
> is used as a technique to break the circular dependency of modules.
>
>
>
> --
> 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.
>

-- 
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.

[elm-discuss] Re: What do you think about Types/State/View split?

['Rupert Smith' via Elm Discuss]

On Wednesday, January 25, 2017 at 12:11:46 PM UTC, Rupert Smith wrote:
>
> I think a better approach would be to put build a TEA component like this:
>
> module MyComponent exposing (Model, Msg, update, view, init, 
> subscriptions) -- and perhaps also OutMsg
>

So I think I understand where the tempation to put Model and Msg in 
Types.elm comes from. As the codebase grows I may end up with lots of 
functions for rendering the view, which are of the type Model -> Html Msg. 
Or it may be the update function that grows and I end up with lots of 
helper update functions of type a -> (Model, Cmd.Msg). So these functions 
cannot simply be pushed down to a sub-module as they need to import the 
type, but that is in the main module that is using them - a circular 
dependency.

Just grabbing some random function from view code I was working on today:

slideButton : Model -> Html Msg
slideButton model =
div
[ class "slide-button"
, Events.onClick ToggleMenu
]
[ div
(Animation.render model.slideButtonStyle
++ [ class "slide-button__inset" ]
)
[]
]

I could push this down into a child module by not passing the whole Model, 
but just the bits it needs, and by passing a 'tagger' for building the 
messages:

slideButton : Animation.State -> msg -> Html msg
slideButton slideButtonStyle clickTagger =
div
[ class "slide-button"
, Events.onClick clickTagger
]
[ div
(Animation.render slideButtonStyle
++ [ class "slide-button__inset" ]
)
[]
]

Interestingly by removing the Msg and Model type from this piece of view 
logic I have also made it re-usable (with other Models and Msgs, that is, 
other components). So I think if I structure my code this way, as groups of 
related functionality emerge and files get too long, the tidying up 
activity will be to introduce re-usability into code as it it organized.

So some good rules about modules with Types only might be:

* A module that declares Type only cannot take responsibility for 
implementing some functionality, so modules like this should be avoided.
* A module that declares Type only can introduce too much coupling when it 
is used as a technique to break the circular dependency of modules.



-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Bob Zhang]

I am not interested in campaign, it's not fun. But I cannot help replying
when I see some inexact arguments... elm is a reasonably fast language, I
think it might run even faster than purescript, enjoy your work!
On Wed, Jan 25, 2017 at 4:55 AM Robin Heggelund Hansen 
wrote:

>
> Actually tree shaking will do absolutely nothing for Elm code as Elm
> compiles everything into a single module that all highly indirectly
> references itself.  It would help with bucklescript as it outputs modules,
> but bucklescript already tree-shakes as part of its compiler optimizations
> anyway.
>
>
> This is false. You are correct that Elm compiles everything into a single
> module, but this means that tree-shaking becomes *easier*, not harder. It
> also makes name-mangling much easier, as everything is local-scope. With
> Elm code, tree-shaking can be done with Uglify.js. Just tell uglify to warn
> you when it removes a function, and you'll see it removes *a lot* of code.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

[elm-discuss] Re: What do you think about Types/State/View split?

['Rupert Smith' via Elm Discuss]

On Tuesday, January 24, 2017 at 4:32:41 PM UTC, jphedley wrote:
>
> FYI, Kris Jenkins' approach-
> http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html
>

Part of the reason I think this design is wrong, is that when importing a 
component into the top-level Main module to use it, I have imports like 
this:

import MyComponent.Types
import MyComponent.State
import MyComponent.View

Which tells me that I never need just one of these modules, I always need 
them all. So the code is not forming a 'coherent' module very well.

I think a better approach would be to put build a TEA component like this:

module MyComponent exposing (Model, Msg, update, view, init, subscriptions) 
-- and perhaps also OutMsg

Then if the component starts to get too big, instead of splitting it up 
into Types/State/View, just split out parts of it that group well together 
into appropriately named sub-modules. The advantage of this is that to use 
the component only 1 import will be needed, and that will hide the 
implementation sub-modules behind the principal one.

To decide what code to pull out into sub-modules, just look for related 
functionality that makes sense to be combined together. So perhaps I am 
writing some view logic for a menu and it is getting quite big, extract all 
the menu code into its own module. Perhaps I have a group of functions that 
unpack/repack data from a REST service into a model that is suited to what 
I need for the UI, maybe pull those related functions and the model Type 
that they work with into its own module. And so on.

-- 
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.

[elm-discuss] Re: Html.Attributes.none

['Rupert Smith' via Elm Discuss]

On Tuesday, January 24, 2017 at 10:21:31 PM UTC, Robert Lee wrote:
>
> Would anyone else find --Html.Attributes.none-- useful?
>


+1 Yes. 

Also elm-mdl has a 'when' function which is very useful, and a version of 
it for Html.Attribute would be very handy:

Button.disabled |> when (not model.isRunning)

In a similar way to optional attributes, I find that when building the 
children of a dom node I end up having to code list manipulations that a 
'when' operator could help with:

div [] 
 [ someInnerDiv,
   someOptionalDiv |> when model.isSelected ]

If there was an Html.none.

-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Robin Heggelund Hansen]

> Actually tree shaking will do absolutely nothing for Elm code as Elm 
> compiles everything into a single module that all highly indirectly 
> references itself.  It would help with bucklescript as it outputs modules, 
> but bucklescript already tree-shakes as part of its compiler optimizations 
> anyway.
>

This is false. You are correct that Elm compiles everything into a single 
module, but this means that tree-shaking becomes *easier*, not harder. It 
also makes name-mangling much easier, as everything is local-scope. With 
Elm code, tree-shaking can be done with Uglify.js. Just tell uglify to warn 
you when it removes a function, and you'll see it removes *a lot* of code. 

-- 
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.