Add JSONResponse class

[prryplatypus]

Adds a new JSONResponse class that's returned for JSON responses which introduces some new JSON utilities, such as accessing the raw JSON body and the ability to modify it directly.

[codecov]

Codecov Report

Base: 87.825% // Head: 87.853% // Increases project coverage by +0.027% 🎉

Coverage data is based on head (a76c7ca) compared to base (d404116).
Patch coverage: 84.000% of modified lines in pull request are covered.

❗ Current head a76c7ca differs from pull request most recent head 13562d8. Consider uploading reports for the commit 13562d8 to get more accurate results

Additional details and impacted files

@@              Coverage Diff              @@
##              main     #2569       +/-   ##
=============================================
+ Coverage   87.825%   87.853%   +0.027%     
=============================================
  Files           71        73        +2     
  Lines         5380      5450       +70     
  Branches       897       903        +6     
=============================================
+ Hits          4725      4788       +63     
- Misses         474       477        +3     
- Partials       181       185        +4     

Impacted Files	Coverage Δ
sanic/response/types.py	83.333% <83.333%> (ø)
sanic/response/__init__.py	100.000% <100.000%> (ø)
sanic/response/convenience.py	96.396% <100.000%> (ø)
sanic/server/websockets/impl.py	38.479% <0.000%> (+0.691%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[prryplatypus]

Just thought about this... what if someone does response.raw_body.update(...)? That wouldn't work as expected. Any suggestions?

EDIT: Only solution I've been able to come up with for this is making .body a read-only property that would just .dumps the raw body when accessed. However, this would probably be a breaking change. What are your thoughts @ahopkins?

[prryplatypus]

Alright, I've approached this differently. Main difference is that now the body doesn't get set when the raw_body is set, and instead it is generated "on-the-fly" when accessing the attribute.

This leaves us with the following outcome:

1. It is backwards-compatible. You can set body at any point throughout the response's lifetime.
2. The new raw_body property can be set at any point throughout the response's lifetime (as long as the body property has not been set manually).
3. Common JSON object methods can be used directly on the raw_body without us having to implement any of the methods, and the body output will remain consistent. For example resp.raw_body.update(...) or resp.raw_body.append(...).

Only "drawback" is that dumps / dumps_kwargs can't be changed once the response has already been created, but this shouldn't be an issue, as that's the way it currently works.

Let me know your thoughts @ahopkins and if you're happy with it I'll write the tests for it.

[prryplatypus]

Another potentially breaking change: Currently a TypeError is raised from within the constructor if a type can't be serialized by the json encoder. With this change mentioned above it would only be raised when calling resp.body. As a workaround we can just add self.body somewhere in the constructor, but this is not optimal as it would make every response be serialized twice.

However, we could potentially leave this in only for a deprecation period and then remove it (not a fan of it however). Thoughts welcome.

[ahopkins]

Remind me... where did we settle on the API for this?

[prryplatypus]

You suggested doing a json.loads if the body was set manually, but I disagreed because it feels like a cross of domains. Therefore, I think we were both on the same page with documenting that raw_body should not be mutated at all, unless after mutating it you called .set_json(raw_body) or did resp.raw_body = resp.raw_body (which would trigger a dumps call with the new raw body).

That said, we could potentially add the "common methods" that you mentioned previously, such as append or update, if so you wish.

[prryplatypus]

@ahopkins API now should be as agreed 😎

[ahopkins]

The json convenience method needs its return type updated.

[prryplatypus]

The json convenience method needs its return type updated.

It is updated, I believe? https://github.com/sanic-org/sanic/pull/2569/files#diff-9e98d5a6f92def2f06f426094980026882610a5e8d8215b9b291b58620f0f15fR50-R57

[ahopkins]

It is updated, I believe?

[prryplatypus]

Ahh the typehint! Done.