Re: [elm-discuss] Re: Compiler option to disable camel-case record property requirement?

[Witold Szczerba]

There is no need to convert JS object to a string. Just declare a Value in
your port and now you can decode it as you will.

Regards,
Witold Szczerba

30.03.2017 7:14 PM "Christian Charukiewicz" 
napisał(a):

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

-- 
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 
> ,
>  
> 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 
,
 
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?

['Rupert Smith' via Elm Discuss]

On Wednesday, March 29, 2017 at 4:41:36 PM UTC+1, 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?
>

Do you have some meta-data describing the data structure that you want to 
map into Elm? For example json-schema or Swagger or possibly even the 
database DDL if the tables map to the HTTP response bodies in a very 1:1 
way? If you have this, you could invest in writing a code generator that 
automatically writes your Elm Encoder/Decoder logic for you.

As others have noted you can specify different field names in the json from 
the Elm records and have the Elm Encoder/Decoder logic handle the 
conversion between pascal and camel case for you.

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

[Stein Setvik]

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?

[Stein Setvik]

I haven't looked into decoders yet. I'll read up on it and give them ago to 
see if there's a performance advantage to doing it on the Elm side vs the 
js side.

On Wednesday, March 29, 2017 at 9:44:11 AM UTC-7, Kasey Speakman wrote:
>
> Short of language changes, you could:
>
> * Use the infamous encoders/decoders to emit/parse pascal case.
> * Use a header on the HTTP request to instruct the server to assume camel 
> case for the request.
>
> Without pre-existing clients, I have the server emit camelCase (a 
> serializer configuration option). In a happy surprise, deserialization was 
> already case-insensitive (in JSON.NET) so I didn't have any trouble using 
> my pascal case objects there.
>
> 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]

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?

[Kasey Speakman]

Short of language changes, you could:

* Use the infamous encoders/decoders to emit/parse pascal case.
* Use a header on the HTTP request to instruct the server to assume camel 
case for the request.

Without pre-existing clients, I have the server emit camelCase (a 
serializer configuration option). In a happy surprise, deserialization was 
already case-insensitive (in JSON.NET) so I didn't have any trouble using 
my pascal case objects there.

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.