Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Why declarative UI frameworks?

Why declarative UI frameworks?

In this talk I show you how traditional (imperative) UI frameworks work. We look at the implications of a component tree and its modification during runtime with regard to maintainability of your code. After that, we turn to declarative UI frameworks. We learn about their advantages over the classic approach, but also visit potential obstacles and pitfalls. All examples are based on the same use case, a simple click counter. Examples are presented in Java, JavaScript, Kotlin (Jetpack Compose), Swift (SwiftUI), and Dart (Flutter).

This talk was held during the online event betterCode() Flutter.

6233177bc63ec02060206adef9108601?s=128

Thomas Künneth

May 24, 2022
Tweet

More Decks by Thomas Künneth

Other Decks in Programming

Transcript

  1. Why declarative UI frameworks? Thomas Künneth, Snapp Mobile Sven Mieke

    https://unsplash.com/photos/fteR0e2BzKo
  2. Ibrahim Boran https://unsplash.com/photos/iYkqHp5cGQ4 What‘s wrong with existing UI frameworks?

  3. Provide an app frame Build a component tree Update UI

    based on data
  4. Define state Modify state and update UI Create and configure

    components
  5. Define state Modify state Update UI based on state Connect

    code to the UI tree
  6. Declare a tree of components Define parts of visual appearance

    Connect UI elements to code
  7. • Separation of UI definition and interaction handling ... •

    ... unclutters the code, making it easier to read and maintain • ... allows designers to create (parts of) the UI • Became popular in many UI frameworks
  8. • User interface still represented as a (component) tree ...

    • ... loaded at program startup • ... kept during execution • UI changes still implemented through … • … modifying properties • … changing the structure of the tree
  9. • Changing the UI necessary • when data shown to

    the user changes • upon navigation • Data and component tree live on their own • Important to keep both in sync Larisa Birta https://unsplash.com/photos/slbOcNlWNHA
  10. Claudio Schwarz https://unsplash.com/photos/qjX0QBtDXto Almos Bechtold https://unsplash.com/photos/AJ_Mou1FUS8 manually with magic

  11. • To modify components, references must be maintained • Change

    may occur in different layers of the app (or on a different thread) • All this can lead to • difficult to find and fix bugs • spaghetti code • ... • Design patterns help mitigate such effects (MVC, MVVM, MVP, ...) Paolo Chiabrando https://unsplash.com/photos/3jt-1Va2eZo
  12. • UI frameworks learned to sync app and UI data

    through a binding mechanism • Read-only components just need one way bindings • Components with user interaction require two way binding zip_code Zip code
  13. Any change to the UI must be explicitly coded, either

    by changing component properties, or by modifying the tree itself Levi Meir Clancy https://unsplash.com/photos/KbPVj7knbTU
  14. Ryunosuke Kikuno https://unsplash.com/photos/KnQ980sdlqU Works well in small projects, but doesn‘t

    really scale
  15. George Rosema https://unsplash.com/photos/yg8pLPTAY8M Declarative UI frameworks

  16. Tell React to render a component The component is based

    on state Declaration of the UI is based on state State changes are wrapped inside setState()
  17. A property wrapper Declaration of the UI is based on

    state State changes have no special syntax
  18. State is created and remembered Declaration of the UI is

    based on state State changes have no special syntax
  19. Based upon stateless or stateful widgets Stateless widgets declare UI

    inside build() Stateful widgets createState()
  20. • Declaration of the UI is based on state •

    Can be extracted into other methods for better reuse and readability State changes are wrapped inside setState() Stateless widgets have build(), too
  21. Declaration of the UI is based on state Simple styling

    based on parameters Complex styling based on composition over inheritance
  22. • User interface is declared based on state • No

    need to modify (transform) the existing component tree • UI updates itself upon state changes
  23. Alen Jacob https://unsplash.com/photos/wdxb9OOMQOs • Frameworks maintain internal representation of the

    user interface • Must make sure that state changes trigger updates • (Should be) irrelevant for the application developer • ... it is most of the time ...
  24. Composition over inheritance

  25. • Traditional UI frameworks are based on components • A

    component has a fixed set of properties to configure appearance and behaviour • Inheritance is used to modify or expand both • Several parents possible only with multiple inheritance
  26. • Declarative UI fromeworks may rely on components, too •

    They may even rely on properties to define appearance and behavior • But they favour combining small, reusable building blocks over inheritance
  27. None
  28. None
  29. Markus Spiske https://unsplash.com/photos/uqeaZXZkquw • UI is declared based on state

    • No need to keep references to UI elements to change properties or the tree • Composition over inheritance
  30. Markus Spiske https://unsplash.com/photos/uqeaZXZkquw • A lot of magic under the

    hood • No easy way to inspect UI hierarchy during runtime • Larger UIs lead to large amounts of code
  31. Markus Spiske https://unsplash.com/photos/uqeaZXZkquw • Declarative UIs still require careful coding

    • We still required established patterns to organize the code base • It is fun using them
  32. Thank you! thomas@thomaskuenneth.eu @tkuenneth @tkuenneth https://www.thomaskuenneth.eu/ @tkuenneth