Description
openedon Aug 17, 2023
I have to admit the fact that this library implements AttributeKey and AttributeValue is a bit confusing. Why not just accept a [String: Any] and if the end user happens to pass in something other than a basic data type that you can understand... ignore it server side? The any
aspect of this whole thing is blowing me up from the typealias' existential jazz.
In my app, I want to pass in [String: Any]'s of data as attributes. I have a lot of data that I want to log which spreads across data types and namespaces.
Simple [String: Any] data I would like to send:
{
"status_code": 200,
"url": "https://foo.bar",
"device": {
"device_model": "iPhone 14 Pro",
"screen_brightness": 50.0,
"device_name": "iPhone",
"battery_level": -100.0,
"is_jailbroken": false,
...
},
"headers": {
"X-ClientId": "000",
"X-Platform": "iOS",
...
},
"global": {
"bundle_id": "com.foo.bar",
...
},
"foo": {
"role": "foo",
"family_list": [
{
"Family_id": 0,
"Family_name": "foo"
}
],
...
}
}
We have a simple wrapper class to organize a bit of the data we want to pass in. This looping logic is purely here to type cast and maintain the object hierarchy. foo: family_list, etc
Which uses this type caster func just to build the expected dictionary:
I can pass in any dictionary I want and cast to AttributeValue easily... as long as the data types are not Any
. So [String: String], [String: Double], [String: Bool]... they all work great, but as soon as I want to use a [String: Any], things fail.
In the above json example, "device" has mixed value types. As does "foo".
This seems to be the issue here: https://stackoverflow.com/a/76924488/2966596
I'm either A: missing something basic here that makes life easy for a developer. Or B: the developers of this library haven't used this in production or on anything other than unit tests with simple mocked data. Please tell me it's A.
I also hope the solution isn't to create an Encodable struct for everything I want to use.