-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
look into proto-lens-jsonpb #109
Comments
https://github.com/tclem/proto-lens-jsonpb/blob/master/src/Data/ProtoLens/JSONPB/Class.hs#L224-L226 This function might help out with types with |
https://github.com/tclem/proto-lens-jsonpb/blob/master/src/Data/ProtoLens/JSONPB/Class.hs#L159-L162 This one should address the other 2 categories |
I should be able to give a pretty thorough pros/cons write up for this. See my WIP branch |
Given below, I don't think we benefit using this library. Aside from not having to worry about possible null values (i.e., because every PB instance is required to declare a default field value), we actually incur writing more boilerplate and manual JSON instances. CONS
PROS
|
In a similar effort of trying to use generic JSON parsers, I've come to another conclusion: We should only use this library if we find any value in encoding defaults inside of a newtype Foo = Foo {..}
instance FromJSON Foo where
parseJSON = withObject "Foo" $ \v -> Foo
<$> v .:? "some_nullable_field" .!= someDefault versus with PB: newtype Foo = Foo {..}
instance FromJSONPB NullableField where
parseJSONPB = ...
instance FieldDefault NullableField where
fieldDefault = someDefault
instance FromJSON Foo where
parseJSON = withObject "Foo" $ \v -> Foo
<$> v .: "some_nullable_field" |
It's possible that this library could allow is to get away with less manual json definitions or
WrappedVal
shttps://hackage.haskell.org/package/proto-lens-jsonpb
The text was updated successfully, but these errors were encountered: