Genres list

For more convenient instantiation of DbContext, let's introduce a small helper function in Db module:

let getContext() = Sql.GetDataContext()
val getContext : unit -> 'a

Full name: CDocument.getContext

Now we're ready to finally read real data in the App module:

let overview = warbler (fun _ ->
    Db.getContext() 
    |> Db.getGenres 
    |> List.map (fun g -> g.Name) 
    |> View.store 
    |> html)
val overview : obj

Full name: CDocument.overview
Multiple items
module List

from Microsoft.FSharp.Collections

--------------------
type List<'T> =
  | ( [] )
  | ( :: ) of Head: 'T * Tail: 'T list
  interface IEnumerable
  interface IEnumerable<'T>
  member GetSlice : startIndex:int option * endIndex:int option -> 'T list
  member Head : 'T
  member IsEmpty : bool
  member Item : index:int -> 'T with get
  member Length : int
  member Tail : 'T list
  static member Cons : head:'T * tail:'T list -> 'T list
  static member Empty : 'T list

Full name: Microsoft.FSharp.Collections.List<_>
val map : mapping:('T -> 'U) -> list:'T list -> 'U list

Full name: Microsoft.FSharp.Collections.List.map

        path Path.Store.overview >=> overview

overview is a WebPart that... Hold on, do I really need to explain it? The usage of pipe operator here makes the flow rather obvious - each line defines each step. The return value is passed from one function to another, starting with DbContext and ending with the WebPart. This is just a single example of how composition in functional programming makes functions look like building blocks "glued" together.

We also need to wrap the overview WebPart in a warbler. That's because our overview WebPart is in some sense static - there is no parameter for it that could influence the outcome. warbler ensures that genres will be fetched from the database whenever a new request comes. Otherwise, without the warbler in place, the genres would be fetched only at the start of the application - resulting in stale genres in case the list changes. How about the rest of WebParts?

  • browse is parametrized with the genre name - each request will result in a database query.
  • details is parametrized with the id - the same as above applies.
  • home is just fine - for the moment it's completely static and doesn't need to touch the database.

GitHub commit: ddad611ccc2555d13a9f22d4340ed1fac8a0aacc

Files changed:

  • App.fs (modified)
  • Db.fs (modified)

results matching ""

    No results matching ""