> > On Sunday, September 25, 2016 at 8:54:50 AM UTC+10, Eric G wrote: >> >> - 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. >> > I find myself using Lists most of the time. Probably because: - Lists is sort of entry level (consider myself still beginner in Elm) - all the tutorials are in Elm - I find code for List manipulation easier to understand/ read. - Lists are a lot easier to manipulate (especially sorting and filtering), which is what happens a lot in my code - Many of the the lists I work with are not very long (so no performance need to switch to Dict)
> - 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. >> > I think you already answered this yourself :) The genre-like data, I put in my model as a separate List (ID, String). They are a List because for the program it does not matter how many genres they are, and what their names are. If the app has logic to deal with genres (e.g. filters), it will also work if the list has more items. User Roles is a specific case: because it DOES matter how many options there are + your program needs logic for each role, Elm types do make sense. I wouldn't worry about the duplication: ALL server side data sent to client will of course be stored = duplicated there. And it is not uncommon to transform server data into different types at client side. -- 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.
