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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
