Skip to content

Support generating a custom map and using non-copying wrappers for serialization #48

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

Merged
merged 3 commits into from
Nov 23, 2017

Conversation

kevmoo
Copy link
Collaborator

@kevmoo kevmoo commented Oct 3, 2017

No description provided.


// TODO(kevmoo): Add documentation
abstract class JsonMapWrapper extends MapBase<String, dynamic> {
/// This operation is not supported by an unmodifiable map.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, is there a mixin for this? Otherwise this has to keep up to date with any new apis that the sdk adds....

Also, I think this should throw on putIfAbsent and addAll as well.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dude! WIP!

MapBase handles everything but what's overloaded here – it's nice.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok looking at the docs for MapBase this should be fine.

@@ -36,6 +36,8 @@ class JsonSerializableGenerator

final List<TypeHelper> _typeHelpers;

final bool _doNewThing = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might want to be a bit more descriptive here :)

buffer.writeln('}');

if (_doNewThing) {
buffer.writeln();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it is probably worth breaking this out into its own function


if (_doNewThing) {
buffer.writeln();
//
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: extra comment line

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack


if (fieldsList.every((e) => _includeIfNull(e, classIncludeIfNull))) {
// write simple `toJson` method that includes all keys...
//_writeToJsonSimple(buffer, fields);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cruft?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup

} else {
// At least one field should be excluded if null
//_writeToJsonWithNullChecks(buffer, fields, includeIfNull);
buffer.writeln('@override\nIterable<String> get keys sync* {');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth having the diverging code paths here? I would avoid it unless you have a compelling reason (performance?) to do this optimization.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sync* is pretty expensive. Going to benchmark to find out.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...in principle I agree

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also not use sync* and just build up a list or w/e, if you are concerned about the performance

var jsonKeys = fields.values.map(_safeNameAccess).join(', ');

// TODO(kevmoo): maybe put this in a static field instead?
// const lists have unfortunate overhead
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A static final field would be lazy initialized right? That might help startup performance.

@kevmoo
Copy link
Collaborator Author

kevmoo commented Oct 3, 2017 via email

@kevmoo kevmoo force-pushed the custom_map branch 5 times, most recently from 99ac290 to 2188446 Compare November 1, 2017 16:16
@kevmoo kevmoo changed the title VERY WIP - Support generating a custom map for toJson calls Support generating a custom map and using non-copying wrappers for serialization Nov 1, 2017
@kevmoo
Copy link
Collaborator Author

kevmoo commented Nov 1, 2017

@jakemac53 – this is ready for review.

@@ -6,102 +6,84 @@ import 'package:test/test.dart';

import 'package:json_serializable/src/utils.dart';

import 'test_files/kitchen_sink.dart';
import 'test_files/kitchen_sink.dart' as nullable;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, this prefix is a bit inconsistent (not abbreviated). Maybe just opt for no prefix? Or come up with a prefix and add it to wrapped as well.

@kevmoo kevmoo mentioned this pull request Nov 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants