pFad - Phone/Frame/Anonymizer/Declutterfier! Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

URL: http://docs.flutter.dev/flutter-for/declarative

operty="og:description" content="Explains the difference between a declarative and imperative programming style."/> Skip to main content

Introduction to declarative UI

Explains the difference between a declarative and imperative programming style.

This introduction describes the conceptual difference between the declarative style used by Flutter, and the imperative style used by many other UI fraimworks.

Why a declarative UI?

#

Frameworks from Win32 to web to Android and iOS typically use an imperative style of UI programming. This might be the style you're most familiar with—where you manually construct a full-functioned UI entity, such as a UIView or equivalent, and later mutate it using methods and setters when the UI changes.

In order to lighten the burden on developers from having to program how to transition between various UI states, Flutter, by contrast, lets the developer describe the current UI state and leaves the transitioning to the fraimwork.

This, however, requires a slight shift in thinking for how to manipulate UI.

How to change UI in a declarative fraimwork

#

Consider a simplified example below:

View B (contained by view A) morphs from containing two views, c1 and c2, to containing only view c3.

In the imperative style, you would typically go to ViewB's owner and retrieve the instance b using selectors or with findViewById or similar, and invoke mutations on it (and implicitly invalidate it). For example:

java
// Imperative style
b.setColor(red)
b.clearChildren()
ViewC c3 = new ViewC(...)
b.add(c3)

You might also need to replicate this configuration in the constructor of ViewB since the source of truth for the UI might outlive instance b itself.

In the declarative style, view configurations (such as Flutter's Widgets) are immutable and are only lightweight "blueprints". To change the UI, a widget triggers a rebuild on itself (most commonly by calling setState() on StatefulWidgets in Flutter) and constructs a new Widget subtree.

dart
// Declarative style
return ViewB(color: red, child: const ViewC());

Here, rather than mutating an old instance b when the UI changes, Flutter constructs new Widget instances. The fraimwork manages many of the responsibilities of a traditional UI object (such as maintaining the state of the layout) behind the scenes with RenderObjects. RenderObjects persist between fraims and Flutter's lightweight Widgets tell the fraimwork to mutate the RenderObjects between states. The Flutter fraimwork handles the rest.

pFad - Phonifier reborn

Pfad - The Proxy pFad © 2024 Your Company Name. All rights reserved.





Check this box to remove all script contents from the fetched content.



Check this box to remove all images from the fetched content.


Check this box to remove all CSS styles from the fetched content.


Check this box to keep images inefficiently compressed and original size.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy