Dialog creation best practices

[busslina]

Is this an acceptable way to prop drilling WidgetHandle? I'm referring to tryCreate method.
I think I asked this before but don't remember.

abstract class CreateDialog extends RearchConsumer {
  final String title;

  const CreateDialog({
    super.key,
    required this.title,
  });

  @override
  Widget build(BuildContext context, WidgetHandle use) => Column(children: [
        // Title
        Text(title),

        // Body
        buildBody(context, use),

        // Create button
        ElevatedButton.icon(
            onPressed: () => tryCreate(use),
            icon: const Icon(Icons.create),
            label: const Text('Create')),
      ]);

  Widget buildBody(BuildContext context, WidgetHandle use);

  Future<void> tryCreate(WidgetHandle use);
}

class UserCreateDialog extends CreateDialog {
  const UserCreateDialog({
    super.key,
    required super.title,
  });

  @override
  Widget buildBody(BuildContext context, WidgetHandle use) => const Column(
        children: [
          Text('Field 1'),
          Text('Field 2'),
          Text('Field n'),
        ],
      );

  @override
  Future<void> tryCreate(WidgetHandle use) {}
}

[GregoryConrad]

Yea, definitely don't pass an entire WidgetHandle around. If you do pass something, I'd make it just a CapsuleReader. Even then, I wouldn't use inheritance to solve this issue like you are. I'd do something like this:

@rearchWidget
Widget createDialog({
  // These two will be parameters to your CreateDialog constructor without the @rearchWidget macro
  required Widget Function(BuildContext, WidgetHandle) bodyBuilder,
  required Future<void> Function() create,
}) {
  // I might also suggest use.mutation here to watch the create() function so you can give
  // users an update on how the creation is going
  return Column(children: [
        // Title
        Text(title),

        // Body
        RearchBuilder(builder: bodyBuilder),

        ElevatedButton.icon(
            onPressed: create,
            icon: const Icon(Icons.create),
            label: const Text('Create')),
      ],
  );
}

For reference, here's the previous discussion we had about prop drilling and scoping state: #50

[busslina]

Well, I need this builder signature:

final Widget Function(
    BuildContext,
    WidgetHandle,
    SizingInformation,
  ) bodyBuilder;

Is there any reason to use RearchBuilder instead of the builder function directly?

[busslina]

Also, how will you do the following without inheritance?:

abstract class Screen extends RearchConsumer {
  final String name;
  final Widget Function(BuildContext, WidgetHandle) bodyBuilder;

  const Screen({
    super.key,
    required this.name,
    required this.bodyBuilder,
  });

  @override
  Widget build(BuildContext context, WidgetHandle use) {
    return Scaffold(
      appBar: AppBar(
        leading: getAppBarLeading(),
        title: fllib.Label(
          scaffoldTitle,
          color: Colors.white,
          fontSize: 20,
        ),
        centerTitle: true,
        backgroundColor: const Color.fromARGB(255, 61, 57, 57),
        foregroundColor: Colors.white,
      ),
      body: bodyBuilder(context, use),
    );
  }

  String get scaffoldTitle => name;

  Widget? getAppBarLeading() => null;
}

Specially getAppBarLeading because it can depend on the specific screen internal state.
Even more, with ReArch, I don't know how I would be able to achieve this, even using inheritance.

Synthesizing, how to build something that depends on the state of the subclass/bodyBuilder?

UPDATE:
I'm thinking maybe to pass to the bodyBuilder a setter function (setAppBarLeading). Would be this the WAY?

[GregoryConrad]

Is there any reason to use RearchBuilder instead of the builder function directly?

yes, because then the builder function is called with its own unique WidgetHandle, and we’re not “passing” one around. If your builder needs another parameter, still use a RearchBuilder but just pass the extra parameter in too.

Specially getAppBarLeading because it can depend on the specific screen internal state.

All state should be handled via side effects, so your answer here is that it should be created in the build().

Synthesizing, how to build something that depends on the state of the subclass/bodyBuilder?

the builder can be passed a function or similar that it can invoke to give its state to its parent. But this depends on the exact scenario in question, as hoisting state is often a workaround for some different issue.

I'm thinking maybe to pass to the bodyBuilder a setter function (setAppBarLeading). Would be this the WAY?

probably. But this also is a pretty rare pattern since there’s often a better way. Maybe there’s another way to build this piece of your app?

[busslina]

probably. But this also is a pretty rare pattern since there’s often a better way. Maybe there’s another way to build this piece of your app?

Maybe. Now I'm translating old code into new code, so maybe I'm not using the best design, like I could do when I do code from scratch. I will think about it

[GregoryConrad]

Ahh, ok. Migrations will fall into the “rare” category where it’s acceptable to do something like that :)