[bug] Custom decoder for Optional field always evaluated

[rpmcginty]

Problem

There is inconsistent behavior in how a custom decoder is used depending on whether the field of the custom decoder has Optional type.

For optional fields which can be None, you are supposed to use the Optional[...] type. However, when doing so, it seems that custom decoders are always evaluated.

It should be noted that fields where the default value is None but no Optional[...] typing is present, a custom decoder will only be used if a non-None value is provided.

Example

Given the following nested dataclass:

from dataclasses import dataclass

@dataclass
class A:
    str_value: str

and top-level dataclass X with three fields:

1. field a1 with default None / custom decoder
2. field a2 with Optional typing / default None / custom decoder
3. field a3 with Optional typing / default None

from dataclasses import dataclass, field
from dataclasses_json import DataClassJsonMixin, config

@dataclass
class X(DataClassJsonMixin):
    # This works as expected
    a1: A = field(default=None, metadata=config(decoder=A))
    # This does not work as expected
    a2: Optional[A] = field(default=None, metadata=config(decoder=A))
    # This works as expected
    a3: Optional[A] = field(default=None)

If I were to deserialize an empty dictionary I would expect to receive to nonetype values for a1 and a2, however this is the result:

>>> x = X.from_dict({})
>>> x
# expected `X(a1=None, a2=None, a3=None)`
X(a1=None, a2=A(s=None), a3=None)

[rpmcginty]

#354

[TristanSpeakEasy]

Optional is also an issue with a custom encoder, with it being called when the optional field isn't set

[patricksnape]

I also agree that I would consider this to be a bug since it generates incorrect objects according to the user provided types - we are ignoring None values in our parsing which is surely not a consistent API.