loading words...

Jun 04, 2019 00:37:11

Responsive. Reactive. Simple. Pick one.

by @ryanbell | 412 words | 🐣 | 4💌

Ryan Bell

Current day streak: 0🐣
Total posts: 4💌
Total words: 2135 (8 pages 📄)

These past few days, I’ve been experimenting with Functional widget design in Flutter, trying out different models for state management. The framework provides one really nice model via setState, but I’ve been curious to get a better feel for the problem itself by trying out other models.

UI = f( state )

https://flutter.dev/docs/development/data-and-backend/state-mgmt/declarative

“How do I best manage the state of the UI controls in a medium-to-large Flutter app?” is a question we often hear. This is a complex topic with strong, and differing, opinions.

https://flutter.dev/docs/development/data-and-backend/state-mgmt/options

“The rule of thumb is: Do whatever is less awkward.” -Dan Abramov

I brought in the `shared_prefs` and `flutter_secure_storage` packages to see what it would be like freezing and hydrating state locally through my `FLOW` package (https://pub.dev/packages/flow). This way, I could achieve an auto-save effect between models and positions within an application at varying depths. Ideally, these would be cached to some third-party site with encryption and authentication, so that applications become more device/location agnostic with data persistence. While easy to describe, this is actually quite a challenge to implement correctly. It’s particularly tricky to abstract this to the level of the mechanism itself rather than simply (or, less than simply) solve the problem once for a single use case.

I’ve been experimenting with better ways to represent hyper-responsive layout design in the code hierarchy with reactive ephemeral state management. How nice would it be to have a singular codebase that could scale up the level of detail and interactivity to make the best use of any canvas, from a tiny watch or voice-only device, to a tall mobile device with hand gestures, a wide desktop with mouse and keyboard input, or big screen tv with limited input? And could that codebase manage its own backend services if structured in some, new way?

Taking simple ideas with complicated mechanics, and making those inner mechanics simple again is well… not simple. Before moving further into Flutter’s nest, I’d like to try a few more approaches from within the progressive web app form factor.

This is a great short interview with Oki Sato, known for his playful, functional design approach. These lessons apply wonderfully to software/web development. At any given time, he has up to 400 projects on his desk.

Japanese designer Oki Sato on his playful approach to design | Braun | British GQ https://www.youtube.com/watch?v=c3TPbj2_Xjg

Originally published at iryanbell.com

  • 1

    @ryanbell - thanks for introducing me to your experiments with Flutter -- I'v been wanting to dive in and check it out -- this may just be the impetus I need.

    Brian Ball avatar Brian Ball | Jun 03, 2019 22:35:51
    • 1

      @brianball It's a cool framework. The learning curve is very forgiving considering it's a new language (Dart) for most people.

      Ryan Bell avatar Ryan Bell | Jun 04, 2019 18:06:48
contact: email - twitter / Terms / Privacy