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.
