So, I am working with my IPFS client library and I’ve run into dialyzer hell. The code is kinda working fine, but Dialyzer is not happy with me. Before I ignore it completely, I want to make sure I’m not guilty of an anti-pattern.
The IPFS API returns stuff like this:
{
"BlocksReceived": "<uint64>",
"BlocksSent": "<uint64>",
"DataReceived": "<uint64>",
"DataSent": "<uint64>",
"DupBlksReceived": "<uint64>",
"DupDataReceived": "<uint64>",
"MessagesReceived": "<uint64>",
"Peers": [
"<string>"
],
"ProvideBufLen": "<int>",
"Wantlist": [
{
"/": "<cid-string>"
}
]
}
I thought it would be nice to make structs for these types of return values, instead of just passing the JSON back to user. I have made structs to build these, where I have structs for wantlist and CIDs.
myspace-ipfs/wantlist.ex at develop · bahner/myspace-ipfs · GitHub
myspace-ipfs/common.ex at develop · bahner/myspace-ipfs · GitHub
Then I use the structs as components for complex structs and so forth. I like the wantlist.keys notation that they give me when I structure the keys as (existing) atoms.
But when I take a result and pass it to Jason.decode, then dialyser becomes really unhappy. The error messages blow up in length, as I try to fix them. And, hence, I suspect I’m doing it wrong.
Please note. I can’t always use only use the Tesla.Middleware.Jason for this, as the API sometimes returns \n<\n when data is streamed, and there is no known end to the data, so it canæt generate lists, and hence not proper JSON.
Am I doing it wrong by trying to massage the data and should I just pass the JSON strings to the user? Or just let the middleware do its best and decode the lines as they come in.