play-json icon indicating copy to clipboard operation
play-json copied to clipboard

Customization for Json macros

Open gmethvin opened this issue 9 years ago • 3 comments

(Moved from playframework/playframework#4684)

As more people start using the json macros, a lot of people seem to want to customize features slightly. We should come up with a general strategy for doing this. Ideally it should be possible to use several of these customizations at once.

Here are a few features we might want to customize:

  • [X] Property naming strategy (see playframework/playframework#2333)
  • [ ] Using default values in Reads implementation (see #4)
  • [ ] Serializing properties for getters (see #3306)
  • [ ] Renaming/ignoring specific properties

When it comes to the behavior for things like property naming and default values, it should also be easy to use the same conventions across your application.

gmethvin avatar Dec 12 '16 22:12 gmethvin

One need I have is a reader which handles JsDefined(null) and JsUndefined differently. For example:

case class Xyz(foo: Int, bar: Option[String], baz: Option[Int])
implicit val xyzReader = Json.reads[Xyz]
val json = Json.parse("""{"foo": 123, "bar": null}""")

val result = json.as[Xyz] 
//expected result is Xyz(123, Some(null), None)

Using Some(null) may not be best choice to represent a json null value, but I just use it as an example here.

To my knowlegde this is not currently possible, but I may be wrong. Could I use some of the macro infrastructure from the current play release, to write such a macro myself?

roti avatar Jul 26 '18 09:07 roti

+1 for allowing the usage of default values in Reads impls, specifically in the case for deserializing non-existent collections as an empty of that collection. E.g., would love to replace a lot of Option[Seq[_]] in our code base with just Seq[_].

Ophirr33 avatar Feb 20 '19 14:02 Ophirr33

I am also interested in doing with @roti mentioned above. This is especially important with HTTP PATCH requests, so that the user can provide intent on what they are doing ("please unset this value" vs "do not change this value"). This intent requires three states (omitted, null or a value) instead of lumping omitted/null into a single state. In other words, something like Option[Option[T]] (or some other model which can denote the third state) instead of Option[T].

I have opened a discussion about this here: https://discuss.lightbend.com/t/distinguishing-between-omitted-and-null-values/7105

solarmosaic-kflorence avatar Sep 04 '20 17:09 solarmosaic-kflorence