Nealyang/PersonalBlog

preface

No matter how lowcode 🐂x, can you avoid the source development for complex pages or specific pages

I have also written related articles before. In total, a page caused the thinking of front-end architecture, but it mainly introduced How, not Way. After one year of use (raX 1.x system is also being improved), it will inevitably be accompanied by some adjustments. This article serves as a stage summary and the paving for BeeMa architecture development auxiliary plug-in.

The following is a summary of H5 MPA development with Rax and TypeScript.

Gai version

Usually coded MPA applications, are added to the corresponding page under pages, and then inside the stack components. Ajax interface syndication is usually done in componentDidMount or useEffect. That’s true, but it’s broad.

Most of the team uses RAX coding, which is the process of FN (state)=>UI in daily coding work, so the main work is classified as follows:

  • index.tsx Provide aggregation
  • Ask the interface to take the field and pass it to the components
  • Components display, digest internal state or collaborate (communicate)

The status quo

Without the constraints of norms, everyone’s style will vary greatly

It can be seen that the front-end business coding is nothing more than the above three problems, but each student has a very different way to deal with them, so it takes a certain amount of time to digest the original logic every time they take over a project to change the code of other students.

And!!! If multiple people are involved in collaborative pages, there may also be a lot of code conflicts (the page logic is not highly decoupled)

Problems and Challenges

To summarize the problems encountered by teams in source development above:

  • Coding styles vary greatly, and it takes time to digest code logic when taking on older projects
  • The service module is highly coupled
  • The Bundle is large, the first screen loads,codesplitingmissing
  • Page containers lack consistency and have varying capabilities

If we need to provide an architecture to solve these problems, at least we need to provide:

  • Page container (management module, basic page function encapsulation)
  • Status Management scheme
  • Module loading scheme (modules are highly decoupled to avoid multi-party collaboration conflicts)
  • The above functions are separated into components and the code repository is more focused on business development

Action

Based on the container

From previous projects, we concluded that containers should have the following capabilities:

API specification

attribute meaning type
title The title string
renderPlaceholder Loading loading (a)= > FunctionComponent
showPlaceHolder Whether to show placeholder layers (isLoading) boolean
hiddenScrollToTop Hide back to top boolean
toTopProps Return to the properties of the top component IScrollToTopProps
renderHeader Render header component (a)= > FunctionComponent
renderFootr Render bottom component (a)= > FunctionComponent
customStyles Custom container styles {contentWrapStyles,headWrapStyles,bottomWrapStyles}
onEndReachedThreshold How far to the bottom begins to trigger endReached Number

IScrollToTopProps

attribute instructions type
bottom Distance to bottom number
zIndex zIndex number
icon Picture icon address string
darkModeIcon Icon image address in Dark mode string
iconWidth Width of the icon number
iconHeight The icon is highly number
threshold Scrolling distance (how much scrolling triggers) number
animated Click back to see if there is animation at the top boolean
right Distance from the right side of the container number
onShow Show the callback (…args) =>void
onHide Disappear callback (…args) =>void

Basic broadcast events

The name of the meaning parameter
SCROLL Scroll event ScrollTop Specifies the top distance
TRIGGER_ERROR Trigger error interface
END_REACHED The bottom of the event
RESET_SCROLL Reset the scroll and recalculate the container height
ENABLE_SCROLL Forbidden scroll true/fase

The packaging of container components above provides basic container capabilities. For most business development, it is basically able to meet the needs.

Again!! Writing business pages, in fact, can be divided into the overall work of two parties:

  • The format of data
  • Take the data and render the UI

Therefore, the following part of the article introduces the selection of the state management tool, and how to sort out the state. Finally, how to load the module

State management

With the underlying capabilities provided by the base container, if we use React, Vue or RAX to develop front-end pages, they are all state-driven UI processes, so state management is naturally essential for complex business scenarios.

Based on the existing hooks technology solution, there is a natural state management solution: useRedux, but given the high degree of decoupling between modules, it makes sense to change Redux to support middleware, compose, combineReducers, and more. So for the architecture design of the first version, I encapsulated a state management scheme: move a wheel from the Paradigm of Redux to do the state management of the source project

However, within the group, ICE offers a much simpler state management package, supported by iceStore and RAX. So naturally still follow the group’s source direction, here we state management, finally chose to use iceStore solution

For state management, considering the high decoupling of modules, it is agreed that each module corresponds to a branch of the state tree. In short, a new module should be added, and the model of the corresponding module should be added

The above advantages:

  • Unified state management, simple pages only need to manage their own model correspondingstatedispatchersCan be
  • Cross-module communication can be achieved by introducing the corresponding module’sdispatchersCan be
  • Page general data, such as baby ID, can be passedcommon model, distributed uniformly to each module from the framework level (detailed implementation is introduced in the module loading section)

State distribution

Before explaining state distribution, you should first introduce the configuration of interface data request. In fact, it is relatively simple, is an MTOP (Ajax) request to get belong to only

In the schema, wrap the request in **utils** and then call the distribution state in custom **hooks: useDataInit**

Request interface data

The source framework initializes a mock request with data from page-name/mock/index.json

Status distribution use-data-init.ts

In custom hooks, take the data and distribute it to the corresponding component based on the modular fields.

As mentioned above, we have completed our work of equipping the state of the entire application (page). Now we focus on how to properly load modules according to the state tree

Module is loaded

Module loading, in accordance with the previous relatively “arbitrary” encoding mode, is stacked in index. TSX according to their own style, holding a variety of ifElse judgment, such disadvantages are as follows:

  • index.tsxEntrance to the clutter
  • Page coupling degree is high, and there is conflict in multi-person collaboration
  • Over time it can lead toindex.tsxLong and logically complex

In view of the above problems, we hope that:

  • Module based on configuration
  • If there is no common logic or page-level part involved,index.tsxAs far as possible, no modification is involved
  • Modules can be loaded asynchronously, supportcode splitting

directory

src/page-name/components/

A small summary

  • There are two steps to writing a business page: 1. Get the one you likestate. 2, according to thestateTo renderUI. The various interactions only modify the correspondingstate
  • The initialization state is inuse-data-initGet the data by calling the interface and distribute it to each module. Make up our “want” state tree.
  • index.tsxBased on the state tree you get and then based onconfig.tsTo decide how to load the component
  • Bottom ability passpageContainerComponents support
  • Status management scheme selectionstore, the correspondingmodelIn addition topageStatecommonThe others are each business module

emphasized

annotation

In Ts comments are documents. Although modules are highly decoupled, even modules that you are familiar with will become unfamiliar over time, so make every field of a module declaration as annotated as possible

The modules corresponding to the state branch must be the same as those configured in config.ts

For more details on the constraints, see an exploration of the Auction source architecture on the detail page

The reason I don’t want to go into the details of constraints is that a series of vscode plug-ins are provided here, which can be developed by following the functionality provided by the plug-ins to digest the constraints at the architectural level

The solution

Detailed instructions for use, next decomposition ~

Create an

Supports EMS configuration of scaffold templates for PC, wireless, and component applications

A new page

Take H5 source code for example

  • Get the corresponding page scaffolding according to the application type
  • Basic information Supports multiple template languages
  • Mobile supports basic UI configuration (common header, gradient background, bottom button and other general layout UI)
  • Basic page information can be modified

The module configuration

  • Add and delete modules
  • The module supports first-screen components and load components on demand
  • Module drag sort

BeeMa outline

Convenient and fast positioning of core function development, almost 96% of the functions can be completed in this outline

The above examples and improvements, based on Rax MPA source page development