On how well Entries describes my problem
@IloSophiep and @Sebastian my thinking here was to ping the server for a json response and instead of a Maybe it’d be a potential NoEntries — but I meant that even the [] empty list might not be there. I agree that it doesn’t bring much to the table in other instances.
@Sebastian Could you give me an example json file that’d work alongside your Collection type? When would you use a collection over simpler json data?
Start with the simplest thing first, until you find that you need a custom type to convey useful information.
Sounds like good advice.
@IloSophiep I’ve watched the video where @rtfeldman goes over the school visit example, so I understand this. So, when you’re using more normalised SQL type data it could be useful to avoid error. I have a situation where I’d probably want to use tags (which are often many-to-many relationship) so perhaps that’s a good use case?
I have no idea how you’d structure routing and search capabilities for those tags though. I’m not that far ahead with Elm!
@dta That Id Int sounds like a good call, or I suppose you could just use a uuid? Or would that still not solve the problem? Would you still create different ID types with a unique id?
Json.Encode
I think I understand this now, so you simply need to create a function that extracts the data you need and converts it into a List Tuple of key/value pairs.
An example of nested json data
See this demo for:
- A
jsonobject that …- Contains another object …
- That in turn contains a
List Int
Do any of you have examples of nested json data that’s been created by Json.Encode? For example, a json object that contains another object that contains a List String. I can’t picture in my head how that might look!
simpleData : Encode.Value
simpleData =
object
[ ("name", string "Tom")
, ("list", (list int [1, 2, 3]))
]
-- nestedObject
encode 0 object
[ ("Collection", int 1)
, ("Nested", simpleObject)
]
I solved my own question 
The first Entry (or [])
@wolfadex Hmm. So at the moment I’m not handling the eventuality for just one entry, and I’m duplicating work for NoEntries and [] (although see above for what I was trying to do). I hadn’t thought of it that way.
Entries Entry (List Entry)
Would that mean I’d have to unwrap it twice? One for I was a little confused about the difference (I thought at first it was a recursive type!); it seems similar to Entries and one for Entry to get at that List Entry? Or is there a shorthand?Random.uniform?
Entries (Entry 1 "one") [Entry 2 "two", Entry 3 "three"]
The more I look at it a List Entry within a Collection might make more sense. And the more I see complication arise, like hacking json to store custom types, the more I want to go back to as simple as possible! I feel unless there’s a graceful way to do this (like what Evan might have in store for SQL) it’s may be wise to store as simple json, not as types.
I like the idea of codecs, and can sort of see how one might work but I’d need a few concrete tutorials to feel comfortable turning a bunch of custom types into a structured (nested) json file, or updating one with put or patch.
I find as a program grows and things become more connected, nested, and complected, my brain sort of goes meltdown and I can’t fit the bits together in my head 
How many Maybes is too many?
So this brings me to my final thought, in that I guess in an ideal world you’d want to have as much control as possible over the json. In many forms there’ll be a lot of optional field types which would result in potentially a lot of Maybes. @Sebastian says to not store these as default empty values and (I think) not Json.Encode them at all and show empty view sections where appropriate.
It seems you want one main way to show if a json response comes back empty, and then Maybe.withDefault as appropriate for the individual object values and json elements in your view.
Are there any other tips to reduce the amount of Maybes? For data points that are dynamic or missing, that we haven’t already covered here?