Button("Home", ___)

Select every answer that applies, then check.

• "home" as a string value.
  Correct. Every Button in the reading points at its route with a quoted string, e.g. Button("Increase", "index").
• home as just the name of the function.
  Correct. The reading says a route is passed "by name, not by call"; the bare function reference works too, exactly as the DrafterIssues question's own Button("Clear", clear_value) shows (no parentheses needed).
• home() with parentheses to call the function.
  Not quite. Parentheses call home immediately, embedding whatever Page it returns right now, instead of deferring execution until the button is clicked.
• home(state) with an argument to call the function with the current state.
  Not quite. This still calls home immediately, for the same reason home() does; adding the state argument doesn't delay execution until a click.
• state.home accessing the function as a field of the state.
  Not quite. Route functions are not stored on the state; home is just a name in the surrounding program.

from drafter import *

@route
def index(state: str) -> Page:
    return Page("Welcome!", Button("Next Page", "next_page"))

@route
def next_page(state: str) -> Page:
    return Page("This is the next page.", Button("Go Home", "home"))

@route
def home(state: str) -> Page:
    return Page("This is the home page.", "The end.")

start_server("")

Select every answer that applies, then check.

• Before the start_server call.
  Not quite. Defining a route with @route only registers it; nothing calls home before start_server starts serving pages.
• After the start_server call.
  Correct. Every route function, home included, only runs once the server is up and a page is requested or a button is clicked.
• When the page first loads in the browser.
  Not quite. The first page loaded calls index, not home.
• When the user clicks the "Next Page" button.
  Not quite. That button's route is "next_page", so it calls next_page, not home.
• When the user clicks the "Go Home" button.
  Correct. That button's second argument is "home", so clicking it is exactly what calls the home function.
• During the execution of the next_page function, when the Page content is defined.
  Not quite. next_page only builds a Button that names "home" as a route; it does not call home itself.

from drafter import *

@route
def index(___: ___) -> Page:
    return Page(1, Div(
        TextBox(___),
        Button(___, ___)
    ))

@route
def about(___: ___, feedback: str) -> Page:
    return Page(2, "Thank you for your input!")

start_server(0)

Select every answer that applies, then check.

• The name of the first route function must have been index.
  Not quite. Every example in the reading happens to name its entry route index, but nothing in the reading states that this exact name is required.
• The first parameter of the index function must have been named state.
  Not quite. The current state is always passed as the first parameter by position, not matched by name; only the parameters that a TextBox feeds need a specific name.
• The first parameter of the about function must have been named state.
  Not quite, for the same reason: the first parameter is always the current state by position, whatever it is named.
• The type of the first parameter of both functions must have been str.
  Not quite. This program's state is a number (Page(1, ...), start_server(0)), and other readings use int or str state just as validly.
• The first argument to the TextBox must have been "feedback".
  Correct. The reading explains that a TextBox's name is matched to a parameter in the route it submits to; here that route is about, whose extra parameter is named feedback.
• The first argument to the TextBox must have been feedback.
  Not quite. Every TextBox in the reading takes a quoted string, e.g. TextBox("guess"), not a bare name.
• The first argument to the Button must have been "Submit".
  Not quite. A button's label is just display text for the user; the reading uses "Increase", "Submit", "Try again" and others interchangeably.
• The second argument to the Button must have been about or "about".
  Correct. The button needs to link to the about route, and Drafter accepts a route either as a quoted string or as the bare function name.

from drafter import *

@route
def index(state: int) -> str:
    return Page(state, Div(
        "Current number:",
        bold(state),
        TextBox("new_value"),
        Button("Set", "set_value"),
        Button("Clear", clear_value)
    ))

@route
def set_value(state: int, new_value: int) -> Page:
    return index(new_value)

@route
def clear_value(state: int) -> Page:
    return index(0)

start_server(7)

Select one answer, then check.

• The state function should be converted from an integer to a string before it is passed to the bold function.
  Correct. Every other example in the reading writes bold(str(state)); here bold(state) passes the raw integer instead.
• The new_value parameter of the set_value function should be of type str instead of int.
  Not quite. Drafter uses a route's parameter types to convert the text a TextBox submits, so typing this parameter int is exactly how you ask for a number back.
• The clear_value and set_value functions should return a Page instead of calling the index function.
  Not quite. Reusing index to build the next page is the pattern the "Multiple Routes" example itself uses (return index(state + 1)).
• The clear_value and set_value in the index function should have parentheses so that they are function calls.
  Not quite. Adding parentheses would call them immediately instead of passing their names to Button; the bare names are correct as written.
• The state cannot initially be 7 when it is passed to the start_server function.
  Not quite. The reading's own "Drafter State" and "Buttons" examples both call start_server(7).

Which statement best describes how State works in Drafter applications?

Select one answer, then check.

• Unlike regular programs, Drafter applications do not have state.
  Not quite. The reading calls state "a central part of any program", not something unique to Drafter.
• Unlike Drafter programs, regular programs do not have state.
  Not quite. The reading says the opposite: "a central part of any program is the state", not just Drafter programs.
• State changes in Drafter by passing it as an argument to the returned Page function in the route.
  Correct. The reading states this directly: "Route functions take the current state as an argument and return a new state as part of the Page."
• State changes in Drafter by modifying global variables in the program.
  Not quite. None of the reading's examples use a global variable; the state is always a parameter and a returned value.
• State changes in Drafter by using special set_state functions.
  Not quite. No such function appears anywhere in the reading.
• State changes in Drafter by updating the value stored in the state parameter (e.g., state += 1).
  Not quite. The "Buttons" example computes a separate next_state value and returns it through Page; the original state parameter itself is never reassigned in place.