Lists for union types have missing type in generated code

[maks]

Given a model class which has a list of a "union subtype":

@freezed
abstract class FApp with _$FApp {
  factory FApp({Header head, List<Page> pages}) = _FApp;
}

where the union is:

@freezed
abstract class WidgetType with _$WidgetType {
  const factory WidgetType.page({Body body, Header header}) = Page;
  const factory WidgetType.body() = Body;
  const factory WidgetType.header({String title}) = Header;
}

the type for the list in the generated code is dynamic instead of the actual type:

mixin _$FApp {
  Header get head;
  List<dynamic> get pages;

  FApp copyWith({Header head, List<dynamic> pages});
}

but in that generated code I expected page getter to be List<Page> not List<dynamic>.

It all works fine if I use List<WidgetType> but I really want to ensure I'm getting a List of Pages and not just any WidgetType

I've got a repo with the full demo code

[rrousselGit]

Do you still have the issue if you extract FApp in a different file?

[maks]

Sorry I didn't explain it well, in my example repo FApp is in a separate file.

[rrousselGit]

This was fixed as part of 10.0.3 but I forgot to close the issue

[maks]

@rrousselGit I'm sorry if I'm doing something wrong, but with my demo repo that I tested with using freezed 0.10.9 now and I am still seeing the same problem, the generated code still has:

mixin _$FApp {
  Header get head;
  List<dynamic> get pages;

  $FAppCopyWith<FApp> get copyWith;
}

so still a dynamic List instead of the actual type from the freezed "union" that I defined 😞

[rrousselGit]

What is Page then?

[maks]

Sorry, Page is from the "union" I have:

import 'package:freezed_annotation/freezed_annotation.dart';

part 'widget_type.freezed.dart';

@freezed
abstract class WidgetType with _$WidgetType {
  const factory WidgetType.page({Body body, Header header}) = Page;
  const factory WidgetType.body() = Body;
  const factory WidgetType.header({String title}) = Header;
}

[rrousselGit]

Oh I didn't realize, my bad.

Indeed this is not supported.

[maks]

@rrousselGit I would really like to have this for a project I'm working on - is this something I could help to add to freezed or is there something fundamental that would stop freezed being able to support this?

[rrousselGit]

This is a bit difficult to support, as analyzer doesn't give the name of the type if it fails to resolve.
So Freezed never knows that it's a List<Page>, it receives List<dynamic> directly.

A first step would be to ask the Dart team to add the name of the type that failed to resolve.

[maks]

@rrousselGit I've started having a look and try to figure out what's happening. As you pointed out, freezed is just using what its given, I can see by setting a breakpoint inside ParserGenerator.generate() at line 29 that the LibraryReader object that parseElement() extracts a List<dynamic> for the pages parameter.

But my suspicion now is that this is actually something to do with how source_gen is working rather than the analyser as the first non generic parameter, header does get assigned the correct Header type which also comes out of the same freezed generated file as the Pages type that is supposed to be assigned to the List parameter.

I'll keeping digging down this rabbit hole and see if I can find where this is being processed inside source_gen...

[rrousselGit]

The real reason is because the class Page is generated by freezed. So when the analyzer analyzes the dart file, Page doesn't exist yet and the analyzer says "dynamic" instead.

…

On Wed, 10 Jun 2020, 06:56 Maksim Lin, ***@***.***> wrote: @rrousselGit <https://github.com/rrousselGit> I've started having a look and try to figure out what's happening. As you pointed out, freezed is just using what its given, I can see by setting a breakpoint inside ParserGenerator.generate() at line 29 that the LibraryReader object that parseElement() extracts a List<dynamic> for the pages parameter. But my suspicion now is that this is actually something to do with how source_gen is working rather than the analyser as the first non generic parameter, header does get assigned the correct Header type which also comes out of the same freezed generated file as the Pages type that is supposed to be assigned to the List parameter. I'll keeping digging down this rabbit hole and see if I can find where this is being processed inside source_gen... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#89 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEZ3I3N2MCNRMLWMHXUJCVDRV4OBTANCNFSM4LCBGFSQ> .

[maks]

That's what I thought at first too, but it works fine for the first parameter of FApp, which is Header type which is also a class generated by freezed: https://github.com/maks/esky/blob/master/lib/src/widget_type.dart

[maks]

I did also think that it might be due to an existing open issue in source_gen around depending on generated classes but it doesn't seem to be the case as per my last comment, the generated Header type from the same freezed generated file is correctly handled.

[rrousselGit]

Header works because Freezed does a manual parsing in this scenario

When an object is analyzed as dynamic, Freezed does an extra parsing to try and extract the type name.

But with List<Header> that wouldn't work as we're not receiving dynamic but List<dynamic>, which is a lot more complex to handle.

[maks]

Ah ok, sorry @rrousselGit I think I am beginning to understand now.
Oh this is super annoying! I can see the actual type stashed away inside the DefaultParameterElementImpl which is what the constructor.parameters objects actually are, but looks like there is no way to get at the property as the ParameterElement class "interface" doesn't expose any of it 😞

[maks]

@rrousselGit so I read through your code some more and once I figured out how it did the extra parsing, I had a basic go at extending your extra parsing to cope with generics which refer to freezed generated code classes, though I think most use cases would just be for List and Map:

maks@82b757a

It seems to work in my initial manual testing.

If this is something that you'd be interested in using? I can add some unit tests for it and check my changes don't break existing tests.

[rrousselGit]

For sure. Feel free to make a pull request 😊