Applets are a new open capability that allows developers to develop applets quickly. Small programs can be easily obtained and spread in the super App, and have excellent use experience.

Customizing the navigation bar in a small program project is definitely one of the most disgusting requirements. This article exposes the sand-carving behavior of the navigation bar products that require applets to customize. May cause products of saliva attack, but I still want to spray, not satisfied with all down the line to hit me ah.

Applets have navigationBar at the top and tabBar at the bottom.

navigationBar

First, what does the top navigation bar of the applet framework do?

  1. Rich apis, such as dynamically setting titles and loading state animations;
  2. Compatible with bangs/water drop/hole screen;
  3. Native window will not be soft keyboard up and the top of the page will be due to the window distance from the top of the problem so that in the special-shaped screen pull down can not see the loading effect;

What does customizing the top navigation bar bring?

  1. Better visual effects;

It seems to solve all the problems that the framework’s navigation bar solves except for its good looks. And part of the problem is insoluble. After the custom page dropdown and input box will be affected by this, through reasonable page design can avoid part of the problem. Many small applications also have custom top navigation bar in some special pages, most still retain the frame native navigation bar.

From the above comparison, it seems that there is not too much of a problem, and it is not enough to explain how much sand sculpture products require customization. The following is the climax of this article.

# Bottom navigation bar (tabBar)

When it comes to the custom bottom navigation bar, my heart has millions of grass mud horses in the pentium jumping in rotation, the inner grass mud horses rotating with the hurricane condensed to my hand formed a “spiral pill”, really want to jump up to the sand sculptures of the dog head is once.

First of all, what does the bottom navigation bar of the applet framework do?

  1. Multi-window switch (this is the most core function, multi-window is one of the biggest differences between small program and public number, is also an important feature of small program ability, this is H5 page can not achieve the experience effect);
  2. Good compatibility with iPhone X devices.
  3. Rich apis, such as red dots and message counts.

What does customizing the bottom navigation bar bring?

  1. Good-looking (the middle button is particularly protruding, which is really TM exciting);

They seem to have no other advantages than good looks.

The most common requirement for customizing the bottom navigation bar is to make the center button stand out. I would like to ask a few questions about products that require customization:

  1. A product with a protruding center button will succeed? Take a look at the small program of each big factory, which one is protruding?
  2. Do you know how many problems native bottom navigation would face without using a framework?

How much meaning can a button bring to the old idea that the middle button protrudes? In addition to small programs, take a look at the National App wechat /QQ/ Alipay/Taobao /JD/ Douyin. Which one has a protruding button in the middle? Successful products are those that truly address user needs. Don’t use native App requirements to ask for miniprograms, and don’t let the bike race against the supercar, okay? The native App sitting on the supercar is the most beautiful thing on the front street, not only handsome, but also fast and silky.

Here are some of the problems with native bottom navigation without frameworks:

  1. Without system navigation, all the code must be written on one page, and the best way to do this is to switch display through multiple custom components. The code is significantly less maintainable, and the home page is inevitably slow to load.
  2. The bottom home button on the iPhone X device takes care of itself.
  3. If the first two are acceptable, the third problem is that due to product needs, it is not guaranteed that all Windows of the navigation page need to be pulled down to refresh. At this time, because they are all in the same window, they can only be opened or closed. (This usually only opens up the whole compromise approach).
  4. The navigation bar will be moved to an invisible area due to the drop-down refresh.

The framework of the small program native navigation bar has done too much compatibility and experience on the processing, custom is the experience of regression, absolutely can’t give up the use of native navigation bar for a button, a gradient color. An excellent product is able to run stably and solve the needs of users, and a protruding button has nothing to do with the success of the product.

Customizing is fun for a while, but only later will you know how many things are affected and can’t be fixed.

Summary: custom navigationBar hard to see the page function to do a bit. The need to customize tabBar is a real no-go.

In addition to small programs, uniApp apps also do not recommend customization, because the problems are the same.

May the world be free of sand sculptures that require applets to customize the navigation bar.