Change component indexes inside model to String or comparable

[doodledood]

Currently some components need an integer index to render in order to find their model. This should be changed to a String type instead mainly because the of cognitive burden associated with keeping track of unique numbers instead of unique meaningful names.

[debois]

@vipentti, nice PR debois/elm-parts#8!

If we integrate this in elm-mdl, users will have to decide on an index type when they define their model and messages, right?

type alias Model = 
  { ...
  , mdl : Material.Model String
  }

 type Msg =
   ...
   | Mdl Material.Msg Msg String

Now that I see this, I'm a little concerned that users will get really complicated type errors if they don't use the same type in both places.

Any comments?

[doodledood]

Well, since this is a UI library, my opinion is that we should keep it simple and limit ids to strings to avoid this problem. Using a generic type here doesn't really offer much and opens a door for confusion.

Another option would be to keep the generic type but recommend using a custom union type that contains the unique ids (like elm-css does). Adds a bit boilerplate but now you have the compiler on your side, telling you when you created a non unique id. (probably will need to convert the type to string to use as id anyways)

[debois]

Very interesting, especially the bit about unique IDs. Can you provide a link to the elm-css implementation? Or an example use?

[doodledood]

See implementation of "(#)"

What they do is use a generic type and then convert it to a string inside their module

[vipentti]

@debois We could also define the type in Material.elm

-- Material.elm 

type alias Indexed m =
  Parts.Indexed String m

type alias Index =
  Parts.Index String

-- Then change all instances of Parts.Index(ed) to Material.Index(ed)

[debois]

I think it'd be nice to have this in v8.

I'm torn between on the one hand wanting a single API that never gives weird type errors and on the other wanting to support both existing users List Int usage and new (or converting) users List String usage. Not sure how to square this.

[OvermindDL1]

My programmerize would prefer the method where I can specify the type. However it might be better to just pick String as the type for List String everywhere, it is both uniform and anything can be cast to string anyway. Plus it is easy to concat the strings in the list. The method above of accepting 'anything' and just toStringing it anyway would satisfy all cases though, but it seems code-smelly to me because Elm does not have native ability to do things like that due to its highly limited type system (looking forward to that being fixed, it is on their roadmap!) and it only works because toString is very unique in the language...

[z5h]

I say we "suffer" with integers, or, if we must, move to Strings with no automatic conversions. Strings are very flexible and easy to generate and understand.

[debois]

@z5h made this comment on #elm-mdl in the elm-slack, which I thought I'd repeat here (edited slightly):

Perhaps, but either could be messier. If you are rendering a list of elements, it's more natural to use an integer index—if you really want your context to be a string, just use a hash: [hash "mylist", 1] ... [hash "mylist, n] Not super pleasant, but ok. With String indices, you have to do: ["mylist", toString 1] ... ["mylist", toString 2]

[OvermindDL1]

What I do currently, for comparison, is pass a 'pidx' (previous index) and just add on another index, and any time I have a view that goes deeper then I just add another on to it as I pass it in. So either works for me, integers as they are work fine.