iRyanBell

Responsive. Reactive. Simple. Pick one.

June 03, 2019

Responsive. Reactive. Simple. Pick one.

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