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 [email protected]. For more options, visit https://groups.google.com/d/optout.
