Use shared repo for transient annotations about auto-value-moshi HOT 13 CLOSED

@SerializeOnly and @DeserializeOnly are cool when you require only one or the other. But may be @Saketme has a point, and moshi-auto-value needs a @Transient annotation that would completely exclude the field from the generated adapter.

from auto-value-moshi.

from auto-value-moshi.

See #41

from auto-value-moshi.

@vanniktech Interesting. So is it possible to create a custom @JsonQualifier annotation that can apply on any type of fields?

from auto-value-moshi.

Just look at the project and the tests and you'll see everything

from auto-value-moshi.

Yea I tried going through it, but it seems like I will have to spend a considerable amount of time to understand the code 😅. I will look into it again after office.

Still, considering that moshi supports transient fields, there's no reason for auto-value-moshi to not support it.

from auto-value-moshi.

This one and that one is all you need to go through.

from auto-value-moshi.

I took a deeper look into this. So at the moment adding Transient could work but in a very nasty way:

• If the return type is a primitive then we just leverage from the default value that the extensions sets and just omit generating the case block for it's name.
• The fun starts if it's not a primitive, then we have to force (at least that's what comes into my mind) the user to specify a @Nullable annotation as well. Otherwise auto-value will generate a null check in the constructor which will throw a soon as the adapter invokes it. And that's ugly (altho not illogical).

What are your thoughts? @rharter would you support such an approach?

from auto-value-moshi.

I'd like to propose accepting any annotation with this name as fuzzy matching (similar to how dagger or autovalue handle nullability annotations). I agree it would be ugly, and would prefer to wait and see if AV opens up its builders to the extension API.

For reference types, would could fail this at annotation compilation time if we don't have a builder to fallback on.

from auto-value-moshi.

We've got a PR in review now for auto-value-gson that would address this and deal with the challenges @serj-lotutovici identified. It adds an @Ignore annotation, with an enum that allows you to specify ignoring SERIALIZATION, DESERIALIZATION or BOTH (default).

As you pointed out, this can make code that will crash at runtime, so we updated the constructor of the generated TypeAdapter to require fields that aren't @Nullable as default values. I think it'll be fairly easy to port over once we get it finished up there.

from auto-value-moshi.

I can take over this, if everyone is ok with that... will come up with a pr later today.

from auto-value-moshi.

I mentioned this in another discussion sometime back, but what do you guys think of creating a shared repo of annotations? I foresee a lot of these being duplicated, or being a bit confusing.

@Ignore/@Transient

I also still think the better long term solution is to rely on a builder, but with no real idea of when that would happen then I think this is fine for now

from auto-value-moshi.

@hzsweers I'm 100% for a shared repo of annotations and may be other shared functionalities.

from auto-value-moshi.