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.

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

    View Slide

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

    View Slide

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

    View Slide

  4. Define state
    Modify state and update UI
    Create and configure
    components

    View Slide

  5. Define state
    Modify state
    Update UI based on state
    Connect code to the UI tree

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  10. Claudio Schwarz
    https://unsplash.com/photos/qjX0QBtDXto
    Almos Bechtold
    https://unsplash.com/photos/AJ_Mou1FUS8
    manually with magic

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  14. Ryunosuke Kikuno
    https://unsplash.com/photos/KnQ980sdlqU
    Works well in small projects, but doesn‘t
    really scale

    View Slide

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

    View Slide

  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()

    View Slide

  17. A property wrapper
    Declaration of the UI is based on state
    State changes have no special syntax

    View Slide

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

    View Slide

  19. Based upon stateless or stateful widgets
    Stateless widgets declare UI inside build()
    Stateful widgets createState()

    View Slide

  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

    View Slide

  21. Declaration of the UI is based on state
    Simple styling based on parameters
    Complex styling based on
    composition over inheritance

    View Slide

  22. • User interface is declared based on state
    • No need to modify (transform) the
    existing component tree
    • UI updates itself upon state changes

    View Slide

  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 ...

    View Slide

  24. Composition over inheritance

    View Slide

  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

    View Slide

  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

    View Slide

  27. View Slide

  28. View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  32. Thank you!
    [email protected]
    @tkuenneth
    @tkuenneth
    https://www.thomaskuenneth.eu/
    @tkuenneth

    View Slide