Add nested decoding

[dtadic]

Hi!

This allows decoding values from nested containers like this:

{
    "a": {
        "b": {
            "c": "hello world"
        }
    }
}

with:

decoder.decode(["a","b","c"])

I thought of adding a dot syntax (eg: decoder.decodeNested("a.b.c"), but found it unnecessary.

I'm not sure if CodextendedDecodingError works with Codextended's philosophy...

It also may be good to add encoding and update readme.

[bofeizhu]

How about decoder.decode(key: CodingKey)? Since we already need to use a set of keys as parameters. I'd would be better to just send in an enum.

[dtadic]

@bofeizhu do you mean array of enums? Because that’s also implemented in this pull request 🙂

I would leave both in since the library already implements string and enum in it’s API

[rainypixels]

Hi @JohnSundell — Any chance you'll be merging this (or your own implementation of nested keypath decoding) into master sometime soon? That was one of my favorite features of Unbox because it allowed our API to adhere to REST but didn't require creating unnecessary container models. It feels like this one addition would make Codextended feature-complete as a companion to the native Codable protocol. Thanks for a great little power-packed framework!

[rainypixels]

@dtadic FWIW, I do prefer the dot syntax as it's the canonical way to namespace in most languages, and it just feels more readable. Your example of decoder.decodeNested("a.b.c") feels more Codextendedy, too. Or you could probably just overload decoder.decode("a.b.c") to handle period-delimited keys. Great pull request nonetheless!

[iwill]

decoder.decodeNested("a.b.c"), but found it unnecessary.

decoder.decodeNested("a.b.c") is better, because decoder.decode(["user_id", "uid", "id"]) can be used for single property with multiple alternative keys.

[iwill]

@dtadic Is nested Encoding necessary?