generic-aeson: Derivation of Aeson instances using GHC generics.

[ bsd3, data, library ] [ Propose Tags ]

Derivation of Aeson instances using GHC generics.


[Skip to Readme]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

Versions [RSS] 0.1, 0.1.0.1, 0.1.0.2, 0.1.0.3, 0.1.1, 0.1.1.1, 0.2.0.0, 0.2.0.1, 0.2.0.2, 0.2.0.3, 0.2.0.4, 0.2.0.5, 0.2.0.6, 0.2.0.7, 0.2.0.8, 0.2.0.9, 0.2.0.10, 0.2.0.11, 0.2.0.12, 0.2.0.13, 0.2.0.14
Change log CHANGELOG.md
Dependencies aeson (>=0.6 && <0.10), attoparsec (>=0.11 && <0.14), base (>=4.4 && <4.9), generic-deriving (>=1.6 && <1.8), ghc-prim, mtl (>=2.0 && <2.3), tagged (>=0.2 && <0.9), text (>=0.11 && <1.3), unordered-containers (>=0.2 && <0.3), vector (>=0.10 && <0.11) [details]
License BSD-3-Clause
Author Silk
Maintainer code@silk.co
Category Data
Source repo head: git clone https://github.com/silkapp/generic-aeson.git
Uploaded by AdamBergmark at 2015-05-25T21:26:50Z
Distributions
Reverse Dependencies 7 direct, 6 indirect [details]
Downloads 20868 total (56 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2015-05-26 [all 1 reports]

Readme for generic-aeson-0.2.0.6

[back to package description]

generic-aeson

Build Status

The structure of the generated JSON is meant to be close to idiomatic JSON. This means:

  • Enumerations (data types containing constructors without fields) are converted to JSON strings.

  • Record fields become JSON keys.

  • Data types with one unlabeled field convert to just that field.

  • Data types with multiple unlabeled fields become arrays.

  • Multiple constructors are represented by keys.

  • Maybe values are either an absent key, or the value.

  • Leading and trailing underscores are removed from constructor names and record fields

See tests/Main.hs in json-schema for more examples.

How does generic-aeson compare to the TH/Generics already present in aeson?

generic-aeson contains more special cases for creating more concise and idiomatic json. If you're working with the JSON representation directly generic-aeson should feel more natural.

Will the generated format ever change?

Changing the format would incur a breaking change to every API that uses generic-aeson so we must keep it intact.

If we find a bug where the fix changes the format we need to create a new package or version the generation code.

Schemas

json-schema has generic derivation of schemas that match the generic-aeson format.