Making It Dynamic: reverse Step 2 (implement update) and 3 (static view)?

[ento]

When finishing Step 3, I was half expecting the app to work (I admit I wasn't looking at the source I was copy-pasting) -- "we already have the value we want in the model.. why not used it already?"

maybe:

• Step 1: download and compile the skeleton app
• Step 2: we already have the input, let's make a skeleton view for where the output should appear
• Step 3: let's make it do something
• Step 4: let's reflect it back to the UI

[raorao]

This was intentional in my part. My intuition is that, when learning, it's easier to learn add update logic -> change view than change view -> add update logic, since

• the former ends with the user refreshing the browser after writing view code, which seems like less of a context shift.
• the notion that model holds both current and future state can be a stumbling block. consequently, it's nice to see that code that changes the model before you actually use the change.

That said, my experience comes from teaching react/flux/backbone, where the wiring is more complicated. Things may be simpler in elm. Interested to see how students react, I could definitely be wrong.

[raorao]

tagging as a wontfix for now, but feel free to remove tag @ento

[ento]

I trust your teaching experience!

Maybe it's a matter of setting the right expectations: step 3 says "we still need to display the application's currentText back to the user!" and I guess I expected to have it implemented in this step. Also in the next paragraph: "display a paragraph tag right after our input tag, with the model's currentText as its value."

How about:

---

Thankfully, the skeleton already includes some styling for us. As a baby step, let's add code to our View.view function to display a paragraph tag with a static text right after our input tag. The resulting HTML should look like this: