Split Json decoder complexity or not?

[ggerico]

In the back-end for a single resource, I have multiple database join statements (relationships).
Then in the front-end , this single resource is fetched sometimes with one database relationship sometimes with more.

from a Json decoder point of view, the Json.Decode.maybe looks good, but it means more case statement to extract data for the view and more complexity, but after all there is only one decoder.

In the other hand, you could make different decoders for each case, which means less complexity, but more decoders too, you might gather these decoders with Json.Decode.oneOf.

Ultimately, according to your choice, you will have to keep neat decoders and data types.
Multiple decoders mean using custom type when a single decoder means a single more complex data type.

I would go for having multiple decoders and using custom type, then after every thing works fine, I would try to refactor into a single decoder with a single type. But I just want to write robust code not to become a smart guy.

Which way should I go along with?
Tks

[gampleman]

In general, it’s better to approach this problem from the other end. For your application, what does the ideal data structure for your data look like? What representation will make the rest of your application the easiest to reason about and the most robust (see Making Impossible States Impossible). Then think of the decoders you need to build as a way to instantiate those data structures.

Sometimes that can be built as a single complex decoder (I have built decoders that are very complex and it works) or as a simpler decoder + transformation functions that take the intermediate decoded result and turn it into application data.

[ggerico]

Tks, I watched “make data structures” by R. Feldman a few hours ago, and indeed it seems to be the right direction.