Fill in wiring about applied-scala HOT 3 CLOSED

What endpoint is most appropriate to not fill in?

I think GET movie is appropriate to not fill in. It's the first endpoint the students work on.

How can we indicate that we have already filled in the wiring, and point curious students in the right direction?

I think updating the README.md that's in each urls package to reflect this is good. I plan to point students to the README.md file often and make sure they know that's what they should refer to for directions.

Additional scope

Can we include the use of OptionalEnrichedMatcher in AppRoutes as part of this too? So time can be spent on explaining it, rather than having students copy it down. It was initially intended to just show that http4s has useful features like query parameter matching, and I did not expect it to be something that people would remember how to use by the end of the course without referring to the docs.

case GET -> Root / "movies" / LongVar(id) :? OptionalEnrichedMatcher(maybeEnriched) =>
      if (maybeEnriched.contains(true)) fetchEnrichedMovieHandler(id) else fetchMovieHandler(id)

from applied-scala.

I think GET movie is appropriate to not fill in. It's the first endpoint the students work on.

👍 agree

How can we indicate that we have already filled in the wiring, and point curious students in the right direction?

I wonder if we can have two files, one filled out we use in course, and one not filled out that people can do themselves? That also might be a nice pattern to be like "here's some extra work to test your knowledge if you want"

But yes also READMEs should be useful and up to date

from applied-scala.

I updated the comments and the README to communicate these things accurately

from applied-scala.