A series of values that, when encoded, should be separated by
commas. Since 0.11.0.0, the .= operator is overloaded to create
either (Text, Value) or Series. You can use Series when
encoding directly to a bytestring builder as in the following
example:

For this common case of only being concerned with a single
type of JSON value, the functions withObject, withNumber, etc.
are provided. Their use is to be preferred when possible, since
they are more terse. Using withObject, we can rewrite the above instance
(assuming the same language extension and data type) as:

Instead of manually writing your FromJSON instance, there are two options
to do it automatically:

Data.Aeson.TH provides Template Haskell functions which will derive an
instance at compile time. The generated instance is optimized for your type
so it will probably be more efficient than the following option.

The compiler can provide a default generic implementation for
parseJSON.

To use the second, simply add a deriving Generic clause to your
datatype and declare a FromJSON instance for your datatype without giving
a definition for parseJSON.

The first space may instead be a T, and the second space is
optional. The Z represents UTC. The Z may be replaced with a
time zone offset of the form +0000 or -08:00, where the first
two digits are hours, the : is optional and the second two digits
(also optional) are minutes.

WARNING: Only parse fixed-precision numbers from trusted input
since an attacker could easily fill up the memory of the target
system by specifying a scientific number with a big exponent like
1e1000000000.

Instead of manually writing your ToJSON instance, there are two options
to do it automatically:

Data.Aeson.TH provides Template Haskell functions which will derive an
instance at compile time. The generated instance is optimized for your type
so it will probably be more efficient than the following option.

To use the second, simply add a deriving Generic clause to your
datatype and declare a ToJSON instance. If you require nothing other than
defaultOptions, it is sufficient to write (and this is the only
alternative where the default toJSON implementation is sufficient):

Previous versions of this library only had the toJSON method. Adding
toEncoding had to reasons:

toEncoding is more efficient for the common case that the output of
toJSON is directly serialized to a ByteString.
Further, expressing either method in terms of the other would be
non-optimal.

The choice of defaults allows a smooth transition for existing users:
Existing instances that do not define toEncoding still
compile and have the correct semantics. This is ensured by making
the default implementation of toEncoding use toJSON. This produces
correct results, but since it performs an intermediate conversion to a
Value, it will be less efficient than directly emitting an Encoding.
(this also means that specifying nothing more than
instance ToJSON Coord would be sufficient as a generically decoding
instance, but there probably exists no good reason to not specify
toEncoding in new instances.)

The default implementation of this method creates an
intermediate Value using toJSON. This provides
source-level compatibility for people upgrading from older
versions of this library, but obviously offers no performance
advantage.

To benefit from direct encoding, you must provide an
implementation for this method. The easiest way to do so is by
having your types implement Generic using the DeriveGeneric
extension, and then have GHC generate a method body as follows.

Keys for maps

Typeclass for types that can be used as the key of a map-like container
(like Map or HashMap). For example, since Text has a ToJSONKey
instance and Char has a ToJSON instance, we can encode a value of
type MapTextChar:

JSON documents only accept strings as object keys. For any type
from base that has a natural textual representation, it can be
expected that its ToJSONKey instance will choose that representation.

For data types that lack a natural textual representation, an alternative
is provided. The map-like container is represented as a JSON array
instead of a JSON object. Each value in the array is an array with
exactly two values. The first is the key and the second is the value.

For example, values of type '[Text]' cannot be encoded to a
string, so a Map with keys of type '[Text]' is encoded as follows:

The default implementation of ToJSONKey chooses this method of
encoding a key, using the ToJSON instance of the type.

To use your own data type as the key in a map, all that is needed
is to write a ToJSONKey (and possibly a FromJSONKey) instance
for it. If the type cannot be trivially converted to and from Text,
it is recommended that ToJSONKeyValue is used. Since the default
implementations of the typeclass methods can build this from a
ToJSON instance, there is nothing that needs to be written:

It is possible to get the ToJSONKey instance for free as we did
with Foo. However, in this case, we have a natural way to go to
and from Text that does not require any escape sequences. So, in
this example, ToJSONKeyText will be used instead of ToJSONKeyValue.
The Show instance can be used to help write ToJSONKey:

The performance of the above instance can be improved by
not using String as an intermediate step when converting to
Text. One option for improving performance would be to use
template haskell machinery from the text-show package. However,
even with the approach, the Encoding (a wrapper around a bytestring
builder) is generated by encoding the Text to a ByteString,
an intermediate step that could be avoided. The fastest possible
implementation would be:

This works because GHC can lift the encoded values out of the case
statements, which means that they are only evaluated once. This
approach should only be used when there is a serious need to
maximize performance.

This is similar in spirit to the showsList method of Show.
It makes it possible to give String keys special treatment
without using OverlappingInstances. End users should always
be able to use the default implementation of this method.

This is similar in spirit to the showsList method of Show.
It makes it possible to give String keys special treatment
without using OverlappingInstances. End users should always
be able to use the default implementation of this method.

Read the docs for ToJSONKey first. This class is a conversion
in the opposite direction. If you have a newtype wrapper around Text,
the recommended way to define instances is with generalized newtype deriving:

This is similar in spirit to the readList method of Read.
It makes it possible to give String keys special treatment
without using OverlappingInstances. End users should always
be able to use the default implementation of this method.

This is similar in spirit to the readList method of Read.
It makes it possible to give String keys special treatment
without using OverlappingInstances. End users should always
be able to use the default implementation of this method.

This type is related to ToJSONKeyFunction. If FromJSONKeyValue is used in the
FromJSONKey instance, then ToJSONKeyValue should be used in the ToJSONKey
instance. The other three data constructors for this type all correspond to
ToJSONKeyText. Strictly speaking, FromJSONKeyTextParser is more powerful than
FromJSONKeyText, which is in turn more powerful than FromJSONKeyCoerce.
For performance reasons, these exist as three options instead of one.

Construct FromJSONKeyFunction for types coercible from Text. This
conversion is still unsafe, as Hashable and Eq instances of a should be
compatible with Text i.e. hash values should be equal for wrapped values as well.
This property will always be maintained if the Hashable and Eq instances
are derived with generalized newtype deriving.
compatible with Text i.e. hash values be equal for wrapped values as well.

Liftings to unary and binary type constructors

Instead of manually writing your FromJSON1 instance, there are two options
to do it automatically:

Data.Aeson.TH provides Template Haskell functions which will derive an
instance at compile time. The generated instance is optimized for your type
so it will probably be more efficient than the following option.

The compiler can provide a default generic implementation for
liftParseJSON.

To use the second, simply add a deriving Generic1 clause to your
datatype and declare a FromJSON1 instance for your datatype without giving
a definition for liftParseJSON.

If the default implementation doesn't give exactly the results you want,
you can customize the generic decoding with only a tiny amount of
effort, using genericLiftParseJSON with your preferred Options:

Instead of manually writing your ToJSON1 instance, there are two options
to do it automatically:

Data.Aeson.TH provides Template Haskell functions which will derive an
instance at compile time. The generated instance is optimized for your type
so it will probably be more efficient than the following option.

The compiler can provide a default generic implementation for
toJSON1.

If the default implementation doesn't give exactly the results you want,
you can customize the generic encoding with only a tiny amount of
effort, using genericLiftToJSON and genericLiftToEncoding with
your preferred Options:

Helper for use in combination with .:? to provide default
values for optional JSON object fields.

This combinator is most useful if the key and value can be absent
from an object without affecting its validity and we know a default
value to assign in that case. If the key and value are mandatory,
use .: instead.

A constructor will be encoded to an object with a field
tagFieldName which specifies the constructor tag (modified by
the constructorTagModifier). If the constructor is a record
the encoded record fields will be unpacked into this object. So
make sure that your record doesn't have a field with the same
label as the tagFieldName. Otherwise the tag gets overwritten
by the encoded value of that field! If the constructor is not a
record the encoded constructor contents will be stored under
the contentsFieldName field.

Constructor names won't be encoded. Instead only the contents of the
constructor will be encoded as if the type had a single constructor. JSON
encodings have to be disjoint for decoding to work properly.

When decoding, constructors are tried in the order of definition. If some
encodings overlap, the first one defined will succeed.

Note: Nullary constructors are encoded as strings (using
constructorTagModifier). Having a nullary constructor alongside a
single field constructor that encodes to a string leads to ambiguity.

Note: Only the last error is kept when decoding, so in the case of
malformed JSON, only an error for the last constructor will be reported.

A constructor will be encoded to a 2-element array where the
first element is the tag of the constructor (modified by the
constructorTagModifier) and the second element the encoded
contents of the constructor.