Re: [elm-discuss] Two suggestions for improvements (Regex and Navigation)

[Peter Damoc]

The reason I asked for the URL examples is because I wanted to understand
the nature of the dynamic part.

I was curious if maybe the kind of need that you have from the parser
couldn't be solved without flags.

Why couldn't you just trim the url in the parser function?





On Tue, Sep 13, 2016 at 9:33 PM, OvermindDL1  wrote:

> In my case it is because I have a single app that can be instanced into
> multiple pages (or twice in a single page) and need to prune the url of a
> part that needs to be ignored and need to completely ignore the url
> entirely (pure internal navigation for this state).  The url's can be
> dynamic so knowing ahead of time is not always possible, but I've worked
> around it well enough for the moment by hot-swapping some code in the
> javascript.  It is messy but eh, it works...
>
>
> On Tuesday, September 13, 2016 at 11:43:26 AM UTC-6, Peter Damoc wrote:
>>
>> Out of curiosity, what functionality are you actually trying to achieve?
>>
>> I'm trying to understand the need behind wanting to be dynamic in
>> ignoring a certain part of the url.
>>
>> Can you give some URL examples that show what you want to achieve?
>>
>>
>>
>> On Tue, Sep 13, 2016 at 8:12 PM, OvermindDL1  wrote:
>>
>>> Does not work in my case of needing to specify a part of the url to
>>> ignore and to only change the remaining part.  Right now I just have this
>>> in my code to 'work around it for now':
>>> ```
>>> module SomeApp.Hacks exposing (..)
>>>
>>> {-| https://github.com/elm-lang/navigation/issues/9
>>> -}
>>>
>>> navigationHack : String
>>> navigationHack =
>>> "/some"
>>> ```
>>>
>>> On Tuesday, September 13, 2016 at 10:15:37 AM UTC-6, Peter Damoc wrote:



 On Tue, Sep 13, 2016 at 6:55 PM,  wrote:

>
> 2. Giving the Url-Parser (of the Navigation package) access to the
> program flags.
>
> This was a little show stopper for me. I wanted to write a single page
> app that does not have to be recompiled if you switch the language.
> Different language files are built in, and there is a flag to choose the
> language. The problem is, that the paths in the url (after the hash) 
> should
> also be in the chosen language. The url parser does not have access to the
> model (and I don't see how it could), but it could at least get access to
> the flags. I think that could be accomlished easily in
> Navigation.programWithFlags.
>

 Wouldn't be easier to just prefix all the urls with the language

 domain.com/#/en/some/path
 domain.com/#/fr/vive/la/france

 This way you could look at the hash/location, figure the language, and
 then chose the appropriate parser for that language.
 (this is what I did in my app)




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



-- 
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] Two suggestions for improvements (Regex and Navigation)

[d . vandeneijkel]

Ok, the solution would look like this; but not sure if it's ok to create a 
new parser every time the addressbar changes...

https://github.com/aische/navigation/blob/master/src/Navigation.elm (new 
function: programWithFlags' )

https://github.com/aische/navigation/blob/master/examples/Counter.elm


-- 
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] Two suggestions for improvements (Regex and Navigation)

[OvermindDL1]

In my case it is because I have a single app that can be instanced into 
multiple pages (or twice in a single page) and need to prune the url of a 
part that needs to be ignored and need to completely ignore the url 
entirely (pure internal navigation for this state).  The url's can be 
dynamic so knowing ahead of time is not always possible, but I've worked 
around it well enough for the moment by hot-swapping some code in the 
javascript.  It is messy but eh, it works...


On Tuesday, September 13, 2016 at 11:43:26 AM UTC-6, Peter Damoc wrote:
>
> Out of curiosity, what functionality are you actually trying to achieve? 
>
> I'm trying to understand the need behind wanting to be dynamic in ignoring 
> a certain part of the url. 
>
> Can you give some URL examples that show what you want to achieve? 
>
>
>
> On Tue, Sep 13, 2016 at 8:12 PM, OvermindDL1  > wrote:
>
>> Does not work in my case of needing to specify a part of the url to 
>> ignore and to only change the remaining part.  Right now I just have this 
>> in my code to 'work around it for now':
>> ```
>> module SomeApp.Hacks exposing (..)
>>
>> {-| https://github.com/elm-lang/navigation/issues/9
>> -}
>>
>> navigationHack : String
>> navigationHack =
>> "/some"
>> ```
>>
>> On Tuesday, September 13, 2016 at 10:15:37 AM UTC-6, Peter Damoc wrote:
>>>
>>>
>>>
>>> On Tue, Sep 13, 2016 at 6:55 PM,  wrote:
>>>

 2. Giving the Url-Parser (of the Navigation package) access to the 
 program flags.

 This was a little show stopper for me. I wanted to write a single page 
 app that does not have to be recompiled if you switch the language. 
 Different language files are built in, and there is a flag to choose the 
 language. The problem is, that the paths in the url (after the hash) 
 should 
 also be in the chosen language. The url parser does not have access to the 
 model (and I don't see how it could), but it could at least get access to 
 the flags. I think that could be accomlished easily in 
 Navigation.programWithFlags.

>>>
>>> Wouldn't be easier to just prefix all the urls with the language 
>>>
>>> domain.com/#/en/some/path
>>> domain.com/#/fr/vive/la/france
>>>
>>> This way you could look at the hash/location, figure the language, and 
>>> then chose the appropriate parser for that language. 
>>> (this is what I did in my app) 
>>>
>>>
>>>
>>>
>>> -- 
>>> 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...@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: Request: loosen syntactic constraints on base-record in record extend/update syntax

[Nick H]

Another solution might be to define some setters, so that you could write
something like:

[
  defaultCustomer 1 |> setName "Smith" |> setOccupation |> "Clerk",
  defaultCustomer 2 |> setName "Jones",
  defaultCustomer 3 |> setNickname "R2-D2" |> setHeight 0.5
]


Unfortunately, defining all those setters is verbose. But I often find them
much nicer to work with than Elm's record-updating syntax.

I am willing to jump through a lot of hoops in order to use pipe operators
:-)


On Tue, Sep 13, 2016 at 10:49 AM, Nick H  wrote:

> OK, this is a more complex issue than what I had in mind. If you have a
> small number of desired initializations (maybe 2 or 3 cases besides
> defaultCustomer), I think it would make sense to have multiple construction
> functions. But of course that won't scale at all.
>
>
> On Tue, Sep 13, 2016 at 7:03 AM, Martin Cerny  wrote:
>
>> Hi,
>> thanks for the suggestion, but I think you are answering to a different
>> problem than the one I had in mind, I'll try to be more clear to avoid
>> confusion.
>> In my use case, I have a lot of fields, which usually can be kept with
>> their default values, but some of them aren't. So not all customers need
>> names. Maybe a better example of the code I want to write would be:
>>
>> type alias Customer =
>>   { id : Int,
>> name : String ,
>> occupation : String,
>> nickname : String,
>> height : Float,
>> -- Lots of other stuff
>>   }
>>
>>
>> defaultCustomer : Int -> Customer
>> defaultCustomer id =
>>   { id = id,
>>name = "",
>>occupation = "",
>>nickname "N/A",
>>height : 1.6,
>> -- lots of other initialization
>>   }
>>
>> [
>>   { (defaultCustomer 1) | name = "Smith", occupation = "Clerk" },
>>   { (defaultCustomer 2) | name = "Jones" }
>>   { (defaultCustomer 3) | nickname = "R2-D2", height = 0.5 }
>> ]
>>
>>
>>
>> Martin
>>
>>
>>
>>
>> On Monday, 12 September 2016 17:50:21 UTC+2, Nick H wrote:
>>>
>>> In this case, I think the best thing to do would be to make a
>>> construction function that takes a name as well as an id.
>>>
>>> defaultCustomer : Int -> String -> Customer
>>> defaultCustomer id name =
>>>   { id = id,
>>>   , name = name,
>>>-- lots of other initialization
>>>   }
>>>
>>> You constructor function should never return an incomplete/invalid
>>> record. If your customers always need names, make sure they always get
>>> names!
>>>
>>>
>>>
>>> On Sun, Sep 11, 2016 at 4:44 AM, Martin Cerny  wrote:
>>>
 Hi,
 hope its polite to bump up an old thread like this - if not, please
 accept my apologies. I have been struggling with the record update syntax
 for a while and wanted to share another use case which I think could be
 made better.
 So let's say I want to populate a list of objects of the same type
 which have a lot of properties, most of which are kept default, e.g.

 type alias Customer =
   { id : Int,
 Name : String ,
 -- Lots of other stuff
   }

 and I have a "constructor" function to build instances with default
 values, but never forget to fill in the id, e.g.

 defaultCustomer : Int -> Customer
 defaultCustomer id =
   { id = id,
Name = "",
-- lots of other initialization
   }

 now I would like to write things like
 [
   { (defaultCustomer 1) | Name = "Smith" },
   { (defaultCustomer 2) | Name = "Jones" }
 ]

 Which is not possible.

 Now I have two options:
 a) do not use a "constructor" and always write the records in full (not
 nice since they have a lot of fields which are mostly left default)
 b) just have a template defaultCostumer : Customer and hope I will
 never forget to fill in the id (used in messages)
 c) have a long "let" clause before defining the list

 Neither of which seems nice.

 I'll probably go with b), but if anyone has a nice suggestion how to
 enforce filling in a record in this way with the current syntax it would be
 very welcome.

 And thanks for the work on elm - I am learning it and having fun with
 it!

 Martin





  but I tried to figure out where on GitHub should this be discussed and
 kind of failed...
 (is it https://github.com/elm-lang/elm-plans/issues/16 or

 On Saturday, 26 July 2014 18:08:22 UTC+2, Jeff Smits wrote:
>
> Yeah, I really want this feature. But I guess I forgot about the "code
> comparison".
>
> @Evan: can you say more concretely what kind of code comparison you
> want to see before moving forward on this feature?
>
> On Sat, Jul 26, 2014 at 2:26 PM, David Sargeant 
> wrote:
>
>> Seems a little strange that the following does not work:
>>
>> { {} | attrs = [1] }
>>
>> I know it's not really useful, but I guess it goes back to 

Re: [elm-discuss] Proposal for a 1st-class, officially-supported CSS package

[Noah Hall]

elm-css doesn't need extra first class Elm support. It has first class
Elm support - everything is a function. As Nick said, focus on how you
_use_ elm-css. It's plenty first-class enough wihtout burdening the
compiler with excessive language features.

On Tue, Sep 13, 2016 at 7:17 PM, Nick H  wrote:
> Hi Kevin,
>
> As far as I can tell, the type alias you are quoting (Value, All,
> NumberedWeight) are not part of the elm-css API. I can't find them in the
> package documentation. Are you suggesting a change to the implementation of
> elm-css, or a change to the interface?
>
> Sorry if I'm missing the point. I don't have a lot of experience with Elm
> CSS.
>
>
> On Tue, Sep 13, 2016 at 8:23 AM, suttlecommakevin
>  wrote:
>>
>> Preface
>>
>> Saying Elm is a language for front-end apps, but leaving out 1/3 of the
>> stack isn't confidence-inspiring.
>> Between our collective experience, I think we can make something awesome
>> and fun to use, while leveraging
>> the features that make Elm a great language.
>>
>>
>> Problem to be solved
>>
>> One thing that React got right was that the UI is always a reflection of
>> state. The UI is defined by HTML/JS, but appearance is defined by CSS.
>>
>> I had proposed that the style attribute of the Virtual DOM package match
>> the same signature of the classList function, by adding a boolean as a
>> param,
>> but that wasn't accepted. To be fair, I didn't provide background or
>> explanation. I should have taken more time to explain. That's on me.
>>
>> What this was meant to do was described just below the style attribute
>> listing in the Elm docs, inside the classList example.
>> As a component author, by applying styles via logic ahead of time, you
>> save component consumers the task of having to know every possible class
>> name.
>>
>> A common trick for this in React is to use ES2015 template strings to
>> interpolate other enumerated properties, thus limiting the scope of what UI
>> component consumers have to know, and what the compiler has to validate
>> against.
>>
>> 
>>
>>
>> where design was enumerated in a PropType list like so:
>>
>> 
>>
>>
>> Prior Art
>>
>> Richard Feldman's work in this area is the most promising I've seen in CSS
>> since Sass. I mean that.
>>
>> One thing I'm curious about though, is in his Elm-CSS library, the APIs
>> don't seem to be taking advantage of Elm's native primitive types.
>> I'm almost a complete n00b, so please take that into context before I give
>> the following example.
>>
>> type alias Value compatible =
>>
>> { compatible | value : String }
>>
>> type alias All compatible =
>>
>> { compatible | value : String, all : Compatible }
>>
>> Like React, it appears that every property and value ends up being a
>> String, even when the possible CSS values are enumerated.
>>
>> Example:
>>
>> type alias NumberedWeight =
>> { value : String, fontWeight : Compatible }
>>
>> Shouldn't this be an Union -> Int  with the possible values of 100 | 200 |
>> 300 | 400 | 500 | 600 | 700 | 800 | 900 ?
>> Am I missing something here (wholly possible and very likely), or is there
>> a reason to not do this with the rest of the package?
>> In this case, it's true that font-weight can take other enumerated strings
>> as values, but I'm wondering why not leverage the native primitive types?
>>
>>
>> I have a slew of other ideas, but let's start here.
>> Thanks!
>>
>> --
>> 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.

-- 
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: Request: loosen syntactic constraints on base-record in record extend/update syntax

[Nick H]

OK, this is a more complex issue than what I had in mind. If you have a
small number of desired initializations (maybe 2 or 3 cases besides
defaultCustomer), I think it would make sense to have multiple construction
functions. But of course that won't scale at all.


On Tue, Sep 13, 2016 at 7:03 AM, Martin Cerny  wrote:

> Hi,
> thanks for the suggestion, but I think you are answering to a different
> problem than the one I had in mind, I'll try to be more clear to avoid
> confusion.
> In my use case, I have a lot of fields, which usually can be kept with
> their default values, but some of them aren't. So not all customers need
> names. Maybe a better example of the code I want to write would be:
>
> type alias Customer =
>   { id : Int,
> name : String ,
> occupation : String,
> nickname : String,
> height : Float,
> -- Lots of other stuff
>   }
>
>
> defaultCustomer : Int -> Customer
> defaultCustomer id =
>   { id = id,
>name = "",
>occupation = "",
>nickname "N/A",
>height : 1.6,
> -- lots of other initialization
>   }
>
> [
>   { (defaultCustomer 1) | name = "Smith", occupation = "Clerk" },
>   { (defaultCustomer 2) | name = "Jones" }
>   { (defaultCustomer 3) | nickname = "R2-D2", height = 0.5 }
> ]
>
>
>
> Martin
>
>
>
>
> On Monday, 12 September 2016 17:50:21 UTC+2, Nick H wrote:
>>
>> In this case, I think the best thing to do would be to make a
>> construction function that takes a name as well as an id.
>>
>> defaultCustomer : Int -> String -> Customer
>> defaultCustomer id name =
>>   { id = id,
>>   , name = name,
>>-- lots of other initialization
>>   }
>>
>> You constructor function should never return an incomplete/invalid
>> record. If your customers always need names, make sure they always get
>> names!
>>
>>
>>
>> On Sun, Sep 11, 2016 at 4:44 AM, Martin Cerny  wrote:
>>
>>> Hi,
>>> hope its polite to bump up an old thread like this - if not, please
>>> accept my apologies. I have been struggling with the record update syntax
>>> for a while and wanted to share another use case which I think could be
>>> made better.
>>> So let's say I want to populate a list of objects of the same type which
>>> have a lot of properties, most of which are kept default, e.g.
>>>
>>> type alias Customer =
>>>   { id : Int,
>>> Name : String ,
>>> -- Lots of other stuff
>>>   }
>>>
>>> and I have a "constructor" function to build instances with default
>>> values, but never forget to fill in the id, e.g.
>>>
>>> defaultCustomer : Int -> Customer
>>> defaultCustomer id =
>>>   { id = id,
>>>Name = "",
>>>-- lots of other initialization
>>>   }
>>>
>>> now I would like to write things like
>>> [
>>>   { (defaultCustomer 1) | Name = "Smith" },
>>>   { (defaultCustomer 2) | Name = "Jones" }
>>> ]
>>>
>>> Which is not possible.
>>>
>>> Now I have two options:
>>> a) do not use a "constructor" and always write the records in full (not
>>> nice since they have a lot of fields which are mostly left default)
>>> b) just have a template defaultCostumer : Customer and hope I will never
>>> forget to fill in the id (used in messages)
>>> c) have a long "let" clause before defining the list
>>>
>>> Neither of which seems nice.
>>>
>>> I'll probably go with b), but if anyone has a nice suggestion how to
>>> enforce filling in a record in this way with the current syntax it would be
>>> very welcome.
>>>
>>> And thanks for the work on elm - I am learning it and having fun with it!
>>>
>>> Martin
>>>
>>>
>>>
>>>
>>>
>>>  but I tried to figure out where on GitHub should this be discussed and
>>> kind of failed...
>>> (is it https://github.com/elm-lang/elm-plans/issues/16 or
>>>
>>> On Saturday, 26 July 2014 18:08:22 UTC+2, Jeff Smits wrote:

 Yeah, I really want this feature. But I guess I forgot about the "code
 comparison".

 @Evan: can you say more concretely what kind of code comparison you
 want to see before moving forward on this feature?

 On Sat, Jul 26, 2014 at 2:26 PM, David Sargeant 
 wrote:

> Seems a little strange that the following does not work:
>
> { {} | attrs = [1] }
>
> I know it's not really useful, but I guess it goes back to the issue
> of allowing arbitrary expressions to the left of the vertical bar.
>
> --
> 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.
>

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

Re: [elm-discuss] Two suggestions for improvements (Regex and Navigation)

[Peter Damoc]

Out of curiosity, what functionality are you actually trying to achieve?

I'm trying to understand the need behind wanting to be dynamic in ignoring
a certain part of the url.

Can you give some URL examples that show what you want to achieve?



On Tue, Sep 13, 2016 at 8:12 PM, OvermindDL1  wrote:

> Does not work in my case of needing to specify a part of the url to ignore
> and to only change the remaining part.  Right now I just have this in my
> code to 'work around it for now':
> ```
> module SomeApp.Hacks exposing (..)
>
> {-| https://github.com/elm-lang/navigation/issues/9
> -}
>
> navigationHack : String
> navigationHack =
> "/some"
> ```
>
> On Tuesday, September 13, 2016 at 10:15:37 AM UTC-6, Peter Damoc wrote:
>>
>>
>>
>> On Tue, Sep 13, 2016 at 6:55 PM,  wrote:
>>
>>>
>>> 2. Giving the Url-Parser (of the Navigation package) access to the
>>> program flags.
>>>
>>> This was a little show stopper for me. I wanted to write a single page
>>> app that does not have to be recompiled if you switch the language.
>>> Different language files are built in, and there is a flag to choose the
>>> language. The problem is, that the paths in the url (after the hash) should
>>> also be in the chosen language. The url parser does not have access to the
>>> model (and I don't see how it could), but it could at least get access to
>>> the flags. I think that could be accomlished easily in
>>> Navigation.programWithFlags.
>>>
>>
>> Wouldn't be easier to just prefix all the urls with the language
>>
>> domain.com/#/en/some/path
>> domain.com/#/fr/vive/la/france
>>
>> This way you could look at the hash/location, figure the language, and
>> then chose the appropriate parser for that language.
>> (this is what I did in my app)
>>
>>
>>
>>
>> --
>> 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.
>



-- 
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] Proposal for a 1st-class, officially-supported CSS package

[Nick H]

Hi Kevin,

As far as I can tell, the type alias you are quoting (Value, All,
NumberedWeight) are not part of the elm-css API. I can't find them in
the package
documentation
. Are you
suggesting a change to the *implementation* of elm-css, or a change to the
*interface*?

Sorry if I'm missing the point. I don't have a lot of experience with Elm
CSS.


On Tue, Sep 13, 2016 at 8:23 AM, suttlecommakevin <
suttlecommake...@gmail.com> wrote:

> *Preface*
>
> Saying Elm is a language for front-end apps, but leaving out 1/3 of the
> stack isn't confidence-inspiring.
> Between our collective experience, I think we can make something awesome
> and fun to use, while leveraging
> the features that make Elm a great language.
>
>
> *Problem to be solved*
>
> One thing that React got right was that the UI is *always* a reflection
> of state . The UI is defined by HTML/JS, but
> appearance is defined by CSS.
>
> I had proposed  that the
> style attribute of the Virtual DOM package match the same signature of the
> classList function, by adding a boolean as a param,
> but that wasn't accepted. To be fair, I didn't provide background or
> explanation. I should have taken more time to explain. That's on me.
>
> What this was meant to do was described just below the style attribute
> listing in the Elm docs, inside the classList example
> 
> .
> As a component author, by applying styles via logic ahead of time, you
> save component consumers the task of having to know every possible class
> name.
>
> A common trick for this in React is to use ES2015 template strings to
> interpolate other enumerated properties, thus limiting the scope of what UI
> component consumers have to know, and what the compiler has to validate
> against.
>
> 
>
>
> where design was enumerated in a PropType list like so:
>
> 
>
>
> *Prior Art*
>
> Richard Feldman's work  in
> this area is the most promising I've seen in CSS since Sass. I mean that.
>
> One thing I'm curious about though, is in his Elm-CSS library
> , the APIs
> don't seem to be taking advantage of Elm's native primitive types.
> I'm almost a complete n00b, so please take that into context before I give
> the following example.
>
> type alias Value compatible =
>
> { compatible | value : String }
>
> type alias All compatible =
>
> { compatible | value : String, all : Compatible }
>
> Like React, it appears that every property and value ends up being a
> String, even when the possible CSS values are enumerated.
>
> *Example:*
>
> type alias NumberedWeight =
> { value : String, fontWeight : Compatible }
>
> Shouldn't this be an Union -> Int  with the possible values of 100 | 200
> | 300 | 400 | 500 | 600 | 700 | 800 | 900 ?
> Am I missing something here (*wholly possible and very likely*), or is
> there a reason to not do this with the rest of the package?
> In this case, it's true that font-weight can take other enumerated
> strings as values, but I'm wondering why not leverage the native primitive
> types?
>
>
> I have a slew of other ideas, but let's start here.
> Thanks!
>
> --
> 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.

Re: [elm-discuss] Two suggestions for improvements (Regex and Navigation)

[OvermindDL1]

Does not work in my case of needing to specify a part of the url to ignore 
and to only change the remaining part.  Right now I just have this in my 
code to 'work around it for now':
```
module SomeApp.Hacks exposing (..)

{-| https://github.com/elm-lang/navigation/issues/9
-}

navigationHack : String
navigationHack =
"/some"
```

On Tuesday, September 13, 2016 at 10:15:37 AM UTC-6, Peter Damoc wrote:
>
>
>
> On Tue, Sep 13, 2016 at 6:55 PM,  
> wrote:
>
>>
>> 2. Giving the Url-Parser (of the Navigation package) access to the 
>> program flags.
>>
>> This was a little show stopper for me. I wanted to write a single page 
>> app that does not have to be recompiled if you switch the language. 
>> Different language files are built in, and there is a flag to choose the 
>> language. The problem is, that the paths in the url (after the hash) should 
>> also be in the chosen language. The url parser does not have access to the 
>> model (and I don't see how it could), but it could at least get access to 
>> the flags. I think that could be accomlished easily in 
>> Navigation.programWithFlags.
>>
>
> Wouldn't be easier to just prefix all the urls with the language 
>
> domain.com/#/en/some/path
> domain.com/#/fr/vive/la/france
>
> This way you could look at the hash/location, figure the language, and 
> then chose the appropriate parser for that language. 
> (this is what I did in my app) 
>
>
>
>
> -- 
> 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: Problem with Html.Lazy

[Mark Hamburg]

There are things you can do in your code to help and things that Elm could
do (maybe already does) in its implementation to help:

For the data construction issue, you need to create an intervening function
that does the construction:

view model = lazy someViewHelper model.data
someViewHelper data = someView { data = data }


But probably not:

view model = lazy (\data -> someView { data = data }) model.data


The compiler could optimize that but might not. That leads to the list of
things the compiler could do (and may be doing) to help:


   - Lift constant expressions. This would help with anonymous functions,
   config records, etc.
   - Optimize { m | field = value } to return m if m.field is already equal
   (referentially) to value.

Sadly, this last optimization doesn't get us anywhere if we are routinely
working with tagged union members since we can't just return the value we
already have. The compiler could cache the last few values constructed with
any given type tag but that creates a drag on the GC.

Mark

P.S. I shifted my code for a while to a form where update had the
signature: update : Msg -> Model -> ( Maybe Model, Cmd Msg ) with the maybe
on the result being used so that unchanged could be indicated by returning
Nothing. This, however, makes sequences of updates harder because we don't
have the model always available which is nice for writing operators like
the following:

(!>) : (model, Cmd msg) -> (model -> (model, Cmd msg)) -> (model, Cmd msg)
(!>) : (oldModel, oldCmd) update =
let
(newModel, newCmd) = update oldModel
in
(newModel, Cmd.batch [oldCmd, newCmd])


The version that works with maybe results needs triples for the state which
can largely be hidden but does tend to then require beginUpdate and
endUpdate functions as well.


On Tue, Sep 13, 2016 at 7:34 AM, OvermindDL1  wrote:

> Lazy is purely and entirely for speed reason, the referential equality is
> for that purpose. If it used equality then imagine suddenly comparing a
> huge model that you passed in, the speed benefits are entirely gone at that
> point.  It is very much a corner case that should not be used except in
> very specific situations.  :-)
>
>
> On Tuesday, September 13, 2016 at 7:43:28 AM UTC-6, James Wilson wrote:
>>
>> I had similar feelings; lazy uses a magical referential equality between
>> things that afaik isn't exposed elsewhere; to me it would be more
>> obvious/clear if it used the same sort of equality as everything else (==),
>> which I'd hope would be able to short circuit the meat of the checking if
>> referentially equal anyway.
>>
>> Basically, I'd be interested to hear more about the decision to use
>> referential equality with lazy too :)
>>
>> On Tuesday, 13 September 2016 12:09:05 UTC+1, Yosuke Torii wrote:
>>>
>>> Hi,
>>>
>>> I have a question about Html.Lazy.
>>>
>>> Now I'm optimizing rendering using Html.Lazy but I feel it is difficult
>>> to use. I found the arguments are not often *referentially* equal and
>>> the view functions are unfortunately called. There are some problems around
>>> this.
>>>
>>>
>>> 1. Sometimes new values are created every time.
>>>
>>> view model = lazy someView { data = model.data }
>>>
>>> 2. Views do not know how arguments are passed.
>>>
>>> view model = lazy grandchildView model
>>>
>>> 3. It is not easy to know if optimization succeeds or not.
>>>
>>> view model = Debug.log "Unfortunately called!" <| text (toString model)
>>>
>>>
>>> I made a demo to describe this problem.
>>>
>>> Source: https://github.com/jinjor/elm-issues/blob/master/src/HtmlLaz
>>> y.elm
>>> Demo: https://jinjor.github.io/elm-issues/html-lazy.html
>>> (9 example views, but 4 ~ 9 are not optimized unfortunately)
>>>
>>> So my question is:
>>>
>>>- Is it a bad idea to compare by *normal *equal?
>>>- Have anyone already solved this problem?
>>>
>>>
>>> Thanks.
>>>
>> --
> 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.

Re: [elm-discuss] Two suggestions for improvements (Regex and Navigation)

[d . vandeneijkel]

That's a good idea. It does not play well with the architecture of the 
program I was working on, but I will investigate it. Thank you!

BTW, I just realized, that my original suggestion would not work, because 
the parser is used at two places; in the init-function it has access to the 
flags, and in the update function it has access to the model. 
Navigation.programWithFlags would need an additional argument with type 
(model -> flags).

-- 
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] Two suggestions for improvements (Regex and Navigation)

[Peter Damoc]

On Tue, Sep 13, 2016 at 6:55 PM,  wrote:

>
> 2. Giving the Url-Parser (of the Navigation package) access to the program
> flags.
>
> This was a little show stopper for me. I wanted to write a single page app
> that does not have to be recompiled if you switch the language. Different
> language files are built in, and there is a flag to choose the language.
> The problem is, that the paths in the url (after the hash) should also be
> in the chosen language. The url parser does not have access to the model
> (and I don't see how it could), but it could at least get access to the
> flags. I think that could be accomlished easily in
> Navigation.programWithFlags.
>

Wouldn't be easier to just prefix all the urls with the language

domain.com/#/en/some/path
domain.com/#/fr/vive/la/france

This way you could look at the hash/location, figure the language, and then
chose the appropriate parser for that language.
(this is what I did in my app)




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

[elm-discuss] Two suggestions for improvements (Regex and Navigation)

[d . vandeneijkel]

Hello everyone,

Elm is great, and version 0.17 is wonderfull. Most of the time, programming 
in Elm feels like exactly how you would like to build things. A big 
thank-you to all the people who made it happen!

However, I stumbled over two litte things that could be improved. One 
concerns the core packages, and one the Navigation package. I hope that 
here's the right place for this. 

1. Creating a Regex from user input. 

The problem now is that an invalid regex string causes Elm to crash. So I 
wonder if the function 'regex' in module Regex could return a 'Maybe Regex' 
instead of simply a Regex? I did not look into the source code, but I guess 
it should be possible to catch the error in javascript and return Nothing 
to the Elm program if the regex is invalid.

2. Giving the Url-Parser (of the Navigation package) access to the program 
flags.

This was a little show stopper for me. I wanted to write a single page app 
that does not have to be recompiled if you switch the language. Different 
language files are built in, and there is a flag to choose the language. 
The problem is, that the paths in the url (after the hash) should also be 
in the chosen language. The url parser does not have access to the model 
(and I don't see how it could), but it could at least get access to the 
flags. I think that could be accomlished easily in 
Navigation.programWithFlags.

I'd be happy to hear your opinions. Please tell me if this is the right way 
to suggest changes, or how I should proceed with such things.

Thanks,
Daniel

-- 
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] Proposal for a 1st-class, officially-supported CSS package

[suttlecommakevin]

*Preface*

Saying Elm is a language for front-end apps, but leaving out 1/3 of the 
stack isn't confidence-inspiring.
Between our collective experience, I think we can make something awesome 
and fun to use, while leveraging
the features that make Elm a great language. 


*Problem to be solved*

One thing that React got right was that the UI is *always* a reflection of 
state . The UI is defined by HTML/JS, but 
appearance is defined by CSS. 

I had proposed  that the 
style attribute of the Virtual DOM package match the same signature of the 
classList function, by adding a boolean as a param,
but that wasn't accepted. To be fair, I didn't provide background or 
explanation. I should have taken more time to explain. That's on me. 

What this was meant to do was described just below the style attribute 
listing in the Elm docs, inside the classList example 

.
As a component author, by applying styles via logic ahead of time, you save 
component consumers the task of having to know every possible class name.

A common trick for this in React is to use ES2015 template strings to 
interpolate other enumerated properties, thus limiting the scope of what UI 
component consumers have to know, and what the compiler has to validate 
against.



 
where design was enumerated in a PropType list like so:




*Prior Art*

Richard Feldman's work  in 
this area is the most promising I've seen in CSS since Sass. I mean that. 

One thing I'm curious about though, is in his Elm-CSS library 
, the APIs 
don't seem to be taking advantage of Elm's native primitive types.
I'm almost a complete n00b, so please take that into context before I give 
the following example.

type alias Value compatible =

{ compatible | value : String }

type alias All compatible =

{ compatible | value : String, all : Compatible }

Like React, it appears that every property and value ends up being a 
String, even when the possible CSS values are enumerated.

*Example:*

type alias NumberedWeight =
{ value : String, fontWeight : Compatible }

Shouldn't this be an Union -> Int  with the possible values of 100 | 200 | 
300 | 400 | 500 | 600 | 700 | 800 | 900 ?
Am I missing something here (*wholly possible and very likely*), or is 
there a reason to not do this with the rest of the package? 
In this case, it's true that font-weight can take other enumerated strings 
as values, but I'm wondering why not leverage the native primitive types? 


I have a slew of other ideas, but let's start here. 
Thanks!

-- 
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: Module manipulation

[OvermindDL1]

On Tuesday, September 13, 2016 at 8:43:27 AM UTC-6, Joey Eremondi wrote:
>
> It's also worth mentioning that first class modules are a decent 
> replacement for type classes.
>

That is precisely the main reason that I am wanting them.  ^.^

Although in that case having OCaml'ish Class Interfaces[0] would simplify 
code even further.  ^.^


[0]: http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual005.html#toc24

-- 
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: Module manipulation

[Joey Eremondi]

It's also worth mentioning that first class modules are a decent
replacement for type classes.

On Sep 13, 2016 7:28 AM, "OvermindDL1"  wrote:

> It seems you are wanting something like OCaml has, first-class modules
> that can be passed around like types and data like OCaml does it?
>
> I would love that and it would fix a lot of the verbosity I have.
>
>
> On Tuesday, September 13, 2016 at 1:23:55 AM UTC-6, Charles-Edouard Cady
> wrote:
>>
>> Would anybody besides me be interested in being able to manipulate module?
>> I was thinking something on the lines of:
>>
>> getUpdate : m -> (m.Model -> m.Msg -> m.Model)
>> getUpdate module =
>>   module.update
>>
>> Then if you have a module, say
>>
>> module Counter exposing (update, Msg, Model)
>>
>> type Model = Int
>>
>> type Msg = Increment | Decrement
>>
>> update : Model -> Msg -> Model
>> update model msg =
>>   case msg of
>> Increment ->
>>   model + 1
>> Decrement ->
>>   model - 1
>>
>> you could use
>>
>> update = getUpdate Counter
>>
>> I think it would allow meta module operations such as putting a list of
>> modules in a view or a list of updates in one big SPA update.
>>
>> What do you think?
>>
> --
> 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: My second Elm project.

[OvermindDL1]

It is to help enforce usage with the spec: 
 https://material.google.com/components/dialogs.html#dialogs-specs

You can actually very easily use mdl directly by just putting the right 
classes and attributes on things, elm-mdl is to help enforce following the 
official spec.  :-)


On Tuesday, September 13, 2016 at 2:44:14 AM UTC-6, Rupert Smith wrote:
>
> On Tuesday, September 13, 2016 at 9:42:16 AM UTC+1, Rupert Smith wrote:
>>
>> One thing that I found a little awkward about elm-mdl is the way Dialog 
>> can only be contructed from Dialog.Blocks, and there are only the 'title', 
>> 'content' and 'actions' constructors available to build such blocks. In my 
>> custom styling I had added an mdl-dialog__media style and used it to render 
>> an image on the dialog just like with cards. I have no way of making that a 
>> Dialog.Block so I just left it out for now. 
>>
>> It is handy to have constructors for various bits of the dialog box, but 
>> perhaps their type should be Html Msg instead of Block? So that any Html I 
>> like can be placed into a dialog. 
>>
>
> Or perhaps a Block constructor that turns any Html into a Block? 
>

-- 
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: Minimize Javascript for deploys

[OvermindDL1]

It works via brunch fine as well.

On Tuesday, September 13, 2016 at 3:02:22 AM UTC-6, Rupert Smith wrote:
>
> On Tuesday, September 13, 2016 at 9:19:27 AM UTC+1, Håkon Rossebø wrote:
>>
>> This is how the clojure compiler is used in the elm-mdl makefile:
>>
>> java -jar closure-compiler.jar -O ADVANCED --assume_function_wrapper --js 
>> elm.js > /tmp/elm.js && mv /tmp/elm.js elm.js
>>
>> I just tried it on one of my own projects and it seems to work fine.
>>
>
> Working for me too, thanks. 
>

-- 
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: Module manipulation

[OvermindDL1]

It seems you are wanting something like OCaml has, first-class modules that 
can be passed around like types and data like OCaml does it?

I would love that and it would fix a lot of the verbosity I have.


On Tuesday, September 13, 2016 at 1:23:55 AM UTC-6, Charles-Edouard Cady 
wrote:
>
> Would anybody besides me be interested in being able to manipulate module?
> I was thinking something on the lines of:
>
> getUpdate : m -> (m.Model -> m.Msg -> m.Model)
> getUpdate module =
>   module.update
>
> Then if you have a module, say
>
> module Counter exposing (update, Msg, Model)
>
> type Model = Int
>
> type Msg = Increment | Decrement
>
> update : Model -> Msg -> Model
> update model msg =
>   case msg of
> Increment ->
>   model + 1
> Decrement ->
>   model - 1
>
> you could use
>
> update = getUpdate Counter
>
> I think it would allow meta module operations such as putting a list of 
> modules in a view or a list of updates in one big SPA update.
>
> What do you think?
>

-- 
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: Request: loosen syntactic constraints on base-record in record extend/update syntax

[Martin Cerny]

Hi, 
thanks for the suggestion, but I think you are answering to a different 
problem than the one I had in mind, I'll try to be more clear to avoid 
confusion.
In my use case, I have a lot of fields, which usually can be kept with 
their default values, but some of them aren't. So not all customers need 
names. Maybe a better example of the code I want to write would be:

type alias Customer =
  { id : Int,
name : String ,
occupation : String,
nickname : String,
height : Float,
-- Lots of other stuff
  }


defaultCustomer : Int -> Customer
defaultCustomer id =
  { id = id,
   name = "",
   occupation = "",
   nickname "N/A",
   height : 1.6,
-- lots of other initialization
  }

[ 
  { (defaultCustomer 1) | name = "Smith", occupation = "Clerk" },
  { (defaultCustomer 2) | name = "Jones" }
  { (defaultCustomer 3) | nickname = "R2-D2", height = 0.5 }
]



Martin




On Monday, 12 September 2016 17:50:21 UTC+2, Nick H wrote:
>
> In this case, I think the best thing to do would be to make a construction 
> function that takes a name as well as an id.
>
> defaultCustomer : Int -> String -> Customer
> defaultCustomer id name =
>   { id = id,
>   , name = name,
>-- lots of other initialization
>   }
>
> You constructor function should never return an incomplete/invalid record. 
> If your customers always need names, make sure they always get names!
>
>
>
> On Sun, Sep 11, 2016 at 4:44 AM, Martin Cerny  > wrote:
>
>> Hi,
>> hope its polite to bump up an old thread like this - if not, please 
>> accept my apologies. I have been struggling with the record update syntax 
>> for a while and wanted to share another use case which I think could be 
>> made better.
>> So let's say I want to populate a list of objects of the same type which 
>> have a lot of properties, most of which are kept default, e.g.
>>
>> type alias Customer =
>>   { id : Int,
>> Name : String ,
>> -- Lots of other stuff
>>   }
>>
>> and I have a "constructor" function to build instances with default 
>> values, but never forget to fill in the id, e.g.
>>
>> defaultCustomer : Int -> Customer
>> defaultCustomer id =
>>   { id = id,
>>Name = "",
>>-- lots of other initialization
>>   }
>>
>> now I would like to write things like
>> [ 
>>   { (defaultCustomer 1) | Name = "Smith" },
>>   { (defaultCustomer 2) | Name = "Jones" }
>> ]
>>
>> Which is not possible.
>>
>> Now I have two options:
>> a) do not use a "constructor" and always write the records in full (not 
>> nice since they have a lot of fields which are mostly left default)
>> b) just have a template defaultCostumer : Customer and hope I will never 
>> forget to fill in the id (used in messages)
>> c) have a long "let" clause before defining the list
>>
>> Neither of which seems nice.
>>
>> I'll probably go with b), but if anyone has a nice suggestion how to 
>> enforce filling in a record in this way with the current syntax it would be 
>> very welcome.
>>
>> And thanks for the work on elm - I am learning it and having fun with it!
>>
>> Martin
>>
>>
>>
>>
>>
>>  but I tried to figure out where on GitHub should this be discussed and 
>> kind of failed...
>> (is it https://github.com/elm-lang/elm-plans/issues/16 or 
>>
>> On Saturday, 26 July 2014 18:08:22 UTC+2, Jeff Smits wrote:
>>>
>>> Yeah, I really want this feature. But I guess I forgot about the "code 
>>> comparison". 
>>>
>>> @Evan: can you say more concretely what kind of code comparison you want 
>>> to see before moving forward on this feature?
>>>
>>> On Sat, Jul 26, 2014 at 2:26 PM, David Sargeant  
>>> wrote:
>>>
 Seems a little strange that the following does not work:

 { {} | attrs = [1] }

 I know it's not really useful, but I guess it goes back to the issue of 
 allowing arbitrary expressions to the left of the vertical bar.

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

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

-- 
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 languages do you write your back-ends in?

[Matt Hughes]

I'm just playing around and don't want to learn another language at the 
moment, so although I'd like to look at Elixir/Phoenix, or F#, or Haskell, 
or Scala, I'm using Java via Dropwizard. 

http://www.dropwizard.io/1.0.0/docs/

If you already know Java, it's a fairly lightweight (for Java) way to get a 
backend up and running. 

mch

On Saturday, September 10, 2016 at 1:41:22 AM UTC-6, Mario Sangiorgio wrote:
>
> Hello,
>
> I was wondering what programming language you use to implement the 
> back-end for your Elm single page web app.
>
> Reading around I see that the Elm/Elixir combo is popular but for how much 
> I think BEAM is an awesome VM I'm a bit sceptical due to Elixir being a 
> dynamic language. How much do you miss the compiler when you write Elixir 
> code?
>
> If you're not using Elixir, to what do you use? I played a bit with F# 
> (using Suave.io) and I think it's quite nice.
>
> Now I'm in the mood of learning something new so I'd like to know what you 
> use and maybe get an idea of what to look at next.
>
> Mario
>

-- 
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] What languages do you write your back-ends in?

[John Orford]

what libs do you use to that? how idiomatic is it in the end?

On Sun, 11 Sep 2016 at 20:55 Eric G  wrote:

> Python at the moment (on Google App Engine), increasingly written in a
> Elm-y/monadic style ;)
>
>
> On Sunday, September 11, 2016 at 12:36:03 PM UTC-4, John Mayer wrote:
>
>> I'll buck the trend and share that I'm happily using Java 8 as my
>> backend. I use protocol buffers over websockets to communicate.
>>
>> https://github.com/jmpspace/jmpspace
>>
>> https://github.com/johnpmayer/elm-protoc
>>
> On Sep 10, 2016 3:41 AM, "Mario Sangiorgio"  wrote:
>>
> Hello,
>>>
>>> I was wondering what programming language you use to implement the
>>> back-end for your Elm single page web app.
>>>
>>> Reading around I see that the Elm/Elixir combo is popular but for how
>>> much I think BEAM is an awesome VM I'm a bit sceptical due to Elixir being
>>> a dynamic language. How much do you miss the compiler when you write Elixir
>>> code?
>>>
>>> If you're not using Elixir, to what do you use? I played a bit with F#
>>> (using Suave.io) and I think it's quite nice.
>>>
>>> Now I'm in the mood of learning something new so I'd like to know what
>>> you use and maybe get an idea of what to look at next.
>>>
>>> Mario
>>>
>>> --
>>> 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.
>>>
>> --
> 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: Problem with Html.Lazy

[James Wilson]

I had similar feelings; lazy uses a magical referential equality between 
things that afaik isn't exposed elsewhere; to me it would be more 
obvious/clear if it used the same sort of equality as everything else (==), 
which I'd hope would be able to short circuit the meat of the checking if 
referentially equal anyway.

Basically, I'd be interested to hear more about the decision to use 
referential equality with lazy too :)

On Tuesday, 13 September 2016 12:09:05 UTC+1, Yosuke Torii wrote:
>
> Hi,
>
> I have a question about Html.Lazy.
>
> Now I'm optimizing rendering using Html.Lazy but I feel it is difficult to 
> use. I found the arguments are not often *referentially* equal and the 
> view functions are unfortunately called. There are some problems around 
> this.
>
>
> 1. Sometimes new values are created every time.
>
> view model = lazy someView { data = model.data }
>
> 2. Views do not know how arguments are passed.
>
> view model = lazy grandchildView model
>
> 3. It is not easy to know if optimization succeeds or not.
>
> view model = Debug.log "Unfortunately called!" <| text (toString model)
>
>
> I made a demo to describe this problem.
>
> Source: https://github.com/jinjor/elm-issues/blob/master/src/HtmlLazy.elm
> Demo: https://jinjor.github.io/elm-issues/html-lazy.html
> (9 example views, but 4 ~ 9 are not optimized unfortunately)
>
> So my question is:
>
>- Is it a bad idea to compare by *normal *equal? 
>- Have anyone already solved this problem?
>
>
> Thanks.
>

-- 
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] Problem with Html.Lazy

[Yosuke Torii]

Hi,

I have a question about Html.Lazy.

Now I'm optimizing rendering using Html.Lazy but I feel it is difficult to 
use. I found the arguments are not often *referentially* equal and the view 
functions are unfortunately called. There are some problems around this.


1. Sometimes new values are created every time.

view model = lazy someView { data = model.data }

2. Views do not know how arguments are passed.

view model = lazy grandchildView model

3. It is not easy to know if optimization succeeds or not.

view model = Debug.log "Unfortunately called!" <| text (toString model)


I made a demo to describe this problem.

Source: https://github.com/jinjor/elm-issues/blob/master/src/HtmlLazy.elm
Demo: https://jinjor.github.io/elm-issues/html-lazy.html
(9 example views, but 4 ~ 9 are not optimized unfortunately)

So my question is:

   - Is it a bad idea to compare by *normal *equal? 
   - Have anyone already solved this problem?


Thanks.

-- 
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: Minimize Javascript for deploys

['Rupert Smith' via Elm Discuss]

On Tuesday, September 13, 2016 at 9:19:27 AM UTC+1, Håkon Rossebø wrote:
>
> This is how the clojure compiler is used in the elm-mdl makefile:
>
> java -jar closure-compiler.jar -O ADVANCED --assume_function_wrapper --js 
> elm.js > /tmp/elm.js && mv /tmp/elm.js elm.js
>
> I just tried it on one of my own projects and it seems to work fine.
>

Working for me too, thanks. 

-- 
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: My second Elm project.

['Rupert Smith' via Elm Discuss]

On Tuesday, September 13, 2016 at 9:39:25 AM UTC+1, Rupert Smith wrote:
>
> I first developed the 'style lab' as static HTML, then converted it to 
> elm-mdl, using html-to-elm along the way then converting all the various 
> components to elm-mdl as necessary.
>

One thing that I found a little awkward about elm-mdl is the way Dialog can 
only be contructed from Dialog.Blocks, and there are only the 'title', 
'content' and 'actions' constructors available to build such blocks. In my 
custom styling I had added an mdl-dialog__media style and used it to render 
an image on the dialog just like with cards. I have no way of making that a 
Dialog.Block so I just left it out for now. 

It is handy to have constructors for various bits of the dialog box, but 
perhaps their type should be Html Msg instead of Block? So that any Html I 
like can be placed into a dialog. 

-- 
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] My second Elm project.

['Rupert Smith' via Elm Discuss]

https://github.com/rupertlssmith/thesett_style_lab

I first developed the 'style lab' as static HTML, then converted it to 
elm-mdl, using html-to-elm along the way then converting all the various 
components to elm-mdl as necessary.

The main difference with pure MDL is that I have developed modifications to 
the MDL styles to gain control over the vertical rhythm and to work up the 
design of various re-usable components. Mainly a table with controls (still 
to do pagination, sorting etc). Also I have made a nice card layout and 
modified the dialog layout to be identical to the card layout for a 
consistent look.

One innovation you may enjoy is the 'debug style' toggle, which draws 
borders around most html components and also draws grid lines for the 24px 
vertical rhythm so I can visually check alignment to the grid.

The borders are drawn as background images using linear-gradient, so they 
do not draw real 1px borders around stuff which would cause positions to 
shift:

h1, h2, h3, h4, p,
dialog,
div, nav,
footer {
background-position: left top;
background-image: linear-gradient(00deg, blue 0px, transparent 1px), 
linear-gradient(90deg, blue 0px, transparent 1px), linear-gradient(180deg, 
blue 0px, transparent 1px), linear-gradient(270deg, blue 0px, transparent 
1px);
}

The grid lines are drawn on the background, with divs stacked on top made 
transparent so you can see them:

div,
footer,
header {
background-color: transparent !important;
}

dialog,
body {
background-image: linear-gradient(to bottom, hsla(200, 100%, 50%, .3) 
1px, transparent 1px);
background-position: left -1px;
background-repeat: repeat;
background-size: rhythm(1) rhythm(1);
}

===

Working with Elm is a very pleasant experience and not at all difficult to 
pick it up. I can already see re-usable functions that I can refactor out 
of of View code to simplify working with the same UI constructs over and 
again. This is much more powerful than working with a template language 
such as handlebars, as I can also pass functions as parameters to 
functions, not just substitute in values to render.

-- 
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: Minimize Javascript for deploys

[Håkon Rossebø]

This is how the clojure compiler is used in the elm-mdl makefile:

java -jar closure-compiler.jar -O ADVANCED --assume_function_wrapper --js 
elm.js > /tmp/elm.js && mv /tmp/elm.js elm.js

I just tried it on one of my own projects and it seems to work fine.



mandag 12. september 2016 23.03.02 UTC+2 skrev Dmytro Gladkyi følgende:
>
> I just use gulp-minify from npmjs:
>
> var minify = require("gulp-minify");
>
>
> gulp.task("minify", ["build-elm"], function() {return 
> gulp.src("./elm.js") //elm.js is what elm-make outputs.pipe(minify())
> .pipe(gulp.dest("./"));});
>
>
> I also tried Google Closure Compiler - but it gave me errors regarding 
> uninitialized variables from elm lib
>
>
> On Monday, September 12, 2016 at 7:29:47 PM UTC+3, Jim Freeze wrote:
>>
>> Hi
>>
>> I can't seem to find in the docs how to minimize the javascript for 
>> production.
>>
>> Does elm provide these tools or are we to use other tools to uglify and 
>> minimize the javascript?
>>
>> Thank you.
>>
>> -- 
>> Dr. Jim Freeze, Ph.D.
>> (m) 512 949 9683
>>
>

-- 
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] Module manipulation

[Charles-Edouard Cady]

Would anybody besides me be interested in being able to manipulate module?
I was thinking something on the lines of:

getUpdate : m -> (m.Model -> m.Msg -> m.Model)
getUpdate module =
  module.update

Then if you have a module, say

module Counter exposing (update, Msg, Model)

type Model = Int

type Msg = Increment | Decrement

update : Model -> Msg -> Model
update model msg =
  case msg of
Increment ->
  model + 1
Decrement ->
  model - 1

you could use

update = getUpdate Counter

I think it would allow meta module operations such as putting a list of 
modules in a view or a list of updates in one big SPA update.

What do you think?

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