You said you cannot write a decoder because there is no constructor for: type alias AnimatedImage = MakeAnimated StaticImage
This is true, but you still can create your own function. I know that would be a pain to keep that function in sync with those aliases (when they change) though. Regards, Witold Szczerba On Tue, Jan 3, 2017 at 5:40 AM, Leo Zhang <[email protected]> wrote: > Sorry to necropost, but this problem bit me recently. Here's my use case. > > I'm working on an client that displays albums, static images, and animated > images. The backend (which is third-party, so I can't change it) sends has > lots of redundancy in the data models it sends me, so my models look > something like this: > > AnimatedImage is a superset of StaticImage is a superset of GalleryItem; > Album is a superset of GalleryItem. > > The way I've got this worked out using extension is: > > type alias StaticImage = { > -- static image fields here > } > > type alias MakeAnimated staticImage = { > staticImage | > -- animated image fields here > } > > type alias AnimatedImage = MakeAnimated StaticImage > > Unfortunately, I can't figure out how to do JSON decoding this way because > there is no type constructor for AnimatedImage. I'm working around this by > nesting instead (i.e. having AnimatedImage contain a StaticImage field > which contains a GalleryItem field), but this quickly gets unwieldy because > working with AnimatedImages still requires me to access GalleryItem > properties (e.g. all gallery items have a "url" field) a lot and nesting > makes my code more noisy without adding semantic meaning. > > On Friday, 18 March 2016 01:06:22 UTC-7, Magnus Rundberget wrote: >> >> I'm not sure I buy that as a convincing argument for not using nesting. >> >> I'm inferring (sorry if that's a strawman, but your post is a bit scarce >> in terms of details) that you are saying that the view model(s) in elm >> must map 1-1 with the backend requests ? That to me is a bit like saying >> your backend model needs to map 1-1 with your database model isn't it ? I >> think it's to be expected to have to do mapping between abstraction layers >> and even more so between process boundaries. >> Something like graphql might make that less the case for web apps, but I >> still believe there will be some level of mapping regardless. >> >> I can't think of a single time I found me wanting to mirror the structure >> of my ui model exactly like the structure of a large nested request, >> modify it and then send back the modified stuff to the backend >> >> Maybe you could elaborate a little bit about your use case, to help me >> understand why the ui would/could be structured like the document structure >> from your backend documents ? >> >> >> Just to be clear I'm not entirely convinced nesting is always the best >> solution (especially when Elm seems to favor making it difficult/cumbersome >> to perform nested record updates). However I haven't come up with a great >> example where record extension(inheritance in my still highly oo influnced >> brain) would clearly be better than nesting (aka composition?) >> >> cheers >> - magnus >> >> >> >> >> >> >> >> On Friday, 18 March 2016 08:22:36 UTC+1, Kamil Durkiewicz wrote: >>> >>> Hi guys, >>> >>> I've got another case when nesting is worse than extension. It comes >>> from our current project. We're building a client application for an >>> existing backend (which we cannot change). The backend returns large and >>> nested documents (dozens of fields on each level) for GET requests and >>> accepts documents of the same structure in POST requests when you want to >>> do an update. In such case, the client application need to use the same >>> document structure, otherwise it would be really confusing and error-prone >>> at request construction level. >>> >> -- > 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.
