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

Consider following screen/body approach #77

Open
nivisi opened this issue Oct 20, 2022 · 1 comment
Open

Consider following screen/body approach #77

nivisi opened this issue Oct 20, 2022 · 1 comment

Comments

@nivisi
Copy link
Contributor

nivisi commented Oct 20, 2022

The problem

When creating a screen, sometimes we need to add a lot of top-level configuration widgets:

  // screen.dart
  @override
  Widget build(BuildContext context) {
    // 1
    return FocusScopeDismissible(
      // 2
      child: BlocProvider<Bloc>(
        create: (context) => injector(),
        // Aand the actual UI comes at this point...
        // 3
        child: Scaffold(
          // Aand the core part of it is here
          body: Column(
            children: const [],
          ),
        ),
      ),
    );
  }

At least 3 top-level things just to make the screen work normally. And it can be more.

The solution

The body of the screen could be moved to a separate widget:

  // screen.dart
  @override
  Widget build(BuildContext context) {
    return FocusScopeDismissible(
      child: BlocProvider<Bloc>(
        create: (context) => injector(),
        child: Scaffold(
          body: const ScreenBody(),
        ),
      ),
    );
  }

  ...

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

  @override
  Widget build(BuildContext context) {
    // The bloc's data could still be accessible via selectors and bloc builders
    final stateData = context.select((Bloc bloc) => bloc.state.data);

    return const Text("I'm the actual UI of the screen!");
  }
}

Pros

  • Makes you to follow smaller widgets approach;
  • Reduces the waterfall in the body of a screen.

Cons

  • So far I don't see it. We followed this approach on two projects and it was quite good.

Additional instruments that may help us

We can write a simple script that will generate the files on command from our IDE. I have already written a very similar script for a VSCode extension for my package, it is here. It can be a create_feature, not a module.

@nivisi
Copy link
Contributor Author

nivisi commented Oct 20, 2022

An example of what that generator does:

GenerationExample.mov

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant