Re: [elm-discuss] Immutable data design problem

Thanks for your help, Aaron. On Mon, Jul 24, 2017 at 11:01 PM, Aaron VonderHaar wrote: > Ah yes, a nice complicated system :) If you're still looking for more > abstract suggestions, here's how I would approach the problem: > Indeed the real system is much more

Re: [elm-discuss] Immutable data design problem

Ah yes, a nice complicated system :) If you're still looking for more abstract suggestions, here's how I would approach the problem: It sounds like you're trying to construct intermediate data structures that directly map to certain domain concepts, and then you later have to transform that

Re: [elm-discuss] Immutable data design problem

Hi Harry, That's an interesting pattern I hadn't thought of. I had been thinking more along the lines of: type alias AssessmentEvent a = { a | otherField : Int } Then something like: type alias InitialAssessmentEvent = AssessmentEvent {} type alias ComputedAssessmentEvent =

Re: [elm-discuss] Immutable data design problem

Hi Aaron, Thanks for your thoughtful reply. The domain model is pretty complex, so it's hard to distill down to a few issues. There's a higher-level structure called a Parcel. That already contains, among other things, the list of AssessmentEvents. I have a function called createParcel that

Re: [elm-discuss] Immutable data design problem

I'm not sure I understand all the details of your domain model, but it seems like the notable point is that accounts are created implicitly as assessment events occur, and you'd like to be able to, given an assessment event, get the related accounts? I'd probably start with making a module (maybe

[elm-discuss] Immutable data design problem

I have a series of datatypes that have already been modeled in a relational database in a product. I'm trying to construct a lighter-weight in-memory representation in Elm for purposes of simulating operations and visualizing the results. Ultimately I will probably want to do some export/import