Using 'part of' where one file doesn't contain a "freezed class" results in errors about freezed HOT 12 CLOSED

Done 👌

from freezed.

I'll take a look, thanks

from freezed.

I think that instead of "don't generate if it doesn't mix-in _$MyCLass", I'll go with "don't generate if the class has a property"

from freezed.

Basically it adds a DiagnosticableTreeMixin to the generated file's classes.

That's expected

It sounds more like a problem with parsing the name.

Could you give a minimalist way of reproducing the error?

from freezed.

When creating the demo project, I probably found the root of the issue. Code gen kicks in even for classes which don't extend _$SomeClass. While this minimal project written as a console app produces errors, they are not the same as in the case which I described with the BLoC.

UPDATE: The repository now also contains a minimal example with BLoC where Event is freezed and State is just a regular class marked as @immutable.

from freezed.

Note that removing the @immutable on NonFreezedClass will fix the issue.

I'll think of a proper fix. The main problem is, since the interface is generated, the analyzer doesn't pick it up because it doesn't exist yet

from freezed.

Removing @immutable works in the example, even with BLoC. For some reason though, this doesn't work on my real code. I can't really share it as there's a lot of specifics going on and it's definitely not a minimal example.

In the meantime, I'll try to migrate the regular class to a freezed data class. That should work 🤞

from freezed.

Sounds reasonable. Anyway, this issue forced me to rethink my legacy approach to pure immutable classes and now I use freezed even for them. Works perfectly, thanks again!

I just have to use static methods instead of factories to have "predefined state configurations" which is a bit of an antipattern in Dart but I can live with that 😄

from freezed.

I just have to use static methods instead of factories to have "predefined state configurations" which is a bit of an antipattern in Dart but I can live with that 😄

What do you mean?

from freezed.

Well, the static method is an anti-pattern, isn't it? I even have to ignore lint.

@immutable
abstract class SignInFormState with _$SignInFormState {
  const factory SignInFormState({
    EmailAddress validatedEmailAddress,
    Password validatedPassword,
    bool autovalidate,
    bool isSubmitting,
    Either<AuthFailure, Unit> isSuccess,
  }) = _SignInFormState;

  // ignore: prefer_constructors_over_static_methods
  static SignInFormState initial() {
    return SignInFormState(
      validatedEmailAddress: EmailAddress(''),
      validatedPassword: Password(''),
      autovalidate: false,
      isSubmitting: false,
      isSuccess: null,
    );
  }
}

from freezed.

Yeah I forgot to test that. I'll fix it.

But to be fair, your example should be a static const instead of a static function

from freezed.

Kind of, but EmailAddress cannot be const anyway as there's some validation going on inside of it. Otherwise, you're correct.

from freezed.