I have a class I am using GSON to convert into the body of a REST request. When the class is marketed @Model for compose it adds “$record” and “frameId” into the json which breaks the request. Any good way to get around this?

Expected (without @Model):
{"public_key":"","user":{"email":"<mailto:me@me.com|me@me.com>","password":"fun"}}

Actual (with @Model): 
{"$record":{"user":{"$record":{"me":"<mailto:guy@me.com|guy@me.com>","password":"fun","frameId":1}},"frameId":1},"public_key":""}

@Model

is getting deprecated. Is your class immutable? Then you should mark it

@Immutable

instead.

the app model needs to be mutable.

Any way around the problem in the short term?

It seems a bit unusual to have your JSON model type double as a live app model. My first instinct would be to make your JSON model immutable, and store it in a

MutableState

. If you need to change your json model, just put a new instance into the state. If you can’t use an immutable value for some reason, then you can make a wrapper that maintains

MutableState

properties for every property on your JSON object.

I have a message that can go over multiple transports. For messages that go only over one transport the message data structure becomes a field in the model. This avoids lots of translation.

I still don’t understand why your can’t just put your message values in

MutableState

holders in your UI layer. How are your JSON model objects mutated?

GSON

IIRC, GSON will return a new instance when deserializing, not mutate an existing one, is that not true?

Correct.

So what’s mutating your ResponseData?

it gets copied into the app model, however it could be changed in other ways.

In general, it’s a good practice to decouple your UI state from your backend data transfer layer.