Suggestion Development Summary and summary of Keyboard Events (for Chinese Input Method Status). For more information, see. Important Keyboard Events:
Event Sequence: keydown-> keypress-> keyup
When the input method is Enabled:
Keypress:
The most special events in these three events can be used with half the effort:
1. First, there is no keypress event for most function keys.
Caps lock, shift, alt, ctrl, num lock, and. Fortunately, enter has this event.
2. the keyCode returned by press is unreliable for letters, numbers, and
In IE and webkit, the returned ASCII code is
Returns 0 forever under firfox.
However, the keyUP keyDOWN event key values are completely unified.
3. KeyPress can only capture a single character
KeyDown and KeyUp can capture the combination of keys. Therefore, functions that may involve key combinations must be bound to the down up event.
When the Chinese Input Method is enabled, the browser has different corresponding events and solutions:
When the Chinese Input Method is Enabled:
Firefox: When you click the keys, the following events are triggered:
Why is it virtual defocus?: This status does not actually trigger the defocus state, but shields all Keyboard Events bound to the input box.
IE,Webkit: However, when you click the keys, this will happen again.
Inspiration: in this state, you can capture keyup and keydown to capture KEYCODE. The frontend can simulate the KEYCODE input box to synchronize the input method with the input box, suggestion is synchronized when the input state is triggered.
So how can we avoid that when the input method is run, the user is hitting the return key to trigger the original event of the Return key?
After reading the two figures above, it's easy to bind the ------- keyPress event to the original event, such as triggering a search.
Keyup is bound to events that need to be triggered when the input method is running, such as carriage return and space. It can also be used to detect exit from the search box.
So how can we check the point after the user inputs?
If you need to block events when the input method appears, you only need to bind the events to the keypress event.
Summary of suggestion:
Start:
In the development of suggestion, the biggest obstacle is to check user behavior. These user behaviors mainly converge on a small input box. The clever use of Keyboard Events can reduce the amount of code, improves performance and maximizes user experience.
The main user behaviors are summarized as follows:
1. Change the input content (add, delete, and paste) -- the most important thing is continuous input.
2. Click the function key-the main key value is:
KeyCode: 13 -- Enter key
KeyCode: 27 -- esc key
KeyCode: 38 -- The up arrow key --> the webkit kernel will automatically locate the header. Remember to preventDefault ~
KeyCode: 40 -- downstream key
There are also some minor problems during development and detours:
First, I would like to summarize the following ideas:
1. incorrect ideas:
One: each time a user clicks the keyboard, a request is sent.
This is undoubtedly a simple method, but requires a lot of AJAX, and most of them do not show the opportunity. Good front-end code should fully consider the virtual consumption of front-end interaction, minimize virtual consumption.
2. Check the content of the input box at intervals:
Code execution at intervals of time is a waste of performance. The most important thing is that this mechanism cannot control the sequence of user input events and js detection,
If the detection is completed exactly after the user input, an error occurs. Although it can be compensated by detecting the status of the current input box, the experience is poor, and it consumes a lot of ajax requests.
2. Thoughts after optimization:
Bound to a key hit event
After the development of the first method, I found that during self-testing, due to the inability to accurately monitor the timestamp of user behavior, many bugs were caused. After fixing them one by one, a better idea emerged.
Checks the key hit event to determine whether to send the request and shield the continuous hit event.
Specific ideas:
When you focus on the input box, you start to monitor the keydown event and enter the status of the input box, when there is a keydown event and the input box can be changed-"100 ms, the system checks the status of the current input box. If it is not consistent with the previous one, it can send an AJAX request to the backend.
In this way, the number of ajax requests is determined based on the user input and input frequency, and the threshold value is used to reduce ajax requests. If there are too many user inputs, there will be more js detection, and more ajax. If the user does not move, there will be no js detection and ajax, and the input will be slower, greatly reducing the amount of waste.
