Skip to content
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

Nullable list generated as an empty list #219

Open
TanguyChevillardNovade opened this issue Jul 8, 2021 · 10 comments
Open

Nullable list generated as an empty list #219

TanguyChevillardNovade opened this issue Jul 8, 2021 · 10 comments
Labels
bug Something isn't working

Comments

@TanguyChevillardNovade
Copy link

TanguyChevillardNovade commented Jul 8, 2021

Hello,
One of my GraphQL types has two fields that can either be null or non-empty lists (in and notIn in the screenshot):
image

My issue is the fact that, in the type generated by Ferry, those fields are not nullable but instead created as empty lists:

image

This causes errors in my backend, as empty lists are not expected there.

I have created an example in this repo:
https://github.com/TanguyChevillardNovade/FerryEmptyList

Is this a bug, or did I forget to add something in one of the GraphQL files?

@smkhalsa
Copy link
Member

smkhalsa commented Jul 8, 2021

This is likely caused by google/built_value.dart#1049 which I believe was resolved in v8.1.0.

We may need to use the new serializeNulls option, but I haven't looked at it very closely.

PRs welcome.

@smkhalsa smkhalsa added the bug Something isn't working label Sep 6, 2021
@GP4cK
Copy link
Contributor

GP4cK commented Apr 15, 2022

@smkhalsa I was looking into this issue to potentially make a PR. If we use serializeNulls without nothing else, I'm afraid the JSON output will have all the nullable fields without value set to null. However, I would like to only set the ones I chose to null (the others should not appear in the JSON).

I know that drift has a class Value which they use to differentiate between:

  1. a value being absent
  2. the value being null.

Would it be ok with you if I do the same? However, this may introduce a breaking change because this code:

final reviewsReq = GReviewsReq((b) => b.vars.first = 10);

will become:

final reviewsReq = GReviewsReq((b) => b.vars.first = Value(10));

if first is nullable.

Is that ok with you? Or do you see an alternative?

@smkhalsa
Copy link
Member

I'd rather avoid this.

Is the issue of absent vs nullable only present when converting to JSON?

@GP4cK
Copy link
Contributor

GP4cK commented Apr 15, 2022

Is the issue of absent vs nullable only present when converting to JSON?

I think so. At least for my use case and I believe the one of the issue.

@smkhalsa
Copy link
Member

The original issue relates to the Dart classes allowing lists with null values.

@GP4cK
Copy link
Contributor

GP4cK commented Apr 15, 2022

Mmm I thought the original issue was to be able to not set in and notIn (or set it to absent) so that the client does not send an empty list to the backend.
Anyways, do you have a better idea to distinguish between absent vs null? I'd be happy to help if needed.

@smkhalsa
Copy link
Member

Does built_value's own internal representation of the data distinguish between null and absent?

@GP4cK
Copy link
Contributor

GP4cK commented Apr 15, 2022

I don't think so. I've made a sample repo: https://github.com/GP4cK/built_value_absent
You can run it with dart run and it will output in the console the JSON with null (even though I did not specify a value).

@GP4cK
Copy link
Contributor

GP4cK commented Apr 15, 2022

Basically whether you set serializeNulls to true or false, it will either include null in the JSON or ignore it but it doesn't make the difference between null and absent.

@GP4cK
Copy link
Contributor

GP4cK commented Apr 16, 2022

I also created an issue on built_value's repo: google/built_value.dart#1123

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants