The next generation request library alova has received a major upgrade, making it easier to use and higher in performance.

hello!

Maybe you have also heard of alova, a lightweight request library, which can help you implement complex data requests at a lower cost, saving developers energy and time.

If you need to learn about alova, you can visit the official website, where you can find more detailed documentation and sample code to help you better understand and use this tool.

It has been a year since the release of alova2.0. During this period, it has received a lot of praise. Of course, it has also received a lot of feedback for improvements, which has made alova continue to mature and improve. I am very grateful to everyone who has contributed to alova, and I also know it. There are many redundancies and flaws in the design.

Now, in order to better serve you, it is time to upgrade to 3.0. The purpose of this upgrade mainly focuses on the following goals:

1. Adjust alova structure and expand application scope
2. Simplify usage, discard unnecessary APIs, and adjust defective designs.
3. Redesign some modules to improve performance

Before looking at the specific 3.0 adjustments, let us review what exactly alova is going to do and where it is going.

Pain points of network requests

In enterprise-level projects involving multi-person collaboration, the cost of Client-Server interaction is relatively high.

1. High cost of front-end and back-end collaboration:

   1. Depends on backend notification: API updates require active notification from the backend
   2. API document dependence: The front end needs to consult the API document to obtain information.
   3. API code writing: The front-end manually writes the interface code according to the API document.
   4. Lack of response data type: API response data does not have type hints by default, which increases the cost of data usage.
   5. Increase in bug rate: API changes may lead to an increase in the bug rate of the project.

2. Complex data interaction logic: Front-end requests are often not that simple. You need to consider when to send requests, when not to send requests, how to process response data, etc. according to different scenarios to meet the performance and performance improvement of the project. This will result in increased developer time costs and code maintenance costs.

solution

1. IDE plug-in (vscode/webStorm): Solve the problem of front-end and back-end collaboration (specific solutions can be viewed in the Feishu document below)

   1. Automatically generate request codes and response data types
   2. Embed the api document into the code, you can directly query and insert the API interface in the code
   3. Update API information regularly and proactively notify front-end development
   4. Interface update records to prevent changes from causing bugs

2. Request Strategy: Select the corresponding request strategy and implement complex data interaction logic in one line of code.

alova goals

Don't spend time on the small matter of requesting, leave it to alova, it will save you most of the work in requesting, you only need to specify which API to use and what strategy to execute the request. .

alova@3.0 update plan

Release Notes

Before the official version 3.0 is released, we always welcome your feedback. You are welcome to comment in the article or submit your valuable opinions on WeChat from any angle such as usage scenarios and design issues.

The specific update content, progress, and IDE plug-in design can be viewed in alova product white paper and 3.0 update overview.

• Join the Discord community to participate in communication

Find core partner people

alovajs has so far achieved certain feasibility verification. In order to speed up its development, it is now necessary to invite two friends who agree with alovajs to join the core team (one has been confirmed) to be responsible for the core work of alovajs. This may allow you to obtain huge benefits. Friends who are willing to learn more see Become a Core Member.