Currently implementing a Swift devRant SDK and encountered something very stupid:

The json value for attached image is an object (dictionary) when there is an image but it‘s an empty string "" when there is no image.

So two different types for the same property.

I hate this kind of crap.

Why not make it null or omit that property when there is no image?

Now I need to add ugly as fuck custom decoding code for this object.

isnt there a "NullValueHandling = NullValueHandling.Ignore" equivalent when deserialising?

@azuredivay the issue is that it‘s not null but an empty string

what's the problem? You don't have union operators?

@antigermanist I know union types (not operators) from typescript.
Declaring multiple possible types doesn‘t help the issue because the decoder still wouldn‘t know what type to use.
All it could do is to try and decode those types one after another until one succeeds.
And that‘s exactly what I am doing with custom decoding.

It‘s not an unsolvable problem. It‘s just shit api design and ugly decoding code.

@Lensflare say what u want, typescript is pretty nice with this. You could just do something like

type Image = ImageProps | ""'

@Lensflare but yes if the decoder want static typing that wouldn't work. Weird though, because nothing in the json specs says anything about props having specific types.

@Lensflare anyway there's always edge cases. maybe abstract it away at least so it doesn't pollute the main code

@antigermanist of course it will be abstracted away. That’s the whole point of the sdk: it provides nice and clean code to access devrant data with nice and clean model types with proper names and structure.

All the dirty mapping and decoding code is hidden.

Though the declarative mapping code can also be seen as doc for the devrant api.
And that‘s where the ugly custom mapping code gets in the way.

@Lensflare well i'll prolly never use swift but

thanks i guess <3

@antigermanist that‘s ok. I mainly write it for myself.

It would be nice if someone else would actually use it but thats unlikely.

How did this end? Still working on that?

@retoor about 80% done. Working on this in this moment.

Btw, what were the values for the downvote reason again?
1=not for me
2=spam

Something like that?

I‘m still not sure how I want to add the downvote reason into JoyRant.

I don‘t want to show a popup with 2 options like in the official app.

Maybe a second button next to the -- one which says "spam".

Or next to the report button if I find out what the report api is.

@Lensflare not for me is zero and repost is 1, see top of file https://retoor.molodetz.nl/retoor/...

@Lensflare four reasons.

@Lensflare what report api? 😂

@Lensflare oh, you think it's a report. No, it's repoST

@retoor thanks. Three reasons then ;)

Report api - the one that should be called when you want to report a rant. The report button is right in your screenshot :)

@Lensflare I never saw that thing before in my life. I swear.

@retoor
https://github.com/WilhelmOks/...

This is a fun little project that came out of the development of the Swift devRant SDK :)

It makes it super nice and easy to write request code for json rest apis in Swift.

@Lensflare, Ooeeh, will check now! I'm trying my new deretoor service at the moment. To be honest, it became a retoor service (the opposite of deretoor).

@Lensflare, nice! I hope I read it right, first time swift. But a few mentions:

- I doubt if it's correct what you do with the "+" as the only token needing to be converted.

- DateTime parsing shouldn't resolve in an error. If it fails, it's just not a DateTime, but a string, in my humble opinion. Or is the exception caught somewhere that I didn't see?

- Do not add support for upper casing HTTP methods. There's nobody that uses lower cases, and we also shouldn't allow that. By accepting both, you're raping the standard. It's described there. Otherwise, you get stuff like <a href=http:// and <a href="http://". Browsers accepted so much crap that nobody knew what was right anymore. That wouldn't have happened if they had a backbone back in those days.

But cool, let me know if you make progress.

@retoor

The + thing that you saw was probably the one exception that needs to be done when using the system functions to percent encode url parameters.
The system accepts + as the space character but it should be percent encoded/escaped if it‘s part of the value of a url parameter.
It‘s a well known quirk of the std lib.

If a json value is supposed to be a date/datetime, then it should resolve in an error if it can‘t be parsed. Due to the strict type system, it can not be a Date OR a String.
And that‘s a good thing. I don‘t want to be forced to check the type and do some fallback logic in case it turns out to be a string and not a date 😄
If it doesn‘t parse, then it‘s considered invalid.
If it‘s valid but still doesn‘t parse, then I should fix the parser.

@retoor

About uppercasing http methods: never heard that uppercasing isn‘t correct.
A googled it quicky and apparently uppercase is correct.
But the consumer of the lib doesn‘t need to care because the methods are abstracted as enums.

The devrant sdk uses this request lib and the sdk itself is mostly done.
Now I need to integrate it into JoyRant as a dependency.

@retoor ah, I read your comment again.

No, I‘m not supporting both, lower and uppercase. They are all uppercase.