JavaScript-free Web Development with WebAssembly, Bolero, and F#

type Model =
    {
        questions: Question list
        choices: string list
        answerState: AnswerState
    }

and Question =
    {
        text: string
        correctChoice: string
        incorrectChoices: string list
    }

and AnswerState =
    | Unanswered
    | AnsweredCorrectly
    | AnsweredIncorrectly

The idea here is that the list of questions is initialized at startup, and the current question is always the one at the head of the list. The list of current choices is stored separately so they can be shuffled.

Although this model does a good job of representing my state, there are still opportunities to make impossible states unrepresentable. I know this was a major theme with Elm, and it is well within reach of functional programming in general. But compared to all the checks that would be necessary to even begin to accomplish the same thing in JavaScript, we’re already way ahead!

With the model in place, the next thing I need is a type to represent the available update operations, and a function to process them.

Update

type Message =
    | ScrambleChoices
    | NextQuestion
    | Answer of string

let update message model =
    match message with
    | ScrambleChoices ->
        let question = List.tryHead model.questions
        let choices =
            match question with
            | None -> []
            | Some question ->
                (question.correctChoice :: question.incorrectChoices)
                |> shuffleList
        { model with choices = choices }, Cmd.none

    | NextQuestion ->
        { model with questions = List.tail model.questions
                     answerState = Unanswered }, Cmd.ofMsg ScrambleChoices

    | Answer choice ->
        let question = List.head model.questions
        { model with answerState =
                         if choice = question.correctChoice
                         then AnsweredCorrectly
                         else AnsweredIncorrectly }, Cmd.none

It might seem like there’s a lot going on here, but the same pattern is repeated for each message handler: Figure out what to change in the model, and then return an updated model. One other interesting thing is that the return type is actually a tuple of model and a follow-up command. I’ve used this to immediately scramble the answers when advancing to the next question.

Finally, I have enough to render the view.

View

Bolero has a couple of options for rendering views. One approach is to use HTML templates, as you might expect. However, they’re extremely limited. You can insert so-called holes for simple variable substitution, but that’s it. This is really disappointing, because the templating engine is hooked up using an F# type provider. I could imagine it providing some neat design-time template validation (in fact, if you try to assign to a non-existent template hole, you’ll get a red squiggly).

I understand that there may be a desire to avoid putting everything and the kitchen sink into templates (that’s how you end up with PHP), but a little more functionality would go a long way here. Some basics like conditionals and loops would allow more of the template to be specified in HTML. I wouldn’t go so far as to enable F# code within the template, though; logic and presentation are best kept separate.

So I started out writing my view as a template, but this is as far as I could get:

<div class="quiz">
  <div>${QuestionText}</div>
  <ol class="choices">
    ${Choices}
  </ol>
  <div class="feedback">
    ${Feedback}
  </div>
  <div>
    <button class="next-question" onclick="${NextQuestion}">Next Question</button>
  </div>
</div>

As it is, anything other than simple variable substition must use the alternative, which is HTML-in-F#. It looks like this (since I ended up using a template for the overall structure, and this is providing values for the template holes, it may not be the best example. Focus on the block provided to Choices in the middle):

let view model dispatch =
    Main()
        // Inputs
        .NextQuestion(fun _ -> dispatch NextQuestion)
        // Outputs
        .QuestionText(
            cond (List.tryHead model.questions) <| function
            | None -> text "You have completed the quiz!"
            | Some question -> text question.text)
        .Choices(
            forEach model.choices <| fun choice ->
                li [] [
                    cond model.answerState <| function
                    | Unanswered ->
                        button [
                            attr.``class`` "choice-btn"
                            on.click (fun _ -> dispatch (Answer choice))
                            ] [text choice]
                    | _ -> text choice
                ])
        .Feedback(
            cond model.answerState <| function
            | Unanswered -> empty
            | AnsweredCorrectly -> text "Correct!"
            | AnsweredIncorrectly -> text "Wrong!"
        )
        .Elt()

It’s awkward–essentially building a DOM tree in F# syntax, using special-purpose helper functions, instead of using the domain-specific language of HTML. And that attr.``class``…yikes. Building up a DOM within program code is not a new concept, but it would take some getting used to.

The main advantage of this approach is that you get all of the type safety of F# directly in your UI specification. That’s actually pretty awesome. But it’s really hard to imagine developing a sizable application like this and keeping it maintainable. It would take some practice to develop a formatting scheme that is concise and readable, yet flexible enough for refactoring.

The Future

Despite the rough edges (this stuff is still pretty new), I think it’s exciting to be able to do front-end web development in F#. I’m looking forward to putting the full stack together and having F# all the way down!