Splash view body

Presentation (Building the UI)

09:40

Summary

This lesson focuses on the initial UI construction of the Splash screen while establishing foundational rules for Flutter performance and project structure. It demonstrates how to avoid massive widget trees by extracting the screen's body into a dedicated SplashViewBody widget. The instructor provides a crucial deep dive into how Flutter renders widgets, emphasizing the critical importance of const constructors and explaining the immutability of both StatelessWidget and StatefulWidget classes to optimize the application's performance from the very beginning.

Key Ideas

Flutter renders widgets by searching for and executing the nearest build method when a rebuild is triggered.
Massive widget trees inside a single build method degrade performance because the entire tree is re-rendered on any state change.
Extracting complex or nested UI into smaller, separate widgets keeps code readable and localizes rebuilds.
Sub-components specific to a view are organized in a widgets subdirectory (e.g., presentation/views/widgets/) to keep the architectural layers organized.
const constructors prevent Flutter from needlessly recreating widget instances during rebuilds, significantly boosting performance.
StatelessWidget is intrinsically @immutable, meaning its configuration cannot change after initialization.
StatefulWidget itself is also @immutable; the mutable data is strictly managed within its separate State object.

Code Snippets

The extracted body widget for the Splash screen, kept small and immutable in widgets/splash_view_body.dart.dart

import 'package:flutter/material.dart';

class SplashViewBody extends StatelessWidget {
  const SplashViewBody({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Column();
  }
}

The main SplashView, kept clean and utilizing the const constructor for the body in views/splash_view.dart.dart

import 'package:bookly/Features/Splash/presentation/views/widgets/splash_view_body.dart';
import 'package:flutter/material.dart';

class SplashView extends StatelessWidget {
  const SplashView({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return const Scaffold(
      body: SplashViewBody(),
    );
  }
}

My Notes

Performance vs. Readability: Extracting SplashViewBody achieves both. By breaking down the UI, you limit the blast radius of potential rebuilds while keeping the parent Scaffold highly readable.
The `@immutable` Gotcha: The point made about StatefulWidget being immutable is an excellent concept that trips up many developers. The widget class itself is just a configuration blueprint; only its attached State object holds mutable data. Because the widget blueprint is immutable, you can (and should) still use const constructors for StatefulWidget instances whenever their initial parameters are static.
Folder Structure: Nesting sub-widgets in presentation/views/widgets is standard practice. It prevents the main views folder from turning into a dumping ground for hundreds of granular component files.