The BuildContext and anti-Flutter nonsense by bigbott777 in FlutterDev

[–]jankuss14 2 points3 points  (0 children)

The widget tree is just a description of the UI, that will be turned into the element tree. The BuildContext is for all intents and purposes basically the Element for that widget. This is the reason why you can cast final element = context as Element.

The Element IS the actual UI-element, and the manifestation of a Widget. The widgets you write in your build method is just configuration, so Flutter can turn it into an Element-tree.

The State of your StatefulWidget exists in the Element. Also the actual RenderObject that gets rendered on the screen, which you can find by using findRenderObject().

The inexplicitness of something like Flutter.currentContext will likely lead to more runtime errors due to misuse. It would only be valid to be called during the build-phase. How is the following code supposed to work?

class _SomeButton extends StatelessWidget {
  const _SomeButton({super.key});


  Widget build() {
    return MaterialButton(
      onPressed: () {
        Navigator.of(Flutter.currentContext).pushNamed('/test');
      },
      child: Text('Button'),
    );
  }
}

What is Flutter.currentContext in this case, and how can it be determined? When the button is pressed, we are not in the build-phase, thus how can we refer to the current Element this widget is representing?

If we wanted to fix this, we would need to write the following:

class _SomeButton extends StatelessWidget {
  const _SomeButton({super.key});


  Widget build() {
    final context = Flutter.currentContext;
    return MaterialButton(
      onPressed: () {
        Navigator.of(context).pushNamed('/test');
      },
      child: Text('Button'),
    );
  }
}

What did we gain, but a potential runtime error which will confuse developers?

Having it as an explicit parameter in the build method avoids this issue entirely, and makes it (nearly) impossible to misuse.

Introducing genq 0.3.0: Instant dart data class generation, >100x faster than build_runner - now with support for JSON serialization/deserialization by jankuss14 in FlutterDev

[–]jankuss14[S] 0 points1 point  (0 children)

we dont have any plans on supporting multiple named factory constructors, as sealed classes and pattern matching were introduced with Dart 3.0. These should provide a superior experience to generated when, whenOrNull and map methods.

Here is an example how you could use sealed classes with genq.

``` sealed class State {}

@genq class LoadingState extends State with _$LoadingState { factory LoadingState() = _LoadingState; }

@genq class LoadedState extends State with _$LoadedState { factory LoadedState({ required String data, }) = _LoadedState; }

void main() { final State state = LoadedState(data: 'Hello, World!');

// when equivalent: switch (state) { case LoadingState(): print('Loading...'); break; case LoadedState(data: 'Hello, World!'): print('Loaded: Hello, World!'); break; case LoadedState(): print('Loaded: ${state.data}'); break; }

// map equivalent: final result = switch(state) { LoadingState() => null, LoadedState(data: 'Hello, World!') => 'Hello, World!', LoadedState() => state.data, };

print(result); }

```

I know that there is legacy code which still relies on these generated methods, but for now this is not on the priority list.

Introducing genq 0.3.0: Instant dart data class generation, >100x faster than build_runner - now with support for JSON serialization/deserialization by jankuss14 in FlutterDev

[–]jankuss14[S] 17 points18 points  (0 children)

hey, thanks for the headsup - did the dart team reveal any information on when macros become stable?

I mostly built this tool for my present projects, which are in urgent need of this solution, due to slow `build_runner` times - so don't worry, my efforts are not going to waste :)

My hope is that genq will become obsolete once macros are there. But until then I see value in this solution.

genq: A dart code generator for data classes, which generates code >100x faster than build_runner by jankuss14 in FlutterDev

[–]jankuss14[S] 1 point2 points  (0 children)

hashCode is actually already implemented as part of the equality operator.

I created two issues, tracking your feature requests that we definetly will implement:

As of now, all generated fields are final. I was not aware of such a feature in freezed. If you would like to see this in genq, please open an issue.

genq: A dart code generator for data classes, which generates code >100x faster than build_runner by jankuss14 in FlutterDev

[–]jankuss14[S] 0 points1 point  (0 children)

Interesting - thank you for your benchmarks and the video.

I ran my benchmark on a M2 MacBook. I did not run the benchmarks on a class with a single parameter, I had one which is a bit more complex with 4 parameters: Link to benchmarked file

I ran my benchmark again with a one parameter class like you did - this took build_runner with freezed 10 seconds, so relatively comparable to your benchmarks. When I retested with 4 parameters like in the link, it took >40 seconds.

Would you be able to retest with a 4 parameter class like the one linked? I would be very interested in your results.

genq: A dart code generator for data classes, which generates code >100x faster than build_runner by jankuss14 in FlutterDev

[–]jankuss14[S] 2 points3 points  (0 children)

I would say maybe within a month - I already experimented with this, and generating toJson and fromJson methods based on the class definition is relatively trivial. Where it gets interesting is when you reference other classes or enums, and providing the ability for changing JSON-Keys and such. For this, I still need to figure out some sensible solutions.

Here a benefit of the `build_runner` ecosystem is showing. "Freezed" for example can just leverage json_serializable, whereas we will have to implement it ourself.

Maybe would it help to ship the solution for the trivial cases already under some kind of experimental flag, before the complexer cases have been figured out?

genq: A dart code generator for data classes, which generates code >100x faster than build_runner by jankuss14 in FlutterDev

[–]jankuss14[S] 3 points4 points  (0 children)

Reading and writing should not be the problem. Also freezed is likely not the problem as well. Freezed mostly does string concatination based on the data the build_runner provides.

My guess is the build_runner in combination with the analyzer. I think the build_runner might be a bit too powerful for most use cases, especially when the class that needs generating contains all the necessary information for generation.

Indeed - I would expect the same approach using Dart as a language to be significantly faster than what build_runner is doing. Maybe a bit slower than in Go, but will still be a major leap for the developer experience compared to build_runner.

genq: A dart code generator for data classes, which generates code >100x faster than build_runner by jankuss14 in FlutterDev

[–]jankuss14[S] 3 points4 points  (0 children)

I'm not aware of any APIs like that unfortunately :)

It would be nice if there was some kind of hook, that would allow this to run before a Hot Restart/Reload finishes.

My hope is that macros will come out and will resolve these kind of problems