Hi Spencer, In an Elm app I am building I ran into similar challenges.
The principles which work well for me in model design:
- Flat is better than nested (for relational stuff, such as your courses)
- One source of truth = a normalized model without duplication of data
- Connect data for viewing in your views.
So I would "normalize" your model as below:
- Put sessions in your model at top level: you want to access the
sessions directly
- For parent-child-like relations (like course-session), only include
the parent Id in the child.
E.g. Course type does not need a list of sessions: this info is stored in
the sessions (which also contain course Id).
In your views, retrieve from your model the info that you need, e.g.
getting the names of the tutors.
I would personally not qualify a UserId of someone else as something that
the user is not supposed to see: it is a data Id for connecting 2 records.
Still, if you really want the user not to see Id of who is enrolled, you
can include that in your model as a Registration type.
The real trick is probably to selectively populate this model in
client-server communication: make your API only provide those Users,
Sessions, Courses to which the particular user has access.
type alias Model =
{ me : Maybe UserId
, users : Dict UserId User
, courses : Dict CourseId Course
, sessions : Dict SessionId Session
}
type alias User =
{ name : String
, id : UserId
, role : UserRole
}
type UserRole =
Admin
| Faculty
| Student
type alias Course =
{ id : CourseId
, name : String
, instructor : UserId
}
type alias Session =
{ id : SessionId
, course : CourseId
, time : Date
, tutor : UserId
, location : String
, registration : Registration
}
type Registration =
Available
| Registered
| RegisteredBy UserId
--
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.
