Re: [elm-discuss] Best practices for designing models in the Elm Architecture - lean or rich?

[Christian Charukiewicz]

In your expensive function example, you should be able to take advantage of 
Html.Lazy to prevent the view from re-running the expensive function unless 
its parameters change.  By storing the derived data in the model rather 
than letting Elm handling the caching through the Lazy functions, you are 
effectively doing something similar but at the cost of adding a lot of 
complexity to your application.

On Tuesday, July 25, 2017 at 2:11:22 AM UTC-5, Peter Damoc wrote:
>
> Keep derived data in the model if it makes sense to keep derived data in 
> the model. 
>
> If you have an expensive function that runs and computes a derived value 
> and you would have to call frequently this function in your view, then by 
> all means, computer the derived value in update and save it in the model. 
>
> If you don't run into a performance problem like the above, keep your 
> model clean and just extract the computation in a function. for example, 
> you could have something like 
>
> bmiText : Model -> Html msg 
> bmiText {weight, height} = 
> weight / height ^ 2 |> toString |> text 
>
> this way, everywhere you need that textual representation, you can use it. 
>
>
>
>
> On Tue, Jul 25, 2017 at 4:23 AM, Ray Toal  > wrote:
>
>> This might be an opinion-based question so I can't ask it on 
>> StackOverflow. :-)
>>
>> I have a trivial beginnerProgram using the Elm Architecture. It has two 
>> text fields (HTML input elements), one for weight and one for height. The 
>> onInput attributes of each generate a message. The update function accepts 
>> the message and produces the new model.
>>
>> The question is: Should the model (a) consist of the width and height 
>> only, or (b) also include the computed BMI (width / height^2)? If the 
>> former, I compute the BMI in the view function; if the latter, I would 
>> compute it in the update function.
>>
>> Does anyone have a lot of experience with Elm applications that would 
>> lead them to believe that keeping models as small as possible and computing 
>> derived data in the view function is better than making rich models? I 
>> don't have enough experience with Elm to know. I sense that for a problem 
>> as simple as mine it really doesn't matter (and I in fact got it working 
>> both ways), but as I start scaling up my apps it would be nice to know if 
>> there is best practice here (or not).
>>
>> -- 
>> 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.

[elm-discuss] Re: Best practices for designing models in the Elm Architecture - lean or rich?

[Christian Charukiewicz]

You should not keep derived values in the model.  The model should be a 
single source of truth.  This property is violated if you store derived 
data in the model.  What happens if you create a new input that fires a 
different Msg that only updates the height, but does not recompute and 
update the BMI?  Should you now be reading from the weight and height 
fields?  Or should you be reading from the BMI?  Or what happens if you add 
a reset Msg?  If you store this derived BMI calculation in your model, you 
have 3 fields to worry about rather than 2.

On Monday, July 24, 2017 at 8:23:44 PM UTC-5, Ray Toal wrote:
>
> This might be an opinion-based question so I can't ask it on 
> StackOverflow. :-)
>
> I have a trivial beginnerProgram using the Elm Architecture. It has two 
> text fields (HTML input elements), one for weight and one for height. The 
> onInput attributes of each generate a message. The update function accepts 
> the message and produces the new model.
>
> The question is: Should the model (a) consist of the width and height 
> only, or (b) also include the computed BMI (width / height^2)? If the 
> former, I compute the BMI in the view function; if the latter, I would 
> compute it in the update function.
>
> Does anyone have a lot of experience with Elm applications that would lead 
> them to believe that keeping models as small as possible and computing 
> derived data in the view function is better than making rich models? I 
> don't have enough experience with Elm to know. I sense that for a problem 
> as simple as mine it really doesn't matter (and I in fact got it working 
> both ways), but as I start scaling up my apps it would be nice to know if 
> there is best practice here (or not).
>
>

-- 
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: On producing production product

[Christian Charukiewicz]

>
> Well, I run this small team that somehow, after Elm, became a lot bigger, 
> even tho the number of people remained.

 
Fantastic way to summarize the impact of Elm on a small team.  I share the 
same experience since we adopted Elm for production use.

On Wednesday, June 7, 2017 at 6:56:01 AM UTC-5, Birowsky wrote:
>
> Sup team, I just poured my feelings towards Elm on Medium:
>
> Web is ready for you on line 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.

[elm-discuss] Re: Google Places and Elm / Identifying when Elm is mounted

[Christian Charukiewicz]

I think what you want to do here is load your compiled Elm js script 
followed by your googleapis script.

One way to do this would be to use jQuery's getScript() function (or a 
vanilla JS equivalent of it ) to 
sequence the order of the loading.

With jQuery your approach would look something like this (note I have not 
tested this code):




function initElmApp(callback) {
var node = document.getElementById('elm');
var app = Elm.Main.embed(node);
callback();
}

function initGoogleScript() {
$.getScript('path/to/google-places');
}

initElmApp(initGoogleScript());


Someone else may have a better way to do this, but this should work.


On Monday, April 3, 2017 at 7:11:09 PM UTC-5, Fikse wrote:
>
> Is there a way to tell if Elm is mounted in the DOM? I am attempting to 
> use Google Places with ports. The Google Places code is trying to attach to 
> an HTML element generated by Elm, but it doesn't exist on the page. My code 
> is at https://ellie-app.com/Pzg2NLX7W5a1/3 and the error can be found in 
> the developer tools console.
>
>
> - fikse
>
>

-- 
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: Flags vs Ports

[Christian Charukiewicz]

This is correct.  I think you listed the primary use cases that each 
interface serves, but I would say ports goes beyond just data.  I can 
provide a few examples of how we use both.

Our Elm application is embedded into several pages of a much older and 
larger CakePHP application (CakePHP is a full stack framework that is 
similar Django or Ruby on Rails in that it handles both front and back end).

We use *Flags* to...

   - Set information about the current user's permission group, to show or 
   hide certain view elements (the back end of course verifies this as well, 
   so there's no way a user can receive or modify data they are not authorized 
   to access)
   - Set the initialization mode of the application, allowing us to reuse 
   certain view components of the Elm application in different pages but with 
   different options enabled (e.g. a full screen mode and a windowed mode that 
   gets embedded in a modal)
   - *Possibly* set the initial state of the model (currently the Elm app 
   fires several HTTP requests to the back end API to download the application 
   data)

We use *Ports* to..

   - Make very specific DOM manipulations (things we cannot do in Elm such 
   as add or remove styles to the document's html node)
   - Access to the browser's window API (e.g. window.localStorage)

Hope that helps.


On Monday, April 3, 2017 at 1:41:57 AM UTC-5, Richard Wood wrote:
>
> Sounds like some nautical adventure!
>
> When is it appropriate to bring in data through flags vs through using 
> ports.
> At the moment I'm thinking:
>
> Flags: 
> * When needed immediately on initialisation
> * When it won't change
>
> Ports:
> * Dynamic data
> * Data not available at the start
>
> Is another reason to use a flag to avoid a perhaps unnecessary maybe? This 
> came up when trying to have a time variable. I don't want a maybe time 
> variable as then I have to handle the maybe every time I use it. So I'm 
> thinking to pass the time in as a flag to begin with then keep it update 
> through ports.
>

-- 
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: Compiler option to disable camel-case record property requirement?

[Christian Charukiewicz]

Sorry I made a few bad typos in my last example function.  It should be:

decodeUser : String -> User
decodeUser jsonString =
decodeString userDecoder jsonString



On Thursday, March 30, 2017 at 12:14:23 PM UTC-5, Christian Charukiewicz 
wrote:
>
> To add onto what Rupert said, my assumption is that you are relying on 
> Ports automatically converting your JS objects to Elm records with 
> identical field types.  This is very cumbersome.  And, as far as I know, 
> you are also limited to using primitive types (Int, Bool, String, List, 
> etc), and can't use ports to any custom union types that you will likely 
> create as your application grows.
>
> What you can do instead is send your entire object as a JSON string (in 
> Elm you would just receive it as a single String value) and then apply a 
> Decoder you write yourself to that string to produce whatever Elm values 
> you want.  You would be using Decode.decodeString 
> <http://package.elm-lang.org/packages/elm-lang/core/latest/Json-Decode#decodeString>,
>  
> but be sure to look at the rest of the documentation in that module.  Your 
> first argument to decodeString will be a Decoder that you create yourself, 
> which in the case of a complex object may be the composition of several 
> Decoder functions that serve to transform the JSON data into whatever Elm 
> values you want.  This way you are not constrained to use matching 
> record/field names either.
>
> Decoders are a huge part of Elm, and you will encounter them elsewhere.  I 
> strongly suggest taking the time to learn to use them, as this more than 
> likely fix your performance issues as well.  We have decoded wildly complex 
> JSON objects with Elm Decoders and have never noticed a degradation in 
> performance at all.
>
> To give you a bit of help, here's an example:
>
> Say I have an object like
>
> {
> user_id: 5
> user_name: "John"
> }
>
> And my Elm type is:
>
> type alias User =
> { userId: Int
> , userName: String
> }
>
>
> My decoder might look like:
>
> userDecoder : Decoder User
> userDecoder =
> map2 User
> (field "user_id" int)
> (field "user_name" string)
>
> And applying it would look like (assuming jsonString was a JSON string 
> sent as a single value by a Ports)
>
> decodeUser : String -> User
> decoderUser jsonString =
> decoderString userDecoder jsonString
>
> Hope that helps!
>
> On Thursday, March 30, 2017 at 12:11:44 AM UTC-5, Stein Setvik wrote:
>>
>> We're using Ports to bring the data from js into elm.
>>
>> On Wednesday, March 29, 2017 at 9:01:45 PM UTC-7, Christian Charukiewicz 
>> wrote:
>>>
>>> Can you elaborate on how you are getting the data from the backend into 
>>> Elm values?  Are you not using Elm decoders?  We use snake_case for all of 
>>> our database fields, and writing decoders that will receive the JSON and 
>>> produce Elm values is a step we have to take with all of our data before it 
>>> ends up in an Elm record value anyway.  Are you avoiding this somehow?
>>>
>>> On Wednesday, March 29, 2017 at 10:41:36 AM UTC-5, Stein Setvik wrote:
>>>>
>>>> Would you consider adding an option for users to disable the camel-case 
>>>> requirement for record properties in the compiler?
>>>>
>>>> Our use case:
>>>> We have a large legacy system we'd like to bring Elm into that uses 
>>>> pascal case throughout (all database fields and all places they're 
>>>> referenced in the backend and frontend).
>>>>
>>>> We are planning on updating to camel case; however, it will be a 
>>>> complicated change and is ~9 months out.
>>>>
>>>> We'd like to look at Elm before then, but the camel case requirement is 
>>>> creating a performance hit because we have to clone all objects and rename 
>>>> all pascal cased properties before shipping them over ports to Elm.
>>>>
>>>> Example:
>>>> We migrated a results view for realtime search (Algolia) in a product 
>>>> catalog. The result view updates in real-time with every keystroke, and 
>>>> the 
>>>> JS transformation of the data before sending it to Elm is weighty enough 
>>>> to 
>>>> delay and slow the rendering of the results in a noticeable way.
>>>>
>>>> Thoughts?
>>>>
>>>

-- 
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: Compiler option to disable camel-case record property requirement?

[Christian Charukiewicz]

To add onto what Rupert said, my assumption is that you are relying on 
Ports automatically converting your JS objects to Elm records with 
identical field types.  This is very cumbersome.  And, as far as I know, 
you are also limited to using primitive types (Int, Bool, String, List, 
etc), and can't use ports to any custom union types that you will likely 
create as your application grows.

What you can do instead is send your entire object as a JSON string (in Elm 
you would just receive it as a single String value) and then apply a 
Decoder you write yourself to that string to produce whatever Elm values 
you want.  You would be using Decode.decodeString 
<http://package.elm-lang.org/packages/elm-lang/core/latest/Json-Decode#decodeString>,
 
but be sure to look at the rest of the documentation in that module.  Your 
first argument to decodeString will be a Decoder that you create yourself, 
which in the case of a complex object may be the composition of several 
Decoder functions that serve to transform the JSON data into whatever Elm 
values you want.  This way you are not constrained to use matching 
record/field names either.

Decoders are a huge part of Elm, and you will encounter them elsewhere.  I 
strongly suggest taking the time to learn to use them, as this more than 
likely fix your performance issues as well.  We have decoded wildly complex 
JSON objects with Elm Decoders and have never noticed a degradation in 
performance at all.

To give you a bit of help, here's an example:

Say I have an object like

{
user_id: 5
user_name: "John"
}

And my Elm type is:

type alias User =
{ userId: Int
, userName: String
}


My decoder might look like:

userDecoder : Decoder User
userDecoder =
map2 User
(field "user_id" int)
(field "user_name" string)

And applying it would look like (assuming jsonString was a JSON string sent 
as a single value by a Ports)

decodeUser : String -> User
decoderUser jsonString =
decoderString userDecoder jsonString

Hope that helps!

On Thursday, March 30, 2017 at 12:11:44 AM UTC-5, Stein Setvik wrote:
>
> We're using Ports to bring the data from js into elm.
>
> On Wednesday, March 29, 2017 at 9:01:45 PM UTC-7, Christian Charukiewicz 
> wrote:
>>
>> Can you elaborate on how you are getting the data from the backend into 
>> Elm values?  Are you not using Elm decoders?  We use snake_case for all of 
>> our database fields, and writing decoders that will receive the JSON and 
>> produce Elm values is a step we have to take with all of our data before it 
>> ends up in an Elm record value anyway.  Are you avoiding this somehow?
>>
>> On Wednesday, March 29, 2017 at 10:41:36 AM UTC-5, Stein Setvik wrote:
>>>
>>> Would you consider adding an option for users to disable the camel-case 
>>> requirement for record properties in the compiler?
>>>
>>> Our use case:
>>> We have a large legacy system we'd like to bring Elm into that uses 
>>> pascal case throughout (all database fields and all places they're 
>>> referenced in the backend and frontend).
>>>
>>> We are planning on updating to camel case; however, it will be a 
>>> complicated change and is ~9 months out.
>>>
>>> We'd like to look at Elm before then, but the camel case requirement is 
>>> creating a performance hit because we have to clone all objects and rename 
>>> all pascal cased properties before shipping them over ports to Elm.
>>>
>>> Example:
>>> We migrated a results view for realtime search (Algolia) in a product 
>>> catalog. The result view updates in real-time with every keystroke, and the 
>>> JS transformation of the data before sending it to Elm is weighty enough to 
>>> delay and slow the rendering of the results in a noticeable way.
>>>
>>> Thoughts?
>>>
>>

-- 
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] Better syntax for nested pattern matching (destructuring)?

[Christian Charukiewicz]

It's an option in the browser-based rich text editor that appears when 
posting/replying.  The button looks like curly braces "{}".  Highlight the 
code you have written and then press the button. 

On Wednesday, March 29, 2017 at 11:12:31 PM UTC-5, Duane Johnson wrote:
>
> May I ask how you create these nicely formatted Elm blocks in google 
> groups?
>
> On Wed, Mar 29, 2017 at 10:40 AM, Matthieu Pizenberg <
> matthieu@gmail.com > wrote:
>
>> Multiple times in my projects, I happen to need nested pattern matching.
>> Below is a raw extract of code (in an update) showing this need.
>>
>> Study.ScribblesMsg scribblesMsg ->
>> case model.study.status of
>> Study.Progressing steps ->
>> case Pivot.getC steps of
>> Study.ScribblesStep ( imageUrl, scribbles ) ->
>> ( Scribbles.update scribblesMsg model scribbles
>> , Cmd.none
>> )
>>
>> _ ->
>> ( model, Cmd.none )
>>
>> _ ->
>> ( model, Cmd.none )
>>
>> Basically, this is a specific case of a generic following code:
>>
>> case f1 var1 of
>> DataType2 var2 ->
>> ...
>> case fn varn of
>> finalVar ->
>> doSomethingOf finalVar
>> _ ->
>> otherwise
>> ...
>>  _ ->
>> otherwise
>>
>> Do you think there could exist a syntax enabling better handling of such 
>> a case?
>> Have you encountered one in another langage maybe?
>>
>> -- 
>> 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: Better syntax for nested pattern matching (destructuring)?

[Christian Charukiewicz]

We have found that this pattern is typically a good case for chaining a 
bunch of andThen statements with a withDefault statement at the end 
together.  The one thing is you would have to be able to adjust your values 
to all be Maybes.

For example, if you have the following:

case someMaybeVal of
Just someVal ->
case someVal.record of
Just someInnerVal ->
Just finalVal

Nothing ->
someDefaultVal
Nothing ->
someDefaultVal

You can replace it with:

someMaybeVal
|> andThen (\someVal -> Just someVal.record)
|> andThen (\someInnerVal -> Just finalVal)
|> withDefault someDefaultVal

Looking at the documentation for andThen 
 
may help.


On Wednesday, March 29, 2017 at 11:40:40 AM UTC-5, Matthieu Pizenberg wrote:
>
> Multiple times in my projects, I happen to need nested pattern matching.
> Below is a raw extract of code (in an update) showing this need.
>
> Study.ScribblesMsg scribblesMsg ->
> case model.study.status of
> Study.Progressing steps ->
> case Pivot.getC steps of
> Study.ScribblesStep ( imageUrl, scribbles ) ->
> ( Scribbles.update scribblesMsg model scribbles
> , Cmd.none
> )
>
> _ ->
> ( model, Cmd.none )
>
> _ ->
> ( model, Cmd.none )
>
> Basically, this is a specific case of a generic following code:
>
> case f1 var1 of
> DataType2 var2 ->
> ...
> case fn varn of
> finalVar ->
> doSomethingOf finalVar
> _ ->
> otherwise
> ...
>  _ ->
> otherwise
>
> Do you think there could exist a syntax enabling better handling of such a 
> case?
> Have you encountered one in another langage maybe?
>

-- 
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: Compiler option to disable camel-case record property requirement?

[Christian Charukiewicz]

Can you elaborate on how you are getting the data from the backend into Elm 
values?  Are you not using Elm decoders?  We use snake_case for all of our 
database fields, and writing decoders that will receive the JSON and 
produce Elm values is a step we have to take with all of our data before it 
ends up in an Elm record value anyway.  Are you avoiding this somehow?

On Wednesday, March 29, 2017 at 10:41:36 AM UTC-5, Stein Setvik wrote:
>
> Would you consider adding an option for users to disable the camel-case 
> requirement for record properties in the compiler?
>
> Our use case:
> We have a large legacy system we'd like to bring Elm into that uses pascal 
> case throughout (all database fields and all places they're referenced in 
> the backend and frontend).
>
> We are planning on updating to camel case; however, it will be a 
> complicated change and is ~9 months out.
>
> We'd like to look at Elm before then, but the camel case requirement is 
> creating a performance hit because we have to clone all objects and rename 
> all pascal cased properties before shipping them over ports to Elm.
>
> Example:
> We migrated a results view for realtime search (Algolia) in a product 
> catalog. The result view updates in real-time with every keystroke, and the 
> JS transformation of the data before sending it to Elm is weighty enough to 
> delay and slow the rendering of the results in a noticeable way.
>
> Thoughts?
>

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