Styles part one

Presentation (Building the UI)

18:06

Summary

This lesson focuses on building a centralized typography system for the application. The instructor demonstrates creating an abstract Styles class containing static constant TextStyle definitions. A key takeaway is the advocacy for a size-based naming convention (e.g., textStyle18) over standard semantic names (e.g., titleMedium) to simplify management and reduce ambiguity in custom UI designs.

Key Ideas

Audit design files (Figma/XD) to catalog recurring font sizes, weights, and families before implementing styles.
Create an abstract Styles class to act as a single source of truth for all typography.
Adopt a size-based naming convention for styles (e.g., textStyle18, textStyle30) for immediate developer clarity, avoiding the confusion of abstract semantic names.
Extract raw string literals, such as font family names, into a centralized constants.dart file.
Define all reusable text styles as static const to ensure compile-time evaluation and better performance.
Apply .copyWith() on base styles directly within UI widgets for rare, one-off text variations to prevent bloat in the Styles class.

Code Snippets

constants.dart - Defining font family constantsdart

const kGtSectraFine = 'GT Sectra Fine';

styles.dart - Creating the central Styles classdart

import 'package:flutter/cupertino.dart';
import 'package:bookly/constants.dart'; // Adjust import path

abstract class Styles {
static const textStyle18 = TextStyle(
fontSize: 18,
fontWeight: FontWeight.w600, // Semi-bold
);

static const textStyle30 = TextStyle(
fontSize: 30,
fontWeight: FontWeight.normal,
fontFamily: kGtSectraFine,
);
}

Architecture Insight

Architecture insight

A central Styles class is a presentation-layer detail. Domain entities never carry styling — a Book entity doesn't know what color its title is, what font it uses, or whether it's bold. If you ever feel pulled to put a TextStyle on an entity (or worse, a model), stop — that's a layer leak.

The size-based naming the instructor advocates (textStyle18) is a workflow choice, not an architectural one. Both size-based and semantic naming (headlineSmall, bodyLarge) are CA-compatible — pick the one your team will actually maintain.

My Notes

[Editor's note] The Naming Convention Debate

The most significant architectural decision in this lesson is the deliberate departure from semantic style naming (like Material's titleLarge or bodyMedium) in favor of explicit, size-based naming (e.g., textStyle18).

Why depart from standard practice? The instructor correctly argues that in highly custom UI designs, semantic naming quickly becomes unwieldy. You often end up with multiple variations of a "body" text that only differ slightly in weight or spacing, leading to confusing and long variable names.
The Pragmatic Approach: Naming by size maps perfectly to developer workflows. When inspecting a Figma file and seeing a font size of 18px, a developer instinctively reaches for Styles.textStyle18.
Managing Variations: If a specific size has multiple common weights (e.g., regular and bold 18px), create explicit entries for them. However, if a design calls for a rare variation (e.g., size 18 but italicized just once in the entire app), use the base style and apply .copyWith(fontStyle: FontStyle.italic) locally within the widget. This strategy keeps the central Styles class lean and strictly for highly reusable assets.