Add a big comment to part10
This commit is contained in:
@@ -213,6 +213,28 @@ onChange toMsg =
|
|||||||
on "change" (Json.Decode.map toMsg Html.Events.targetValue)
|
on "change" (Json.Decode.map toMsg Html.Events.targetValue)
|
||||||
|
|
||||||
|
|
||||||
|
{-| NOTE: The following is not part of the exercise, but is food for thought if
|
||||||
|
you have extra time.
|
||||||
|
|
||||||
|
There are several opportunities to improve this getQueryString implementation.
|
||||||
|
A nice refactor of this would not change the type annotation! It would still be:
|
||||||
|
|
||||||
|
getQueryString : Model -> String
|
||||||
|
|
||||||
|
Try identifying patterns and writing helper functions which are responsible for
|
||||||
|
handling those patterns. Then have this function call them. Things to consider:
|
||||||
|
|
||||||
|
* There's pattern of adding "+foo:bar" - could we write a helper function for this?
|
||||||
|
* In one case, if the "bar" in "+foo:bar" is empty, we want to return "" instead
|
||||||
|
of "+foo:" - is this always true? Should our helper function always do that?
|
||||||
|
* We also join query parameters together with "=" and "&" a lot. Can we give
|
||||||
|
that pattern a similar treatment? Should we also take "?" into account?
|
||||||
|
|
||||||
|
If you have time, give this refactor a shot and see how it turns out!
|
||||||
|
|
||||||
|
Writing something out the long way like this, and then refactoring to something
|
||||||
|
nicer, is generally the preferred way to go about building things in Elm.
|
||||||
|
-}
|
||||||
getQueryString : Model -> String
|
getQueryString : Model -> String
|
||||||
getQueryString model =
|
getQueryString model =
|
||||||
-- See https://developer.github.com/v3/search/#example for how to customize!
|
-- See https://developer.github.com/v3/search/#example for how to customize!
|
||||||
|
|||||||
Reference in New Issue
Block a user