Pass parent to field coders

[alfonsogarciacaro]

Sorry, not sure which branch is supposed to be the target for PRs now, so I'm using develop :) I'm playing with the field custom decoders doing migrations in JSON documents and I realized it would be helpful to have access to the parent from the field coder in case we need to access another field and make some transformation. Example:

Extra.empty
|> Extra.withCustomFieldDecoder fieldName (fun _path parent value ->
    match value with
    | Some _ -> UseAutoDecoder
    | None ->
        let anotherFieldName = Casing.convert caseStrategy "AnotherField"
        let anotherFieldDecoder = Decode.field anotherFieldName Decode.string
        match anotherFieldDecoder "$" parent with
        | Error er -> UseError er
        | Ok v -> someTransformation v |> UseOk)

Note this PR also exposes the Casing module so we can convert the field names manually. It seems the field custom coders feature is not yet released so this shouldn't break anything :)

[MangelMaxime]

You are right, I think I didn't release the custom coders feature because it is a big change and I don't understand it yet. And problem is that I will need to be able to maintain it and explain it to people.

I probably first thought that I would quickly write vNext which is a major rewrite of Thoth.Json and include in it. But since then, I am still not sure if I want to include the custom coders feature.

It is no surprise that I never was a big fan of the Auto module because it felt like a hacks/full of quirks. And this feature does look really confusing for me and kind of hacking around a problem.

It is really hard to read at least for me. Probably because the custom coders feature introduces a lot of indirection in the code in opposition with explicit code.

I really want to have vNext in a stable state (aka ready to release). And then, go back to the custom coders feature and taking the time to try to understand it correctly etc.

For now, we can keep this PR here as a reminder. So I know, I need to take a look back at this feature.

[alfonsogarciacaro]

Thanks a lot for the reply @MangelMaxime! I have the feeling that most people using Thoth.Json rely on the Auto module though I may be wrong 😸 In any case, I totally understand that maintaining a project becomes harder when there's part of the code that is not very convincing for oneself. If you're working on a restructure of Thoth.Json, maybe it would be a good opportunity to move Auto to its own package (I think it doesn't need any internal stuff) and let someone else maintain it so you can focus on the "manual" coders.

[MangelMaxime]

I have the feeling that most people using Thoth.Json rely on the Auto module though I may be wrong

"Unfortunately" ^^, yes.

If you're working on a restructure of Thoth.Json, maybe it would be a good opportunity to move Auto to its own package (I think it doesn't need any internal stuff) and let someone else maintain it so you can focus on the "manual" coders.

This is indeed something that I am considering.