generic-aeson: Derivation of Aeson instances using GHC generics.
Modules
[Index] [Quick Jump]
Downloads
- generic-aeson-0.2.0.14.tar.gz [browse] (Cabal source package)
- Package description (as included in the package)
Maintainer's Corner
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 && <2.2), attoparsec (>=0.11 && <0.15), base (>=4.4 && <4.17), generic-deriving (>=1.6 && <1.15), ghc-prim, mtl (>=2.0 && <2.4), tagged (>=0.2 && <0.9), text (>=0.11 && <2.1), unordered-containers (>=0.2 && <0.3), vector (>=0.10 && <0.13) [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 AlejandroSerrano at 2022-06-17T12:06:41Z |
| Distributions | |
| Reverse Dependencies | 7 direct, 6 indirect [details] |
| Downloads | 21311 total (62 in the last 30 days) |
| Rating | (no votes yet) [estimated by Bayesian average] |
| Your Rating | |
| Status | Docs uploaded by user Build status unknown [no reports yet] |
Readme for generic-aeson-0.2.0.14
[back to package description]generic-aeson
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.
-
Maybevalues 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.