Author: Idle fish technology — Ah Qiu
The preface
Fish_redux 2.0 FlowAdapter function optimization. After the overall business landing, we started a new round of optimization and architecture evolution of Fish_redux. The ultimate goal of fish_redux 3.x is to keep Fish_Redux “alive” and sustainable in terms of ease of use, scalability, and core capabilities of the framework. This article is divided into three main topics, first optimization of version 3.0, Architectural thinking, and sustainable output of Fish_redux.
Fish_redux 3.0.1
As far as application development is concerned, most of you have heard of the MVC model. MVC is a description of an architecture, and there are many variations of it, such as MVP, MVVM, etc., but these are essentially MVC categories. The definition or interpretation of MVC varies depending on the language/domain/framework. MVC mode (Model — View — Controller) is a software architecture [2] mode in software engineering [1], which divides the software system into three basic parts: Model, View and Controller.
When views change from traditional GUI objects that operate directly to declarative UI/ responsive UI. This will bring two big changes (MVVM variants) : 1) The View layer, for developers, removes the intermediate state of the GUI and further reduces complexity. 2) The structural relationship between MVC is simplified and decoubled, and the Model and Controller are no longer dependent on the View.
Ease of use and maintainability are often considered at two levels:
• Ease of use is a summary of the past; • Maintainability is a further abstract interpretation of scene requirements;
So take fish_redux for example:
•State defines &Reducer function corresponding to Model layer •Effect function corresponding to Controller layer •View function corresponding to View layer
The purpose of fish_redux3.0 is to solve the problem of rapid increase in software moisture due to client/front-end application layer software, improve software maintainability, and improve team collaboration efficiency. There are several possible reasons for the rapid increase in the complexity of client/front-end application layer software:
1. Without application architecture in the project, it will be completely unable to cope with the changes of requirement iteration and personnel iteration. 2. The mismatch between application architecture and practical requirements leads to the failure of application architecture to play an effective role in isolation and reuse, and even becomes an obstacle. 3. There is no effective consensus within the team due to the difference in developers’ cognition and design level.
An application framework is a specific code implementation of an application architecture, and the above points are the main motivations for fish_Redux’s creation and evolution. The current goals of Fish_redux3.0 are:
1. We received feedback and needed to improve usability. 2. Improve software maintainability, inheritance and continuity. 3. Try to integrate and cover more free fish scenes and form a unified programming paradigm of application framework.
Fish_redux3.0.1 is the first step to improve fish_redux’s ease of use and maintainability. Therefore, the concept of core capabilities is streamlined, and the overall implementation of the code is streamlined is our primary goal. Fish_redux2.0 contains 3k+ lines of code, and the overall code remains around 1K lines after this simplification. The next three dimensions will show how concepts are simplified.
1. Core competencies
Fish_redux combines the state management features of Redux to create an application framework based on state-driven, componentization, functionalization and high performance.
State-driven in modern UI libraries, it’s all reactive, state-driven. Further, in Fish_redux, driving the UI is automatic. Components are refreshed whenever the state changes. From a hierarchical perspective: The first level of state management, responsible for centralized state management, provides componentization/state read/write and change subscriptions up to a single data source. **Middleware is designed to scale this level of cutting power.
Componentization in Fish_redux gives a new definition to components and their relationships
Build highly isolated business code.2. On the basis of isolation, provide the reuse unit of business components.3. Explicitly declare dependencies between components. Improved business orchestration readability, maintainability and extensibility in many types of detail/release scenarios.
The service code in the component is abstracted functionally and divided into View/Reducer/Effect. Each role is responsible for a single responsibility. Each single responsibility is constrained by each defined function signature.
After sorting out the core competence of appeal, the core classes and APIS of each functional layer are defined. In state management we retain the base capability section as well as the aspect capability. Story: Store/Connector/DispatchBus/Action aspect ability: MiddleWare two cases we do the minimum code support Redux framework can work normally, driving ability get perfect implementation.
Component part (Component) : the View/Reducer/Effect/Context.
Before optimization:
After the optimization:
Obviously, we have removed some redux_AOP /redux_routes/ redux_Component_mixin capabilities. The purpose of this is that these capabilities are not the core capabilities of Fish_Redux, but some extensions based on Redux. Adding part of the code to fish_redux adds concepts that increase the cost of understanding for users. At the same time, redux_Middleware, redux_Connector merges into redux and redux_Adapter merges into redux_Component.
2. Close the hierarchy
Fish_redux2. 0 implement Component raises many similar features, different degrees of lower abstract class, Component/Logic/AbstractLogic/AbstractComponent, etc. The realization of the Adapter at the same time on the basis of the more complicated and Adapter/AbstractAdapter/AbstractAdapterBuilder/Logic/AbstractLogic/AbstractComponent. The cost of reading implementation, debugging, and so on down this level is huge. So we realize do the level of the Component layer curl, reduce redundant concepts, retained BasicComponent/Component/Adapter.
Abstract class Component<T> extends Logic<T> implements AbstractComponent<T> {..... } abstract class Logic<T> implements AbstractLogic<T> { ...... } abstract class AbstractComponent<T> implements AbstractLogic<T> { ....... } abstract class AbstractLogic<T> { .... } Extends BasicComponent<T> extends BasicComponent<T> {... } Class Adapter<T> extends BasicComponent<T> { ... } abstract class BasicComponent<T> { ..... }Copy the codeWe also made the same optimization for the Context section. Context is the same concept and implementation for any component. It also maintains a unified implementation for View receiving Context. Original Context section: ComponentContext/LogicContext/ContextSys/Context/ViewService AdapterContext/LogicContext/ContextSys/Context/ViewService Multilevel inheritance is also difficult to debug and conceptually understand, and we have also made changes to the refactoring and hierarchy reduction part of this section.
Fish_redux2. 0: class AdapterContext<T> extends LogicContext<T> { } class ComponentContext<T> extends LogicContext<T> { } abstract class LogicContext<T> extends ContextSys<T> with _ExtraMixin { } abstract class ContextSys<T> extends Context<T> implements ViewService { } abstract class Context<T> extends AutoDispose implements ExtraData { } abstract class ViewService Implements ExtraData {} fish_redux3.0: abstract class ComponentContext<T> { } class ComponentContextImp<T> extends ComponentContext<T> { }Copy the codeWe’ve normalized Context to manage only the Context management of Component nodes. For virtual components, common components remain the same implementation. Context is currently responsible for the Component lifecycle, sending messages, and caching, and holds the store BuildContext portion. The ability to implement the Context at a glance is very clear to the code implementation.
3. Expand your capabilities
The extensibility part is removed to keep the core extensibility. View/Effect/Connector and other functional parts, we have made a series of extensions, easy to use and other core capabilities. Considering that these functions are not core functions, different users have different views, and there are different ways to use the unified APP. So we moved to the subsequent fish_redux extension pack for these capabilities. The idea of extending capabilities comes from the evolution of Adapter. There are many functional Adapter variants of Adpater’s predecessor, DynamicFlowAdapter, StaticFlowAdapter, etc. that use leveling with different lists. The core ability is attributed to the FlowAdapter Dependents description. Imagine that variations on this type are endless and implemented differently in different scenarios. The “implementation” for the extension pack is based on the Fish_redux core capability to adapt “variant functionality” to different scenarios. The expansion packs are imaginative and fun. According to the View/Effect/Connector/Adapter etc. We have a good idea, expansion pack continues in the output.
conclusion
Fish_redux2.0 lite version to part 3.0, the overall code volume reduced from 3K + to the current 1K. In the continuous optimization of core capabilities, I believe that easier implementation and code optimization will continue to output. We listed the current planned actions, which we will continue to invest in and implement in the near future.
Release of version 1.3.0, and extended capability package output and release. The 2.0 version will also be adapted to DartSDK 2.x. 2. How to implement the virtual component more gracefully, how to rationalize the life cycle, and how to embed the virtual component more skillfully. 3. Application framework of Flutter supports business containers of different business types. (Currently supports ListView containers)
At the same time, customize the longer term plan and continuously output better fish_redux to everyone. 3. The goal of X is to improve the “vitality” of the framework so that more developers can participate in the use and construction of Fish_redux, and make continuous improvements to maintain the common development of Flutter. So the code simplification in the core implementation layer, the output of the extended capability layer is for developers to come in from the application level, the implementation part of the discussion and into the development. Only with this kind of sustainable progress can better application frameworks be used and explored by developers. We also hope we can do some more discussions on Github and jointly contribute to the Redux app framework on the Flutter side. Fish_redux3.0-beta will be available soon.
References
[1] Software Engineering: zh.wikipedia.org/wiki/%E8%BD… [2] Software Architecture: zh.wikipedia.org/wiki/%E8%BD…