Front-end component design — the clever use of bit arithmetic

Long time no see. I haven’t had much time to summarize and record my experiences and practices during this period since MY job-hopping, so I finally managed to squeeze some time. Today, I want to record the design and development process of a recent component. The development environment of this component is small program, but I think this thinking is universal

This article may cover —

• Demand profile
• The combination of bitwise operations and form components
• Component design summary

Demand profile

We probably need to complete the form component ↓↓

Judging from the diagram, we should split this component into two parts, one for the TAB TAB area and one for the additional options area below.

Why is it necessary to split up?

• The main reason is the project itself, there is a TAB component before, we can directly reference.

• Of course, even if we don’t have this component in our own project, I recommend splitting it up, because this TAB selection is so common in form development that it would be beneficial to split it up, and its functionality is so simple that it fits well as a standalone component.

How do you describe components with data structures?

The static structure is pretty straightforward, so how do we describe this component in terms of data? Let’s consider the data structure of the component before we begin

The number of tabs is variable. TAB is associated with additional items. The number of additional items is variable.

The above is the data structure I dreamed up in the first version. The reason for this rule is as follows

• Since the number of tabs varies, it is best to configure them as arrays for front end list rendering (the same goes for add-ons).

• Because TAB is linked to the content of the additional item, I directly inline the additional item with TAB. When switching TAB, I can directly switch the corresponding additional item data.

• With multiple tabs and add-ons, there are bound to be collation problems. In the first version of the scheme, I adopted the map processing method, splicing the selected values together, and then obtaining the final value in valueMap. (Different businesses have different methods. If you do not need to deal with combination problems, you can directly output all the selected values.)

Then the logic is smooth, we just need to get the final value concatenation value selected by the user to get the target data in valueMap.

But this solution was flawed, and I ignored the configuration complexity so that the logic could be easily handled in the front-end code. However, it will bring endless troubles for the subsequent configuration. With the increase of the number of schemes, the combination will increase rapidly. To avoid this pit, I need to make some optimizations to valueMap.

ValueMap optimization scheme

As the code in the figure shows, instead of a one-to-one key value approach, TAB items are used to strip out the value range.

The subscript of the array of value optional ranges is then obtained by processing the selected options. In this way, the configuration will be better than the previous one, and the front-end logic will be slightly more complex, but the front-end code only needs to be written once, while the configuration may be countless times.

The front-end logic of the new solution looks something like this, etc… Why does it look so weird? This logic is completely mixed with the business, in case of additional projects will not explode? In case additional programs also appear between the combination of the situation is not also exploded 🙁

Doesn’t that make the plan even more unreliable? Can we try to decouple it from the business?

The combination of bitwise operations and form components

An introduction to JavaScript bitwise operations

Bitwise operations operate directly on the binary bits of an integer in memory. It doesn’t matter if you’re in JavaScript or not, but we can use this bitwise thinking. Documentation on JavaScript bitwise operations. In this article, we’ll focus on using bitwise shift operators for our purposes.

How do you combine the two?

Just go to the code, let’s look at the picture

In the new logic, we no longer have a dependency on the addon item value, but instead place subscripts in binary form. Suppose we have an array like this:

let A = [A-value-0, A-value-1, A-value-2, A-value-3]

The values of each of these four choices

If you look at the binary subscript column, 0 means not selected, 1 means selected, and you can tell which item is selected or not selected by the position of 1.

Look at the relationship between array subscripts and binary subscripts, which, when converted to decimal, is exactly the desired array subscript.

Looking back at the code in the figure, this is exactly what forEach is doing internally:

Through the checked items in addon array, the binary subscripts belonging to the item are obtained according to their index, and then all binary subscripts traversed are calculated by OR operation to obtain the final binary subscripts, which are then converted into real array subscripts to obtain the final value.

Through this scheme, we can get the combination we want and the corresponding value of the combination without caring about the number of items or the value of each item in addonList. When we configure items, we only need to pay attention to the order of each value. No matter how many items are configured, the front-end logic will not be affected.

It is also possible to change the number of addonLists in this case, for example, if there are three items:

Component Design Summary

Through this form component design, there is a little bit of thinking about the front-end component design:

• independent
  • If the component has a single function, radio should be responsible for radio selection without adding some business-related logic or copywriting.
  • Try not to make components too complex. If you split components, don’t expect one component to do everything.
• reusable
  • When designing components to meet current needs, it is best to consider their versatility. If you find that it is not universal, it is better to write it in the business and not separate it from it.
  • Of course, in the design of components, it is impossible to require the use of components of the scene to be 100% consistent, so that the adaptation of components, expansion ability is stronger, conducive to the robustness of components.
• neutral
  • As little business coupling as possible — component neutrality.
  • This point looks good, is the reality that feels bone commonly 🙂
• Easy to use
  • As far as possible, the user only needs to think about the inputs and outputs.

I’m not sure you need the case code either. A full version of the component code will follow if required.