GHC 8.0 and later come with the `DeriveLift` extension for deriving
instances of `Language.Haskell.TH.Syntax.Lift`. `yesod-core` supports
GHC 8.2 and up, so it is able to make use of this. Not only does
`DeriveLift` make for much shorter code, but it also fixes warnings
that you get when compiling `yesod-core` with GHC 8.10 or later:
```
[20 of 31] Compiling Yesod.Routes.TH.Types ( src/Yesod/Routes/TH/Types.hs, interpreted )
src/Yesod/Routes/TH/Types.hs:34:10: warning: [-Wmissing-methods]
• No explicit implementation for
‘liftTyped’
• In the instance declaration for ‘Lift (ResourceTree t)’
|
34 | instance Lift t => Lift (ResourceTree t) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
src/Yesod/Routes/TH/Types.hs:49:10: warning: [-Wmissing-methods]
• No explicit implementation for
‘liftTyped’
• In the instance declaration for ‘Lift (Resource t)’
|
49 | instance Lift t => Lift (Resource t) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
src/Yesod/Routes/TH/Types.hs:59:10: warning: [-Wmissing-methods]
• No explicit implementation for
‘liftTyped’
• In the instance declaration for ‘Lift (Piece t)’
|
59 | instance Lift t => Lift (Piece t) where
| ^^^^^^^^^^^^^^^^^^^^^^^^
src/Yesod/Routes/TH/Types.hs:78:10: warning: [-Wmissing-methods]
• No explicit implementation for
‘liftTyped’
• In the instance declaration for ‘Lift (Dispatch t)’
|
78 | instance Lift t => Lift (Dispatch t) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This is because `DeriveLift` fills in implementations of `liftTyped`,
a method that was introduced to `Lift` in `template-haskell-2.16.0.0`
(bundled with GHC 8.10).
* Add functions for setting description and OG meta
It's common that a website author will want to add a specific
description and Open Graph image to a given page in their website. These
functions are simple conveniences to add these meta tags to the document
head.
I decided against simply adding all possible meta tags, because not all
of them are useful, and even in the case of Open Graph tags, many of
them should be set only once and they should use the same value for the
entire website. In those cases, it's probably better for the website
author to add those tags in their layout template.
Closes https://github.com/yesodweb/yesod/issues/1659
This function checks that a response body is JSON, and parses it into a Haskell value. Having something like this function is pretty essential to using Yesod as a JSON API server, so I think it's a good addition. You can use it to parse a Haskell record directly (usually by adding FromJSON classes to your response types), or parse a Value and pull out individual fields, maybe using something like `aeson-lens` (though probably a testing-specific library would be better).
I debated over these things:
1. The name. I was thinking of something like [assert/require/decode/parse]JSON[Response/Body]. I ultimately went with requireJSONResponse:
- decode/parse sound like the aeson functions that return Either or Maybe, and I wanted this function to throw an error if it failed
- I'm open to using `assertJSONResponse`—it matches the other functions (`assertEq`) better—but I think it reads less like English.
- I chose Response over Body because (a) It also checks the content-type header, which is not in the body (b) "Body" felt slightly in-the-weeds of HTTP; I think "response" is more approachable.
2. Should it require the JSON content type? You can definitely have a server that returns JSON without JSON content types, but I think that's a such a bad idea, it's more likely requiring it helps people if they accidentally don't add the header.
3. Should it take a String parameter to add to the error message? This would match `assertEq`, but other functions like `statusIs` don't take a message. Ultimately I went without it, because the messages felt like I was repeating myself: `(comment :: Comment) <- requireJSONResponse "the response has a comment"`
