Applets cannot use the DOM API exposed by various browsers for DOM selection and manipulation
Reason: In the applet, the rendering layer and the logic layer are separated and run in different threads respectively. The logic layer runs in JSCore and does not have a complete browser object, so it lacks related DOM API and BOM API.
Why is it designed this way?
Because JavaScript can manipulate the DOM, if the JavaScript thread and the UI thread run at the same time, that is, the interface is rendered while modifying the properties of these elements, the element data obtained before and after the rendering thread may be inconsistent, resulting in the traditional web development. The rendering thread and the script thread are mutually exclusive. reprimanded. So when the JavaScript engine is executing, the GUI thread will be suspended, and the GUI update will be stored in a queue and executed immediately when the engine thread is free. So long script runs may cause the page to become unresponsive.
Mini Program DOM Operation API —— SelectQuery
In the browser:
const demo= document.querySelector('#demo')
console.log(demo.boundingClientRect().top)
In the applet:
const query = wx.createSelectorQuery()
// 组件中：const query = wx.createSelectorQuery().in('组件id')
query.select('#demo').boundingClientRect()
query.exec(function (res) {
console.log(res[0].top)
})
Three obvious differences can be found:
- A query object is created by createSelectorQuery instead of document.querySelector
- Executing the query operation on the query object is not executed immediately, but enters the waiting queue, and the query behavior is not triggered until exec is called on the query object
- The query results are returned asynchronously, and are read from the parameters in the order of the query in the callback
The reason for the first difference is that first of all, the dual-threaded model of the applet determines that it cannot be obtained in the business code document对象, and the relevant query methods cannot be called on it. So why return the query object by calling createSelectorQuery() instead of defining the query object as global? This is because the view layer of each page of the applet corresponds to a webview, and all pages share a logical thread. This one-to-many relationship needs to be distinguished by an id during communication, so the returned value every time createSelectorQuery The query object is bound to the id corresponding to the current view layer webview.
The second and third points of query 非立即执行are actually triggered when exec is called. It is easier to understand: the business code is in the logical thread, and the real DOM is in another webview thread. The communication between threads needs to be completed with the help of the host. The exec method of the query object When triggered, the applet stores the callbak, and then calls the method exposed by the native host to communicate. After getting the query result from the webview thread, it performs deserialization processing, passes it to the previously saved callbak and starts executing, so this is asynchronous .