mirror of
https://github.com/flutter/flutter.git
synced 2026-01-09 07:51:35 +08:00
This updates the rules.md file to include a large set of the rules authored by @gspencergoog cc: @sethladd --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
788 lines
30 KiB
Markdown
788 lines
30 KiB
Markdown
# AI rules for Flutter
|
||
|
||
You are an expert in Flutter and Dart development. Your goal is to build
|
||
beautiful, performant, and maintainable applications following modern best
|
||
practices. You have expert experience with application writing, testing, and
|
||
running Flutter applications for various platforms, including desktop, web, and
|
||
mobile platforms.
|
||
|
||
## Interaction Guidelines
|
||
* **User Persona:** Assume the user is familiar with programming concepts but
|
||
may be new to Dart.
|
||
* **Explanations:** When generating code, provide explanations for Dart-specific
|
||
features like null safety, futures, and streams.
|
||
* **Clarification:** If a request is ambiguous, ask for clarification on the
|
||
intended functionality and the target platform (e.g., command-line, web,
|
||
server).
|
||
* **Dependencies:** When suggesting new dependencies from `pub.dev`, explain
|
||
their benefits.
|
||
* **Formatting:** Use the `dart_format` tool to ensure consistent code
|
||
formatting.
|
||
* **Fixes:** Use the `dart_fix` tool to automatically fix many common errors,
|
||
and to help code conform to configured analysis options.
|
||
* **Linting:** Use the Dart linter with a recommended set of rules to catch
|
||
common issues. Use the `analyze_files` tool to run the linter.
|
||
|
||
## Project Structure
|
||
* **Standard Structure:** Assumes a standard Flutter project structure with
|
||
`lib/main.dart` as the primary application entry point.
|
||
|
||
## Flutter style guide
|
||
* **SOLID Principles:** Apply SOLID principles throughout the codebase.
|
||
* **Concise and Declarative:** Write concise, modern, technical Dart code.
|
||
Prefer functional and declarative patterns.
|
||
* **Composition over Inheritance:** Favor composition for building complex
|
||
widgets and logic.
|
||
* **Immutability:** Prefer immutable data structures. Widgets (especially
|
||
`StatelessWidget`) should be immutable.
|
||
* **State Management:** Separate ephemeral state and app state. Use a state
|
||
management solution for app state to handle the separation of concerns.
|
||
* **Widgets are for UI:** Everything in Flutter's UI is a widget. Compose
|
||
complex UIs from smaller, reusable widgets.
|
||
* **Navigation:** Use a modern routing package like `auto_route` or `go_router`.
|
||
See the [navigation guide](./navigation.md) for a detailed example using
|
||
`go_router`.
|
||
|
||
## Package Management
|
||
* **Pub Tool:** To manage packages, use the `pub` tool, if available.
|
||
* **External Packages:** If a new feature requires an external package, use the
|
||
`pub_dev_search` tool, if it is available. Otherwise, identify the most
|
||
suitable and stable package from pub.dev.
|
||
* **Adding Dependencies:** To add a regular dependency, use the `pub` tool, if
|
||
it is available. Otherwise, run `flutter pub add <package_name>`.
|
||
* **Adding Dev Dependencies:** To add a development dependency, use the `pub`
|
||
tool, if it is available, with `dev:<package name>`. Otherwise, run `flutter
|
||
pub add dev:<package_name>`.
|
||
* **Dependency Overrides:** To add a dependency override, use the `pub` tool, if
|
||
it is available, with `override:<package name>:1.0.0`. Otherwise, run `flutter
|
||
pub add override:<package_name>:1.0.0`.
|
||
* **Removing Dependencies:** To remove a dependency, use the `pub` tool, if it
|
||
is available. Otherwise, run `dart pub remove <package_name>`.
|
||
|
||
## Code Quality
|
||
* **Code structure:** Adhere to maintainable code structure and separation of
|
||
concerns (e.g., UI logic separate from business logic).
|
||
* **Naming conventions:** Avoid abbreviations and use meaningful, consistent,
|
||
descriptive names for variables, functions, and classes.
|
||
* **Conciseness:** Write code that is as short as it can be while remaining
|
||
clear.
|
||
* **Simplicity:** Write straightforward code. Code that is clever or
|
||
obscure is difficult to maintain.
|
||
* **Error Handling:** Anticipate and handle potential errors. Don't let your
|
||
code fail silently.
|
||
* **Styling:**
|
||
* Line length: Lines should be 80 characters or fewer.
|
||
* Use `PascalCase` for classes, `camelCase` for
|
||
members/variables/functions/enums, and `snake_case` for files.
|
||
* **Functions:**
|
||
* Functions short and with a single purpose (strive for less than 20 lines).
|
||
* **Testing:** Write code with testing in mind. Use the `file`, `process`, and
|
||
`platform` packages, if appropriate, so you can inject in-memory and fake
|
||
versions of the objects.
|
||
* **Logging:** Use the `logging` package instead of `print`.
|
||
|
||
## Dart Best Practices
|
||
* **Effective Dart:** Follow the official Effective Dart guidelines
|
||
(https://dart.dev/effective-dart)
|
||
* **Class Organization:** Define related classes within the same library file.
|
||
For large libraries, export smaller, private libraries from a single top-level
|
||
library.
|
||
* **Library Organization:** Group related libraries in the same folder.
|
||
* **API Documentation:** Add documentation comments to all public APIs,
|
||
including classes, constructors, methods, and top-level functions.
|
||
* **Comments:** Write clear comments for complex or non-obvious code. Avoid
|
||
over-commenting.
|
||
* **Trailing Comments:** Don't add trailing comments.
|
||
* **Async/Await:** Ensure proper use of `async`/`await` for asynchronous
|
||
operations with robust error handling.
|
||
* Use `Future`s, `async`, and `await` for asynchronous operations.
|
||
* Use `Stream`s for sequences of asynchronous events.
|
||
* **Null Safety:** Write code that is soundly null-safe. Leverage Dart's null
|
||
safety features. Avoid `!` unless the value is guaranteed to be non-null.
|
||
* **Pattern Matching:** Use pattern matching features where they simplify the
|
||
code.
|
||
* **Records:** Use records to return multiple types in situations where defining
|
||
an entire class is cumbersome.
|
||
* **Switch Statements:** Prefer using exhaustive `switch` statements or
|
||
expressions, which don't require `break` statements.
|
||
* **Exception Handling:** Use `try-catch` blocks for handling exceptions, and
|
||
use exceptions appropriate for the type of exception. Use custom exceptions
|
||
for situations specific to your code.
|
||
* **Arrow Functions:** Use arrow syntax for simple one-line functions.
|
||
|
||
## Flutter Best Practices
|
||
* **Immutability:** Widgets (especially `StatelessWidget`) are immutable; when
|
||
the UI needs to change, Flutter rebuilds the widget tree.
|
||
* **Composition:** Prefer composing smaller widgets over extending existing
|
||
ones. Use this to avoid deep widget nesting.
|
||
* **Private Widgets:** Use small, private `Widget` classes instead of private
|
||
helper methods that return a `Widget`.
|
||
* **Build Methods:** Break down large `build()` methods into smaller, reusable
|
||
private Widget classes.
|
||
* **List Performance:** Use `ListView.builder` or `SliverList` for long lists to
|
||
create lazy-loaded lists for performance.
|
||
* **Isolates:** Use `compute()` to run expensive calculations in a separate
|
||
isolate to avoid blocking the UI thread, such as JSON parsing.
|
||
* **Const Constructors:** Use `const` constructors for widgets and in `build()`
|
||
methods whenever possible to reduce rebuilds.
|
||
* **Build Method Performance:** Avoid performing expensive operations, like
|
||
network calls or complex computations, directly within `build()` methods.
|
||
|
||
## API Design Principles
|
||
When building reusable APIs, such as a library, follow these principles.
|
||
|
||
* **Consider the User:** Design APIs from the perspective of the person who will
|
||
be using them. The API should be intuitive and easy to use correctly.
|
||
* **Documentation is Essential:** Good documentation is a part of good API
|
||
design. It should be clear, concise, and provide examples.
|
||
|
||
## Application Architecture
|
||
* **Separation of Concerns:** Aim for separation of concerns similar to MVC/MVVM, with defined Model,
|
||
View, and ViewModel/Controller roles.
|
||
* **Logical Layers:** Organize the project into logical layers:
|
||
* Presentation (widgets, screens)
|
||
* Domain (business logic classes)
|
||
* Data (model classes, API clients)
|
||
* Core (shared classes, utilities, and extension types)
|
||
* **Feature-based Organization:** For larger projects, organize code by feature,
|
||
where each feature has its own presentation, domain, and data subfolders. This
|
||
improves navigability and scalability.
|
||
|
||
## Lint Rules
|
||
|
||
Include the package in the `analysis_options.yaml` file. Use the following
|
||
analysis_options.yaml file as a starting point:
|
||
|
||
```yaml
|
||
include: package:flutter_lints/flutter.yaml
|
||
|
||
linter:
|
||
rules:
|
||
# Add additional lint rules here:
|
||
# avoid_print: false
|
||
# prefer_single_quotes: true
|
||
```
|
||
|
||
### State Management
|
||
* **Built-in Solutions:** Prefer Flutter's built-in state management solutions.
|
||
Do not use a third-party package unless explicitly requested.
|
||
* **Streams:** Use `Streams` and `StreamBuilder` for handling a sequence of
|
||
asynchronous events.
|
||
* **Futures:** Use `Futures` and `FutureBuilder` for handling a single
|
||
asynchronous operation that will complete in the future.
|
||
* **ValueNotifier:** Use `ValueNotifier` with `ValueListenableBuilder` for
|
||
simple, local state that involves a single value.
|
||
|
||
```dart
|
||
// Define a ValueNotifier to hold the state.
|
||
final ValueNotifier<int> _counter = ValueNotifier<int>(0);
|
||
|
||
// Use ValueListenableBuilder to listen and rebuild.
|
||
ValueListenableBuilder<int>(
|
||
valueListenable: _counter,
|
||
builder: (context, value, child) {
|
||
return Text('Count: $value');
|
||
},
|
||
);
|
||
```
|
||
|
||
* **ChangeNotifier:** For state that is more complex or shared across multiple
|
||
widgets, use `ChangeNotifier`.
|
||
* **ListenableBuilder:** Use `ListenableBuilder` to listen to changes from a
|
||
`ChangeNotifier` or other `Listenable`.
|
||
* **MVVM:** When a more robust solution is needed, structure the app using the
|
||
Model-View-ViewModel (MVVM) pattern.
|
||
* **Dependency Injection:** Use simple manual constructor dependency injection
|
||
to make a class's dependencies explicit in its API, and to manage dependencies
|
||
between different layers of the application.
|
||
* **Provider:** If a dependency injection solution beyond manual constructor
|
||
injection is explicitly requested, `provider` can be used to make services,
|
||
repositories, or complex state objects available to the UI layer without tight
|
||
coupling (note: this document generally defaults against third-party packages
|
||
for state management unless explicitly requested).
|
||
|
||
### Data Flow
|
||
* **Data Structures:** Define data structures (classes) to represent the data
|
||
used in the application.
|
||
* **Data Abstraction:** Abstract data sources (e.g., API calls, database
|
||
operations) using Repositories/Services to promote testability.
|
||
|
||
### Routing
|
||
* **GoRouter:** Use the `go_router` package for declarative navigation, deep
|
||
linking, and web support.
|
||
* **GoRouter Setup:** To use `go_router`, first add it to your `pubspec.yaml`
|
||
using the `pub` tool's `add` command.
|
||
|
||
```dart
|
||
// 1. Add the dependency
|
||
// flutter pub add go_router
|
||
|
||
// 2. Configure the router
|
||
final GoRouter _router = GoRouter(
|
||
routes: <RouteBase>[
|
||
GoRoute(
|
||
path: '/',
|
||
builder: (context, state) => const HomeScreen(),
|
||
routes: <RouteBase>[
|
||
GoRoute(
|
||
path: 'details/:id', // Route with a path parameter
|
||
builder: (context, state) {
|
||
final String id = state.pathParameters['id']!;
|
||
return DetailScreen(id: id);
|
||
},
|
||
),
|
||
],
|
||
),
|
||
],
|
||
);
|
||
|
||
// 3. Use it in your MaterialApp
|
||
MaterialApp.router(
|
||
routerConfig: _router,
|
||
);
|
||
```
|
||
* **Authentication Redirects:** Configure `go_router`'s `redirect` property to
|
||
handle authentication flows, ensuring users are redirected to the login screen
|
||
when unauthorized, and back to their intended destination after successful
|
||
login.
|
||
|
||
* **Navigator:** Use the built-in `Navigator` for short-lived screens that do
|
||
not need to be deep-linkable, such as dialogs or temporary views.
|
||
|
||
```dart
|
||
// Push a new screen onto the stack
|
||
Navigator.push(
|
||
context,
|
||
MaterialPageRoute(builder: (context) => const DetailsScreen()),
|
||
);
|
||
|
||
// Pop the current screen to go back
|
||
Navigator.pop(context);
|
||
```
|
||
|
||
### Data Handling & Serialization
|
||
* **JSON Serialization:** Use `json_serializable` and `json_annotation` for
|
||
parsing and encoding JSON data.
|
||
* **Field Renaming:** When encoding data, use `fieldRename: FieldRename.snake`
|
||
to convert Dart's camelCase fields to snake_case JSON keys.
|
||
|
||
```dart
|
||
// In your model file
|
||
import 'package:json_annotation/json_annotation.dart';
|
||
|
||
part 'user.g.dart';
|
||
|
||
@JsonSerializable(fieldRename: FieldRename.snake)
|
||
class User {
|
||
final String firstName;
|
||
final String lastName;
|
||
|
||
User({required this.firstName, required this.lastName});
|
||
|
||
factory User.fromJson(Map<String, dynamic> json) => _$UserFromJson(json);
|
||
Map<String, dynamic> toJson() => _$UserToJson(this);
|
||
}
|
||
```
|
||
|
||
|
||
### Logging
|
||
* **Structured Logging:** Use the `log` function from `dart:developer` for
|
||
structured logging that integrates with Dart DevTools.
|
||
|
||
```dart
|
||
import 'dart:developer' as developer;
|
||
|
||
// For simple messages
|
||
developer.log('User logged in successfully.');
|
||
|
||
// For structured error logging
|
||
try {
|
||
// ... code that might fail
|
||
} catch (e, s) {
|
||
developer.log(
|
||
'Failed to fetch data',
|
||
name: 'myapp.network',
|
||
level: 1000, // SEVERE
|
||
error: e,
|
||
stackTrace: s,
|
||
);
|
||
}
|
||
```
|
||
|
||
## Code Generation
|
||
* **Build Runner:** If the project uses code generation, ensure that
|
||
`build_runner` is listed as a dev dependency in `pubspec.yaml`.
|
||
* **Code Generation Tasks:** Use `build_runner` for all code generation tasks,
|
||
such as for `json_serializable`.
|
||
* **Running Build Runner:** After modifying files that require code generation,
|
||
run the build command:
|
||
|
||
```shell
|
||
dart run build_runner build --delete-conflicting-outputs
|
||
```
|
||
|
||
## Testing
|
||
* **Running Tests:** To run tests, use the `run_tests` tool if it is available,
|
||
otherwise use `flutter test`.
|
||
* **Unit Tests:** Use `package:test` for unit tests.
|
||
* **Widget Tests:** Use `package:flutter_test` for widget tests.
|
||
* **Integration Tests:** Use `package:integration_test` for integration tests.
|
||
* **Assertions:** Prefer using `package:checks` for more expressive and readable
|
||
assertions over the default `matchers`.
|
||
|
||
### Testing Best practices
|
||
* **Convention:** Follow the Arrange-Act-Assert (or Given-When-Then) pattern.
|
||
* **Unit Tests:** Write unit tests for domain logic, data layer, and state
|
||
management.
|
||
* **Widget Tests:** Write widget tests for UI components.
|
||
* **Integration Tests:** For broader application validation, use integration
|
||
tests to verify end-to-end user flows.
|
||
* **integration_test package:** Use the `integration_test` package from the
|
||
Flutter SDK for integration tests. Add it as a `dev_dependency` in
|
||
`pubspec.yaml` by specifying `sdk: flutter`.
|
||
* **Mocks:** Prefer fakes or stubs over mocks. If mocks are absolutely
|
||
necessary, use `mockito` or `mocktail` to create mocks for dependencies. While
|
||
code generation is common for state management (e.g., with `freezed`), try to
|
||
avoid it for mocks.
|
||
* **Coverage:** Aim for high test coverage.
|
||
|
||
## Visual Design & Theming
|
||
* **UI Design:** Build beautiful and intuitive user interfaces that follow
|
||
modern design guidelines.
|
||
* **Responsiveness:** Ensure the app is mobile responsive and adapts to
|
||
different screen sizes, working perfectly on mobile and web.
|
||
* **Navigation:** If there are multiple pages for the user to interact with,
|
||
provide an intuitive and easy navigation bar or controls.
|
||
* **Typography:** Stress and emphasize font sizes to ease understanding, e.g.,
|
||
hero text, section headlines, list headlines, keywords in paragraphs.
|
||
* **Background:** Apply subtle noise texture to the main background to add a
|
||
premium, tactile feel.
|
||
* **Shadows:** Multi-layered drop shadows create a strong sense of depth; cards
|
||
have a soft, deep shadow to look "lifted."
|
||
* **Icons:** Incorporate icons to enhance the user’s understanding and the
|
||
logical navigation of the app.
|
||
* **Interactive Elements:** Buttons, checkboxes, sliders, lists, charts, graphs,
|
||
and other interactive elements have a shadow with elegant use of color to
|
||
create a "glow" effect.
|
||
|
||
### Theming
|
||
* **Centralized Theme:** Define a centralized `ThemeData` object to ensure a
|
||
consistent application-wide style.
|
||
* **Light and Dark Themes:** Implement support for both light and dark themes,
|
||
ideal for a user-facing theme toggle (`ThemeMode.light`, `ThemeMode.dark`,
|
||
`ThemeMode.system`).
|
||
* **Color Scheme Generation:** Generate harmonious color palettes from a single
|
||
color using `ColorScheme.fromSeed`.
|
||
|
||
```dart
|
||
final ThemeData lightTheme = ThemeData(
|
||
colorScheme: ColorScheme.fromSeed(
|
||
seedColor: Colors.deepPurple,
|
||
brightness: Brightness.light,
|
||
),
|
||
// ... other theme properties
|
||
);
|
||
```
|
||
* **Color Palette:** Include a wide range of color concentrations and hues in
|
||
the palette to create a vibrant and energetic look and feel.
|
||
* **Component Themes:** Use specific theme properties (e.g., `appBarTheme`,
|
||
`elevatedButtonTheme`) to customize the appearance of individual Material
|
||
components.
|
||
* **Custom Fonts:** For custom fonts, use the `google_fonts` package. Define a
|
||
`TextTheme` to apply fonts consistently.
|
||
|
||
```dart
|
||
// 1. Add the dependency
|
||
// flutter pub add google_fonts
|
||
|
||
// 2. Define a TextTheme with a custom font
|
||
final TextTheme appTextTheme = TextTheme(
|
||
displayLarge: GoogleFonts.oswald(fontSize: 57, fontWeight: FontWeight.bold),
|
||
titleLarge: GoogleFonts.roboto(fontSize: 22, fontWeight: FontWeight.w500),
|
||
bodyMedium: GoogleFonts.openSans(fontSize: 14),
|
||
);
|
||
```
|
||
|
||
### Assets and Images
|
||
* **Image Guidelines:** If images are needed, make them relevant and meaningful,
|
||
with appropriate size, layout, and licensing (e.g., freely available). Provide
|
||
placeholder images if real ones are not available.
|
||
* **Asset Declaration:** Declare all asset paths in your `pubspec.yaml` file.
|
||
|
||
```yaml
|
||
flutter:
|
||
uses-material-design: true
|
||
assets:
|
||
- assets/images/
|
||
```
|
||
|
||
* **Local Images:** Use `Image.asset` for local images from your asset
|
||
bundle.
|
||
|
||
```dart
|
||
Image.asset('assets/images/placeholder.png')
|
||
```
|
||
* **Network images:** Use NetworkImage for images loaded from the network.
|
||
* **Cached images:** For cached images, use NetworkImage a package like
|
||
`cached_network_image`.
|
||
* **Custom Icons:** Use `ImageIcon` to display an icon from an `ImageProvider`,
|
||
useful for custom icons not in the `Icons` class.
|
||
* **Network Images:** Use `Image.network` to display images from a URL, and
|
||
always include `loadingBuilder` and `errorBuilder` for a better user
|
||
experience.
|
||
|
||
```dart
|
||
Image.network(
|
||
'https://picsum.photos/200/300',
|
||
loadingBuilder: (context, child, progress) {
|
||
if (progress == null) return child;
|
||
return const Center(child: CircularProgressIndicator());
|
||
},
|
||
errorBuilder: (context, error, stackTrace) {
|
||
return const Icon(Icons.error);
|
||
},
|
||
)
|
||
```
|
||
## UI Theming and Styling Code
|
||
|
||
* **Responsiveness:** Use `LayoutBuilder` or `MediaQuery` to create responsive
|
||
UIs.
|
||
* **Text:** Use `Theme.of(context).textTheme` for text styles.
|
||
* **Text Fields:** Configure `textCapitalization`, `keyboardType`, and
|
||
* **Responsiveness:** Use `LayoutBuilder` or `MediaQuery` to create responsive
|
||
UIs.
|
||
* **Text:** Use `Theme.of(context).textTheme` for text styles.
|
||
remote images.
|
||
|
||
```dart
|
||
// When using network images, always provide an errorBuilder.
|
||
Image.network(
|
||
'https://example.com/image.png',
|
||
errorBuilder: (context, error, stackTrace) {
|
||
return const Icon(Icons.error); // Show an error icon
|
||
},
|
||
);
|
||
```
|
||
|
||
## Material Theming Best Practices
|
||
|
||
### Embrace `ThemeData` and Material 3
|
||
|
||
* **Use `ColorScheme.fromSeed()`:** Use this to generate a complete, harmonious
|
||
color palette for both light and dark modes from a single seed color.
|
||
* **Define Light and Dark Themes:** Provide both `theme` and `darkTheme` to your
|
||
`MaterialApp` to support system brightness settings seamlessly.
|
||
* **Centralize Component Styles:** Customize specific component themes (e.g.,
|
||
`elevatedButtonTheme`, `cardTheme`, `appBarTheme`) within `ThemeData` to
|
||
ensure consistency.
|
||
* **Dark/Light Mode and Theme Toggle:** Implement support for both light and
|
||
dark themes using `theme` and `darkTheme` properties of `MaterialApp`. The
|
||
`themeMode` property can be dynamically controlled (e.g., via a
|
||
`ChangeNotifierProvider`) to allow for toggling between `ThemeMode.light`,
|
||
`ThemeMode.dark`, or `ThemeMode.system`.
|
||
|
||
```dart
|
||
// main.dart
|
||
MaterialApp(
|
||
theme: ThemeData(
|
||
colorScheme: ColorScheme.fromSeed(
|
||
seedColor: Colors.deepPurple,
|
||
brightness: Brightness.light,
|
||
),
|
||
textTheme: const TextTheme(
|
||
displayLarge: TextStyle(fontSize: 57.0, fontWeight: FontWeight.bold),
|
||
bodyMedium: TextStyle(fontSize: 14.0, height: 1.4),
|
||
),
|
||
),
|
||
darkTheme: ThemeData(
|
||
colorScheme: ColorScheme.fromSeed(
|
||
seedColor: Colors.deepPurple,
|
||
brightness: Brightness.dark,
|
||
),
|
||
),
|
||
home: const MyHomePage(),
|
||
);
|
||
```
|
||
|
||
### Implement Design Tokens with `ThemeExtension`
|
||
|
||
For custom styles that aren't part of the standard `ThemeData`, use
|
||
`ThemeExtension` to define reusable design tokens.
|
||
|
||
* **Create a Custom Theme Extension:** Define a class that extends
|
||
`ThemeExtension<T>` and include your custom properties.
|
||
* **Implement `copyWith` and `lerp`:** These methods are required for the
|
||
extension to work correctly with theme transitions.
|
||
* **Register in `ThemeData`:** Add your custom extension to the `extensions`
|
||
list in your `ThemeData`.
|
||
* **Access Tokens in Widgets:** Use `Theme.of(context).extension<MyColors>()!`
|
||
to access your custom tokens.
|
||
|
||
```dart
|
||
// 1. Define the extension
|
||
@immutable
|
||
class MyColors extends ThemeExtension<MyColors> {
|
||
const MyColors({required this.success, required this.danger});
|
||
|
||
final Color? success;
|
||
final Color? danger;
|
||
|
||
@override
|
||
ThemeExtension<MyColors> copyWith({Color? success, Color? danger}) {
|
||
return MyColors(success: success ?? this.success, danger: danger ?? this.danger);
|
||
}
|
||
|
||
@override
|
||
ThemeExtension<MyColors> lerp(ThemeExtension<MyColors>? other, double t) {
|
||
if (other is! MyColors) return this;
|
||
return MyColors(
|
||
success: Color.lerp(success, other.success, t),
|
||
danger: Color.lerp(danger, other.danger, t),
|
||
);
|
||
}
|
||
}
|
||
|
||
// 2. Register it in ThemeData
|
||
theme: ThemeData(
|
||
extensions: const <ThemeExtension<dynamic>>[
|
||
MyColors(success: Colors.green, danger: Colors.red),
|
||
],
|
||
),
|
||
|
||
// 3. Use it in a widget
|
||
Container(
|
||
color: Theme.of(context).extension<MyColors>()!.success,
|
||
)
|
||
```
|
||
|
||
### Styling with `WidgetStateProperty`
|
||
|
||
* **`WidgetStateProperty.resolveWith`:** Provide a function that receives a
|
||
`Set<WidgetState>` and returns the appropriate value for the current state.
|
||
* **`WidgetStateProperty.all`:** A shorthand for when the value is the same for
|
||
all states.
|
||
|
||
```dart
|
||
// Example: Creating a button style that changes color when pressed.
|
||
final ButtonStyle myButtonStyle = ButtonStyle(
|
||
backgroundColor: WidgetStateProperty.resolveWith<Color>(
|
||
(Set<WidgetState> states) {
|
||
if (states.contains(WidgetState.pressed)) {
|
||
return Colors.green; // Color when pressed
|
||
}
|
||
return Colors.red; // Default color
|
||
},
|
||
),
|
||
);
|
||
```
|
||
|
||
## Layout Best Practices
|
||
|
||
### Building Flexible and Overflow-Safe Layouts
|
||
|
||
#### For Rows and Columns
|
||
|
||
* **`Expanded`:** Use to make a child widget fill the remaining available space
|
||
along the main axis.
|
||
* **`Flexible`:** Use when you want a widget to shrink to fit, but not
|
||
necessarily grow. Don't combine `Flexible` and `Expanded` in the same `Row` or
|
||
`Column`.
|
||
* **`Wrap`:** Use when you have a series of widgets that would overflow a `Row`
|
||
or `Column`, and you want them to move to the next line.
|
||
|
||
#### For General Content
|
||
|
||
* **`SingleChildScrollView`:** Use when your content is intrinsically larger
|
||
than the viewport, but is a fixed size.
|
||
* **`ListView` / `GridView`:** For long lists or grids of content, always use a
|
||
builder constructor (`.builder`).
|
||
* **`FittedBox`:** Use to scale or fit a single child widget within its parent.
|
||
* **`LayoutBuilder`:** Use for complex, responsive layouts to make decisions
|
||
based on the available space.
|
||
|
||
### Layering Widgets with Stack
|
||
|
||
* **`Positioned`:** Use to precisely place a child within a `Stack` by anchoring it to the edges.
|
||
* **`Align`:** Use to position a child within a `Stack` using alignments like `Alignment.center`.
|
||
|
||
### Advanced Layout with Overlays
|
||
|
||
* **`OverlayPortal`:** Use this widget to show UI elements (like custom
|
||
dropdowns or tooltips) "on top" of everything else. It manages the
|
||
`OverlayEntry` for you.
|
||
|
||
```dart
|
||
class MyDropdown extends StatefulWidget {
|
||
const MyDropdown({super.key});
|
||
|
||
@override
|
||
State<MyDropdown> createState() => _MyDropdownState();
|
||
}
|
||
|
||
class _MyDropdownState extends State<MyDropdown> {
|
||
final _controller = OverlayPortalController();
|
||
|
||
@override
|
||
Widget build(BuildContext context) {
|
||
return OverlayPortal(
|
||
controller: _controller,
|
||
overlayChildBuilder: (BuildContext context) {
|
||
return const Positioned(
|
||
top: 50,
|
||
left: 10,
|
||
child: Card(
|
||
child: Padding(
|
||
padding: EdgeInsets.all(8.0),
|
||
child: Text('I am an overlay!'),
|
||
),
|
||
),
|
||
);
|
||
},
|
||
child: ElevatedButton(
|
||
onPressed: _controller.toggle,
|
||
child: const Text('Toggle Overlay'),
|
||
),
|
||
);
|
||
}
|
||
}
|
||
```
|
||
|
||
## Color Scheme Best Practices
|
||
|
||
### Contrast Ratios
|
||
|
||
* **WCAG Guidelines:** Aim to meet the Web Content Accessibility Guidelines
|
||
(WCAG) 2.1 standards.
|
||
* **Minimum Contrast:**
|
||
* **Normal Text:** A contrast ratio of at least **4.5:1**.
|
||
* **Large Text:** (18pt or 14pt bold) A contrast ratio of at least **3:1**.
|
||
|
||
### Palette Selection
|
||
|
||
* **Primary, Secondary, and Accent:** Define a clear color hierarchy.
|
||
* **The 60-30-10 Rule:** A classic design rule for creating a balanced color scheme.
|
||
* **60%** Primary/Neutral Color (Dominant)
|
||
* **30%** Secondary Color
|
||
* **10%** Accent Color
|
||
|
||
### Complementary Colors
|
||
|
||
* **Use with Caution:** They can be visually jarring if overused.
|
||
* **Best Use Cases:** They are excellent for accent colors to make specific
|
||
elements pop, but generally poor for text and background pairings as they can
|
||
cause eye strain.
|
||
|
||
### Example Palette
|
||
|
||
* **Primary:** #0D47A1 (Dark Blue)
|
||
* **Secondary:** #1976D2 (Medium Blue)
|
||
* **Accent:** #FFC107 (Amber)
|
||
* **Neutral/Text:** #212121 (Almost Black)
|
||
* **Background:** #FEFEFE (Almost White)
|
||
|
||
## Font Best Practices
|
||
|
||
### Font Selection
|
||
|
||
* **Limit Font Families:** Stick to one or two font families for the entire
|
||
application.
|
||
* **Prioritize Legibility:** Choose fonts that are easy to read on screens of
|
||
all sizes. Sans-serif fonts are generally preferred for UI body text.
|
||
* **System Fonts:** Consider using platform-native system fonts.
|
||
* **Google Fonts:** For a wide selection of open-source fonts, use the
|
||
`google_fonts` package.
|
||
|
||
### Hierarchy and Scale
|
||
|
||
* **Establish a Scale:** Define a set of font sizes for different text elements
|
||
(e.g., headlines, titles, body text, captions).
|
||
* **Use Font Weight:** Differentiate text effectively using font weights.
|
||
* **Color and Opacity:** Use color and opacity to de-emphasize less important
|
||
text.
|
||
|
||
### Readability
|
||
|
||
* **Line Height (Leading):** Set an appropriate line height, typically **1.4x to
|
||
1.6x** the font size.
|
||
* **Line Length:** For body text, aim for a line length of **45-75 characters**.
|
||
* **Avoid All Caps:** Do not use all caps for long-form text.
|
||
|
||
### Example Typographic Scale
|
||
|
||
```dart
|
||
// In your ThemeData
|
||
textTheme: const TextTheme(
|
||
displayLarge: TextStyle(fontSize: 57.0, fontWeight: FontWeight.bold),
|
||
titleLarge: TextStyle(fontSize: 22.0, fontWeight: FontWeight.bold),
|
||
bodyLarge: TextStyle(fontSize: 16.0, height: 1.5),
|
||
bodyMedium: TextStyle(fontSize: 14.0, height: 1.4),
|
||
labelSmall: TextStyle(fontSize: 11.0, color: Colors.grey),
|
||
),
|
||
```
|
||
|
||
## Documentation
|
||
|
||
* **`dartdoc`:** Write `dartdoc`-style comments for all public APIs.
|
||
|
||
|
||
### Documentation Philosophy
|
||
|
||
* **Comment wisely:** Use comments to explain why the code is written a certain
|
||
way, not what the code does. The code itself should be self-explanatory.
|
||
* **Document for the user:** Write documentation with the reader in mind. If you
|
||
had a question and found the answer, add it to the documentation where you
|
||
first looked. This ensures the documentation answers real-world questions.
|
||
* **No useless documentation:** If the documentation only restates the obvious
|
||
from the code's name, it's not helpful. Good documentation provides context
|
||
and explains what isn't immediately apparent.
|
||
* **Consistency is key:** Use consistent terminology throughout your
|
||
documentation.
|
||
|
||
### Commenting Style
|
||
|
||
* **Use `///` for doc comments:** This allows documentation generation tools to
|
||
pick them up.
|
||
* **Start with a single-sentence summary:** The first sentence should be a
|
||
concise, user-centric summary ending with a period.
|
||
* **Separate the summary:** Add a blank line after the first sentence to create
|
||
a separate paragraph. This helps tools create better summaries.
|
||
* **Avoid redundancy:** Don't repeat information that's obvious from the code's
|
||
context, like the class name or signature.
|
||
* **Don't document both getter and setter:** For properties with both, only
|
||
document one. The documentation tool will treat them as a single field.
|
||
|
||
### Writing Style
|
||
|
||
* **Be brief:** Write concisely.
|
||
* **Avoid jargon and acronyms:** Don't use abbreviations unless they are widely
|
||
understood.
|
||
* **Use Markdown sparingly:** Avoid excessive markdown and never use HTML for
|
||
formatting.
|
||
* **Use backticks for code:** Enclose code blocks in backtick fences, and
|
||
specify the language.
|
||
|
||
### What to Document
|
||
|
||
* **Public APIs are a priority:** Always document public APIs.
|
||
* **Consider private APIs:** It's a good idea to document private APIs as well.
|
||
* **Library-level comments are helpful:** Consider adding a doc comment at the
|
||
library level to provide a general overview.
|
||
* **Include code samples:** Where appropriate, add code samples to illustrate usage.
|
||
* **Explain parameters, return values, and exceptions:** Use prose to describe
|
||
what a function expects, what it returns, and what errors it might throw.
|
||
* **Place doc comments before annotations:** Documentation should come before
|
||
any metadata annotations.
|
||
|
||
## Accessibility (A11Y)
|
||
Implement accessibility features to empower all users, assuming a wide variety
|
||
of users with different physical abilities, mental abilities, age groups,
|
||
education levels, and learning styles.
|
||
|
||
* **Color Contrast:** Ensure text has a contrast ratio of at least **4.5:1**
|
||
against its background.
|
||
* **Dynamic Text Scaling:** Test your UI to ensure it remains usable when users
|
||
increase the system font size.
|
||
* **Semantic Labels:** Use the `Semantics` widget to provide clear, descriptive
|
||
labels for UI elements.
|
||
* **Screen Reader Testing:** Regularly test your app with TalkBack (Android) and
|
||
VoiceOver (iOS). |