Create book details view

Presentation (Building the UI)

09:00

Summary

This lesson focuses on creating the Book Details view and organizing its files within the existing feature-based architecture. The instructor explains why the Book Details screen belongs to the "Home" feature rather than being a standalone feature, emphasizing that related screens should share a single feature folder. Additionally, the lesson provides a critical analysis of the GetX package, detailing why its GetMaterialApp creates risky tight coupling, and concludes with the decision to replace it with a dedicated navigation solution in the upcoming lessons.

Key Ideas

Feature-based architecture groups related screens and logic (e.g., Login and Register in an Authentication feature).
The Book Details view is categorized under the "Home" feature because it shares the same core data context as the Home view.
File naming conventions matter: use suffixes like _view for screens and _view_body for their primary content widgets to simplify IDE navigation.
Placing all application widgets into a single shared folder is a bad practice; widgets should be scoped to their specific feature when possible.
The get package (GetX) suffers from poor documentation, making it difficult to use correctly and discouraging community contributions.
GetMaterialApp wraps and replaces Flutter's native MaterialApp, meaning you must wait for GetX updates to access new native Flutter features.
Using GetX for navigation tightly couples the app to a massive dependency, making it difficult to remove if bugs occur.
The instructor decides to remove GetMaterialApp in favor of a specialized, standalone navigation package.

Code Snippets

Creating the BookDetailsView screendart

import 'package:bookly/features/home/presentation/views/widgets/book_details_view_body.dart';
import 'package:flutter/material.dart';

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

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

Creating the BookDetailsViewBody widgetdart

import 'package:flutter/material.dart';

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

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

Architecture Insight

Architecture insight

Pushing into BookDetailsView raises a question CA can answer two ways:

1. Pass the `Book` from the previous screen. Fast, but the detail view now depends on caller state. 2. Pass an ID, re-fetch by use case. A round trip, but the detail view becomes self-sufficient — deep links work, refresh works, no stale state.

Pure CA leans (2). The instructor uses (1) for now. Both are valid; just be conscious which trade-off you took.

My Notes

Feature Boundaries: The explanation of feature grouping is pragmatic. A "feature" isn't strictly one screen; it's a domain context. Book listing and book details both deal with the core Book domain, so they logically live together in the home feature rather than polluting the root directory.
GetX Criticism: The critique against GetX is highly relevant for Clean Architecture. GetMaterialApp essentially hijacks the native Flutter framework. In Clean Architecture, frameworks should be details that are easily swappable. GetX makes itself the center of the app, which is a massive anti-pattern.
Naming Conventions: The _view and _view_body pattern is a staple. It keeps the Scaffold (the View) separate from the scrollable/layout content (the Body), which makes the Body easily testable and reusable if needed.
[Editor's note]: Switching away from GetX to a dedicated router (like go_router or auto_route) is a necessary step to decouple the presentation layer's navigation from a bloated state-management library.