By Jiangxiu from Xianyu Technology
Flutter may not be a scorching and trendy topic anymore. Still, as a technology that has gradually entered into scale practice, its value has been initially recognized and should have a good life afterward. As a relatively early Flutter practitioner, I have been thinking about the technical value of Flutter and how to release these values. This article attempts to structure the technical value of Flutter from a new perspective and do the corresponding application analysis. The following section does not cover specific technical points of Flutter. However, based on our team's past exploration and practice, we will make a summary of these points in terms of technology application strategies, hoping to help partners to think and summarize in the development practice, looking at the road, looking up to the stars, to find the future direction of innovation.
To trace the origin of Flutter, we have to start with the front-end. Here, the front-end is a concept relative to the back-end and refers broadly to the endpoint technology that enables user interaction through a graphical interface. This field has always been very dynamic. Along with the advent of the Internet, many new ideas and technologies are a bit dazzling. The ancient model-view-controller (MVC) is not much to mention; the old MVP - model-view-viewmodel (MVVM) - is gradually fading; the new - Vue, Angular, and React - is still emerging; and there are Redux, Mobx, Hooks to push the wave. All these technologies are like little beings with feelings. Some are enthusiastic, some literary, some cold, and they are very lively. Maybe you will think: What are they all talking about? What problem do they all want to solve?
The Internet is the background of all this, and there are three significant elements of the Internet: nodes, connections, and network topology. The evolution of each component will bring upgrades and changes to the front-end. From PC Internet to mobile Internet and then to Internet of Things is the evolution of nodes. The imaginative 5G is the evolution of connections. Similarly, the transformation from centralization to distribution is the evolution of network topology. The front-end mission is to allow users (people) to be efficiently embedded in the network. It also enables people and devices to merge into a living network "node."
Note: You can adjust the network model to many front-end scenarios. The "nodes" can refer to mobile devices, applications, processes, pages, and even components.
Front-end technology is the glue between users (people) and equipment, allowing the two to form a network node organically. I try to analyze the form of front-end technology in nodes. Firstly, it needs to provide the interface to the user and respond to the user's interaction. It needs to manage the communication with remote nodes and exchange information. It also needs to manage the information status of the current node. Finally, in order to be easily embedded in the network, the node needs a friendly "appearance," which is the lifecycle. The lifecycle describes the birth, demise, rights, and responsibilities of a node.
Note: This partition model also has some generalization, and you can apply it to applications, pages, or components.
As a software technology, the front-end also needs basic deployment support in daily engineering development. Based on the previous discussion, the basic element issues to be solved by the front-end are:
The lifecycle management here is a relatively invisible issue; it is actually the construction of the "appearance" description, which is also known as componentization. The structural relationship of these basic issues probably looks as below:
You cannot solve these elemental issues in isolation, and therefore considering them as a whole is crucial when designing solutions. Technology solutions in the front-end domain usually merge to solve several of these problems. For example, React solves interface management and lifecycle; Vue solves interface management, state management, and lifecycle; Redux focuses on handling state management; GraphQL, BFF; Serverless resolves remote communication; Webpack solves the build department.
So, what problems does Flutter solve? Or, what problems can Flutter solve?
Interesting technical solutions have their own distinctive features. When managing architecture, we often encounter unique problems or find better tools. Therefore, when using Flutter as a solution, you should sort out what Flutter brings. In general, there are mainly Dart language, Dart runtime (VM), GUI framework, and related development and building tools.
It's hard to say how good Dart language is. Generally speaking, it is an engineering-friendly modern language. It may seem plain, but when the official introduced Flutter, it also proudly showed its inclusiveness. It can support declarative, procedural, object-oriented, functional, and responsive business scenarios more natively. Besides, it provides a very free paradigm space for technical solution implementation, worth exploring and trying. Combined with my own practice, there are several points worth mentioning：
When you introduce Flutter, you'll have a Dart-runtime. Originally, Dart was introduced to support the running of Flutter. However, similar to JS's V8 engine, which was initially used to support H5 pages and then has been widely used in many areas. Dart does not have the dynamic capability of JS (it is possible on special occasions), but it is cross-platform, and its AOT performance is guaranteed. Further, Dart's exploration space is ample, and it can cover almost all scenes at the same time, including mobile app development, PC construction and deployment, server, and even serverless runtime.
Flutter brings a high-performance cross-platform GUI Framework. There is not much to mention. Just use it! But if you already have your own development ecosystem, the cost of abandoning it is too high. If you want to "borrow" the technical advantages of Flutter, there are probably several options:
Another ideal way is hybrid development, which needs to implement hybrid stack management. Moreover, after version 1.22, Flutter upgraded the Navigator component to provide Navigator 2.0; this is good for hybrid development.
It is worth mentioning HotReload, and whoever uses it will know how good it is. Hot deployment is not only required for interface development, but it's also a common requirement. It is also excellent if one is implemented through Dart on the server.
There are not many highlights of Flutter's build tools because the Dart language does not support reflection in Flutter (the product is too large, increasing the package volume), and the implementation of business architecture relies much on compilation and processing techniques. This again largely depends on the capabilities of building systems. From another perspective, since there is no mature solution in this field, coupled with Dart's engineering "friendliness," it might be cool to have one language to unify front-end development, back-end development, build, and deployment.
We have discussed several basic elements to be solved at the front-end and also discussed the technical tools brought by Flutter. Now, we will see what we can achieve with the help of Flutter.
"Remote communication" is an abstract concept, and its specific form varies according to the definition of the network node. It can refer to communication between physical devices (phone to server), between modules (a page to another page), or between components (between two StatefulWidgets). Since "everything is a widget" in Flutter, to simplify it, there are two scenarios in Flutter: server-oriented communication and communication between widgets.
In this field, there are traditional Restful, GraphQL, and Serverless, which emerged from the concept of "cloud-native." With the help of Dart's capabilities, Dart-runtime can become an optional container for Serverless, then both front-end and back-end can use Dart to develop. If Dart supports the middle build deployment pipeline, then you can build a highly "cloud-native" application development flow (dev flow):
You can combine the cross-platform capability of Flutter with the elastic deployment of cloud-native. The front-end and back-end implementations can be put together, and the call between them becomes natural and straightforward. There is reason to believe that this will be an efficient development method. Xianyu has done the preliminary exploration and tried to land in the business.
In addition, the combination of GraphQL and Flutter is also worth trying. The GraphQL and React paradigms fit well conceptually, but we haven't tried before.
Flutter's basic business programming components are StatefulWidget and StatelessWidget, organized in a tree structure, and provide InheritedWidget to support communication between them. Below are the three ways to summarize it:
State management is a big problem and consists of two elements: state and logic for processing state. In terms of code implementation, the state is data, and the logic is function. When they become complex, the solution is to split them up and then rationally combine them. I tried to list all possible solutions by splitting the state and logic:
This approach is known as "unified state management," as all states are placed in a common state structure object. With only one data object, you can easily eliminate the problem of information sharing between the various processing logic. There is no state inside the logic, making it very pure (such as pure function implementation). Further, the logic is combined into a whole in a suitable way - with clear implementation boundaries, simplicity, and elegance - the representative solution is Redux.
If you choose this design scheme, the functional style is more suitable. This is not because the functional style is more efficient or more elegant, but it is very consistent with the functional approach. Besides, it is easier to grasp the idea in implementation. There is nothing wrong with using object-oriented implementation. The final effect depends on the engineering environment and the users you are facing. The advantages of this state management are apparent. When a state changes, you do not need to synchronize events everywhere. But if you use it in a complex and large business (such as a business product with dozens of page flow) the state must be complicated, and the state structure must be huge. The Redux approach manages the logic very well. If you want to manage unified and substantial state data, perhaps memory-level SQL is a good idea. GraphQL-Client has inspired us, and we are also trying to practice.
I call this "Step state management." It is similar to the state machine mode. However, if you really want to use it, the state must be limited and cannot be changed frequently. This is actually not consistent with the ever-changing business needs of the Internet, so there is almost no design in this way. However, in some serious business scenarios, such as the transaction process, it is difficult to change once the transaction is set; therefore, stepping state management can be useful.
This is an easy solution theoretically. At a finer granularity, the state and its corresponding processing logic are split and packaged into smaller scopes, and then you can unify and coordinate these subModels, I call this combined state management. Further solutions can uniformly define the fundamental behavior of subModels and then introduce a scheduler to coordinate and manage them. subModels can also share context to exchange information.
This idea is independent, and you can implement it in many ways. Both classic object-oriented and scoped models use this idea, which is easy to understand but has limited capabilities. Also, the functional method is an alternative option. You can also implement higher-order functions and closures effectively, but I haven't seen related designs being implemented. Another point is that Dart provides the Mixin feature to obtain a more concise implementation scheme. For example, many specific models can be deposited and then be combined into the business model by selection (refer to the implementation of WidgetsBinding in Flutter Framework). Currently, Flutter hook is doing exploration in this area. Flutter Hook looks a little confusing, but its core is to use Dart's Mixin feature to combine states.
Flutter uses a responsive UI, which allows business developers to reduce interface management work and just provide good page descriptions. Although Flutter has a built-in Diff mechanism similar to Virtual DOM, building this Diff still costs performance. Wouldn't it be possible to improve performance if we could design the framework to bring forward the Diff work to the data layer?
We have tried several methods, but the effect is not ideal because Dart cannot reflect in Flutter. However, there will be a good solution after ecosystem improvement in the future.
Flutter always had a faint voice of dynamic in UI development, which seems to be ignored by the officials and is not mentioned here.
Flutter provides basic lifecycle management for service development through the StatefulWidget. The design of the lifecycle component varies with different business scenarios. My own understanding is that the creation of the lifecycle should start from two points. The first is the timeline of the component from birth to death, and the second is the rights and responsibilities of components in the scenario. The extension origin of the lifecycle is the StatefulWidget. Since the extension varies with different business scenarios, it is hard to expand.
For example, if you use native or pure Flutter development, the lifecycle provided by the StatefulWidget is sufficient. But if you want to do hybrid development, after introducing the hybrid stack, it is obviously not enough. At this time, it is necessary to provide new components to expand the lifecycle to meet the development requirements of hybrid scenarios effectively. I didn't understand this when I was working on the hybrid stack.
This article starts with analyzing several basic core issues that front-end development needs to face, combined with the technical tools brought by Flutter, and tries to structure the analysis of possible technical options and exploration directions of Flutter in business development. Of course, technical engineers need to look both at the stars and the road. For hot technical issues in Flutter development, you are welcome to pay attention to other articles of Xianyu.
Flutter: A Full-scene Scrolling Container with High-performance and Multi-functions
56 posts | 4 followers
FollowAlibaba Tech - February 24, 2020
Hanks - April 21, 2020
XianYu Tech - May 11, 2021
淘系技术 - December 9, 2020
XianYu Tech - September 9, 2020
XianYu Tech - May 13, 2021
56 posts | 4 followers
Follow
Serverless Workflow
Visualization, O&M-free orchestration, and Coordination of Stateful Application Scenarios
Learn More
Web Hosting Solution
Explore Web Hosting solutions that can power your personal website or empower your online business.
Learn More
Serverless Application Engine
Serverless Application Engine (SAE) is the world's first application-oriented serverless PaaS, providing a cost-effective and highly efficient one-stop application hosting solution.
Learn More
YiDA Low-code Development Platform
A low-code development platform to make work easier
Learn MoreMore Posts by XianYu Tech
