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