bahner
To struct or not to struct, Decode or not decode
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.
Most Liked
al2o3cr
What warnings? Where do they appear? I ask because I’ve seen plenty of very strange messages in-editor when elixir-ls gets confused, but those usually disappear after cleaning _build etc and don’t show up in mix dialyzer.
zachallaun
I personally have dialyzer disabled in my vscode-elixirls settings because I find the warnings very distracting for WIP code. When I am closer to a final version, I run it on the command line to check my assumptions and catch things I missed.
bahner
I took in the replies I got and learned that I was trying a bit too hard. So i loosened up trying to cram everything into a specific type in the api-module. Refactored the whole thing, in a way that means I have to do a little more work over each function, but have more control. Using the mix dialyzer allowed be to see the errors more clearly in the shell, than as small windows in VS Code.
The hint, that dialyser is usually right made me follow the advice to get a better picture of what iot wanted. And it worked. Thanks.
paulanthonywilson
Fun thing about elixir_ls is that it doesn’t compile to ./_build, but to ./.elixir_ls (specifically ./elixir_ls/build/test). I don’t think I’m alone in occasionally zapping the .elixir_ls directory.
Another fun thing is that dialyzer is almost always correct although often cryptic. (When I say fun, I really mean infuriating.)
As @hlx says, I’d be inclined to also include dialyxir as a dependency (only: [:dev, :test], runtime: false) so you can run mix dialyzer from the terminal and fix the errors, eg with the capitalisation typo MySpaceIPFS instead of MyspaceIPFS, eg here
Also as @hlx alludes {:ok,MyspaceIpfs.RootCid}should probably be{:ok, :MyspaceIpfs.RootCid.t()}` (which I see you’ve defined in the struct).







