If the random access happens only on user input, ie it's not something you need to do several thousands times per second, stick to Lists. If you need a particular sorting order, stick to Lists.
You can use `Dict.foldl/r` to map a dictionary to a list in a single step, rather than first converting and then mapping. This should give you a rendering performance similar to that of `List.map`. All in all, if performance is the problem, I'd try both approaches and see which one works better. (You could even write a thin layer between your app and the container, so that you can switch from List to Dict without touching much of your code). Re "value types", if I understand correctly, if you have complex behavior to model on that I'd use a Union Type. I'd expect the user to want to specify a "genere" which is not in a list of preset, which mean you'd want to leave it a String. On Sunday, September 25, 2016 at 8:54:50 AM UTC+10, Eric G wrote: > > Thanks for this question and the suggestions - very useful to issues I am > dealing with now. > > Some questions: > > - Is it better to use Dicts as the basic 'table' structure, if frequently > rendering lists of items filtered and sorted in various ways? In short, is > it better to convert a `List (ID, Item)` to a Dict for finding items, or > convert a `Dict ID Item` to a List for rendering them? I kind of am > leaning towards `List (ID, Item)` as the persistent data structure esp. for > data that is frequently rendered in lists, but would really appreciate > hearing what peoples' actual experiences have been. > > - How are people modelling so-called 'value types' ? For example in the > Albums/Artists if you had a `genre` type assigned to Albums. The genre > types change infrequently, but perhaps the application still needs some > kind of user interface to change them, which suggests they should be stored > as data, e.g. `List (ID, String)`, with no special behavioral significance > to the app. On the other hand, in some cases you have value types that > *do* have behavioral significance, such as e.g. User Roles, and it is > tempting to want to have these map to Elm types instead of strings when you > `case` on them in view and update. But this means duplication of server- > and/or datastore- side data, and you still have to map your Elm types back > to IDs. > > Anyway, some rambling thoughts but curious if people have dealt with these > kinds of issues. > -- 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.
