dartson
dartson copied to clipboard
Future of dartson
There have been great improvements and changes in the dart ecosystem since the first version (0.1.0) of dartson was released in October 2013. With the latest movement away from mirrors, transformers (barback) and towards code generation there are some great alternatives to dartson including:
https://pub.dartlang.org/packages/json_serializable https://pub.dartlang.org/packages/built_value
With this in mind I was thinking about the future of dartson with the following points in mind:
- Why do developers choose dartson over other packages?
- Popularity because of the article: https://www.dartlang.org/articles/libraries/serialization
- Ease of use without importing generated files?
- Custom type transformers?
- What features should be provided in the future?
- Support across multiple packages
- Complex objects
- Runtime class/type replacements
- Versioning support
- Default value serialization
- Which packages are used commonly with dartson?
- Should there some sort of adapters to these packages?
- On which platform is dartson used or should be used? (server,web,mobile)
I need your support to answer these questions and to make a decision of where to go next with the development of dartson. Therefore I would really appreciate feedback to these questions or any additional input.
Great reflection here, @eredo .
Happy to discuss alignment, code sharing, etc across dartson and json_serializable.
Well I was using dartson cause it was familiar to me coming from java world used to jackson. But now I am not on dart for more than year, so don't know how things have changed.
Thanks @kevmoo !
It sounds like a good idea, to have json_serializable as the basic serialization solution with no "magic" and dartson on top to provide some nice to have features. I'll go ahead and make a list of features which are currently available in both packages and gather some further features from known libraries of other languages (like jackson, gson, etc...).
Sounds great!
On Thu, Mar 1, 2018 at 12:59 AM, Eric Schneller [email protected] wrote:
Thanks @kevmoo https://github.com/kevmoo ! It sounds like a good idea, to have json_serializable as the basic serialization solution with no "magic" and dartson on top to provide some nice to have features. I'll go ahead and make a list of features which are currently available in both packages and gather some further features from known libraries of other languages (like jackson, gson, etc...).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eredo/dartson/issues/48#issuecomment-369522270, or mute the thread https://github.com/notifications/unsubscribe-auth/AABCiox3U99m8BxzXRJaHfS2pcTLa06xks5tZ7hvgaJpZM4SVewB .
Dartson was the only library that actually worked + quickly and easily given the sample code and it reminded me the most of how Gson from java or Newtonsoft from c# worked.
dartson is the library used by swagger.io. we currently use it for native (android/ios) and web development so it will be cool to use it on flutter as well!!
Interesting! Didn't know it was used, but looks like they have also converted from dartson because of flutter support.
@kevmoo I'm still working on this, but it takes some time because of the lack of free time (tackling the release of our 2.0 software version). I'm currently getting into the source of json_serializable builder and write a proposal of how the package could work together based on the features dartson could ship with.
There are also some additional proposals which could provide a functionality on top of json_serializable:
https://github.com/eredo/dartson/tree/master/doc/proposal
Sounds great!
On Fri, May 18, 2018 at 11:50 PM Eric Schneller [email protected] wrote:
@kevmoo https://github.com/kevmoo I'm still working on this, but it takes some time because of the lack of free time (tackling the release of our 2.0 software version). I'm currently getting into the source of json_serializable builder and write a proposal of how the package could work together based on the features dartson could ship with.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eredo/dartson/issues/48#issuecomment-390384523, or mute the thread https://github.com/notifications/unsubscribe-auth/AABCipRaUzhKNCwSo_9bP4i3u7dhQOq1ks5tz8DKgaJpZM4SVewB .
To keep you posted. I'm working on a new alpha version, which should support current functionality but requires small amount of builder setup. I'll probably have something released by the weekend.
It is using a different approach to json_serializable and built_value as the serialisation will not take place in a part file of the actual object, but in a part for the serialiser. However this of course has some downsides like: privat properties aren't accessible and changing some objects will cause a longer build, however there are some upsides: less bootstrapping, full control of objects. Also there are some ideas to make it compatible with built_value and json_serializable.
So first alpha release is out. It ships with the base functionality which was provided in previous dartson versions and because of json_serializable enums are supported as well.
Big thanks to @kevmoo and all authors of json_serializable. Regarding code sharing: I have used the TypeHelper implementations and it would be great to expose the MapHelper, ValueHelper and IterableHelper as public. @kevmoo let me know what you think and I can prepare a PR for json_serializable. Also the implementation within dartson is just a draft and needs heavy refactoring. During the refactoring I'll write down some further proposals of how an adjustment of De/SerializableContext and TypeHelper could be helpful for other builders. There are also some helper functions within json_serializable which could be useful for other builders and could be exposed within a more general builder_utils package (like fetching all fields including inherited once from a ClassElement).
Big thanks to @kevmoo and all authors of json_serializable.
You're welcome! 😁
Regarding code sharing: I have used the TypeHelper implementations and it would be great to expose the MapHelper, ValueHelper and IterableHelper as public. @kevmoo let me know what you think and I can prepare a PR for json_serializable.
A PR is great. They should be exported from type_helper.dart - https://github.com/dart-lang/json_serializable/blob/master/json_serializable/lib/type_helper.dart
Also the implementation within dartson is just a draft and needs heavy refactoring. During the refactoring I'll write down some further proposals of how an adjustment of De/SerializableContext and TypeHelper could be helpful for other builders.
SGTM! (sounds good to me)
There are also some helper functions within json_serializable which could be useful for other builders and could be exposed within a more general builder_utils package (like fetching all fields including inherited once from a ClassElement).
I've gone back and forth with folks on the team about this. I've done a LOT of copy-paste to https://github.com/kevmoo/build_cli that could use some code sharing. Happy to collaborate and even own the shared-bits package.
@eredo hi, I gather that the little 'codec: json' should automatically call json.decode/encode right? but I still get an error: "Type 'IdentityMap<String, dynamic>' is not a subtype of expected type 'String'. (CastErrorImpl)" I looked around and the bug I think is because the generated serializer.g.dart is wrong, it initializes with "codec: null" despite me adding "codec: json" in serializer.dart
edit: Also could you add a .message to the DartsonEntityNotExistsException that says which entities dont exist?
@Meai1 thanks for the feedback! I'm currently working on the refactoring including proper exception messages. I'm also considering implementing Codec in Dartson, so it could be used with other codecs using the fuse functionality. An implementation could look like:
final Codec<Map<String, dynamic>, String> serializer = _serializer$dartson.fuse(json);
I was able to reproduce your issue and I am working on a fix ASAP.
@Meai1 the issue is fixed in 1.0.0-alpha+1 . Please see README.md for the implementation. My previous idea of using Codec doesn't work as intended because of the generic methods necessary for dartson.
@eredo I just tried to encode a List
List<int> not found in the entity list of the serializer. Please make sure to add List<int> to the entities defined in the @Serializer annotation of your serializer.
That seems like it worked in the old dartson.
Indeed! I have this on my todo list. List encoding / decoding doesn't work currently. I'll maybe get something in today. It will be a different method encodeList, decodeList.
@Meai1 encodeList + decodeList is now available in 1.0.0-alpha+2.
Also refactoring is ongoing. Further improvements and adoption of TypeHelper, but still a lot of stuff to do. Wasn't able to write the proposal for a shared package just yet, but have this on my list for this week. However since I'm no longer on vacation, I will probably have not that much time to spend on it.
@eredo FYI - https://github.com/dart-lang/json_serializable/pull/318
To keep you posted. The year is close to it's end and time went by so fast (as always).
I'll take a break from work live starting in January next year and will invest that time in dartson and some other dart related projects. My first goal will be to finish dartson 1.0, but there are some great changes ahead. Dartson will (hopefully fully) support json_annotation and be completely compatible with json_serializable, therefore the next release will be a beta version, which contains all the necessary changes of which most will be breaking the current API. Afterwards only minor refactorings and no breaking changes will continue to hopefully finally release a stable version of dartson within the first quarter of 2019 (no promises made).
I would like to give an example of a situation when json_serializable wasn't enough for my needs and maybe a package that forks/extends/improves-upon json_serializable would have been really useful.
I wanted to store my flutter app's theme in memory so I can persist it across app launches, and I thought json would be a great way to do that. If only I would have been able to declare the built-in class ThemeData as serializable that would have been so easy and perfect solution, but I couldn't because it is built-in. So instead, I made my own class to represent the theme of the app but unfortunately, since it was a complex class, that wasn't enough. json_serializable wouldn't work for Brightness and Color objects! So when I declare a class as serializable it doesn't generate serialization code for the objects that could be contained in the class!
If dartson could extend json_serializable to work with built-in types and complex objects that would be a great package and a great contribution for the dart and flutter ecosystem.
possible syntax:@jsonSerializable(Color)