在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

鍍金池/ 問答
膽怯 回答

pull 時(shí)URL地址更換成新的倉庫地址...

尛曖昧 回答

你的每個(gè)選項(xiàng)是for循環(huán)渲染出來的吧,那么正確答案的選項(xiàng)也是知道的。

/*每個(gè)選項(xiàng)綁定的樣式*/
<div v-for="(item, index) in question">
    <div :class="bindClass" @click="clickItem(index)"></div>
</div>

data() {
    return {
        question: [...],
        bindClass: '' //未選擇的時(shí)候
    }
}
/*點(diǎn)擊選項(xiàng)時(shí)的點(diǎn)擊事件*/
clickItem(index) {
    if(question[index]===正確答案){
        bindClass = correctClass //答對(duì)的樣式
    }else {
        bindClass = errorClass /答錯(cuò)的樣式
    }
}

但我不知道你一道題返回的數(shù)據(jù)格式是什么樣子的,你可以大概看看這種思路是否可行?

我不懂 回答

兩種方式
mvn jetty:run -Djetty.http.port=9999

<build>
  <plugins>
    <plugin>
      <groupId>org.eclipse.jetty</groupId>
      <artifactId>jetty-maven-plugin</artifactId>
      <version>9.2.1.v20140609</version>
      <configuration>
        <httpConnector>
          <!--host>localhost</host-->
          <port>9999</port>
        </httpConnector>
      </configuration>
    </plugin>
  </plugins>
</build>
不討囍 回答

建議和app同事溝通,監(jiān)聽h5調(diào)用相機(jī)事件(全局監(jiān)聽),并直接彈出app的拍照,之前h5在瀏覽器里面也是好好的,到了app里面,有些bug,最終是app原因,選擇了監(jiān)聽h5調(diào)用相機(jī)時(shí)彈出app的內(nèi)容

安淺陌 回答

試一試

text.encode('latin-1').decode('unicode_escape') 
念舊 回答

1、A自定義完成后,點(diǎn)擊跳轉(zhuǎn)到B/C/D小程序的A/B/C功能,這個(gè)需要A、B、C、D關(guān)聯(lián)在同一公眾號(hào)下(簡單、推薦、題主提出的方案)
clipboard.png

2、如果A是非個(gè)人賬號(hào)的話,可以用web-view,這樣需要提供一個(gè)可以實(shí)現(xiàn)B、C、D功能的網(wǎng)頁(如果有網(wǎng)頁的話,簡單,沒有的話,還需要開發(fā)一套)

3、A調(diào)用B、C、D開發(fā)的小程序插件(相對(duì)最麻煩)

厭惡我 回答

1.代碼拆分
2.路由按需引入
3.分模塊打包
4.js在使用時(shí)才引入 代碼中減少定時(shí)器
5.使用watch 少用deep:true 比較耗性能

悶騷型 回答

transition 包在keep-alive中看看

朕略萌 回答

在代碼 標(biāo)記后聲明 一下語言
clipboard.png

clipboard.png

我以為 回答

說下自己的理解,供參考。假設(shè)題主了解網(wǎng)絡(luò)編程和計(jì)算機(jī)系統(tǒng)的一些基本概念。

簡單概括來說,事件驅(qū)動(dòng)是實(shí)現(xiàn)并發(fā)處理的一種方式。

我們就以HTTP請(qǐng)求的處理過程為例,為簡化說明,僅考慮網(wǎng)絡(luò)IO,不考慮文件IO和數(shù)據(jù)庫等其他過程,也不考慮多核系統(tǒng)。
考慮采用如下最簡模型來處理HTTP請(qǐng)求:

main_loop:
  accept() 
  recv()  
  parse() 
  send() 
  close() 

來一個(gè)連接,讀取數(shù)據(jù)(請(qǐng)求),解析請(qǐng)求內(nèi)容,返回?cái)?shù)據(jù)(應(yīng)答)。
同一時(shí)間只為一個(gè)客戶端服務(wù)。在為A客戶端服務(wù)的過程中,B客戶端必須等待。

這種方式非常簡單直接,容易理解,但其無法滿足現(xiàn)實(shí)場景的需要——不支持并發(fā)
現(xiàn)實(shí)中,客戶端的請(qǐng)求是并發(fā)的:即當(dāng)一個(gè)客戶端的請(qǐng)求還在處理時(shí),另外一個(gè)客戶端的請(qǐng)求就會(huì)達(dá)到,甚至多個(gè)客戶端的請(qǐng)求同時(shí)達(dá)到。
而且,recv 和 send等涉及網(wǎng)絡(luò)操作的API由于網(wǎng)絡(luò)數(shù)據(jù)發(fā)送與到達(dá)的不確定性,可能需要等待,CPU會(huì)空閑下來——但這種模型下即使CPU空閑了也無法處理其他客戶端的請(qǐng)求,浪費(fèi)了CPU。

我們采用如下多線程模型,可以解決上述問題:

main_loop:
  accept() 
  start_thread(thread_loop)

thread_loop:    
    recv()  
    parse() 
    send() 
    close() 
    exit thread()

即每個(gè)客戶端在一個(gè)獨(dú)立的線程中處理。
當(dāng)一個(gè)客戶端的線程執(zhí)行網(wǎng)絡(luò)操作需要等待時(shí),會(huì)被操作系統(tǒng)調(diào)度出去,執(zhí)行其他需要干活兒的線程。
似乎完美了解決了我們的問題?
然而并沒有。
因?yàn)椴僮飨到y(tǒng)創(chuàng)建線程的開銷是比較大的,能夠支持的線程數(shù)量是有限的,通常是幾萬的級(jí)別,如果線程太多,就會(huì)有很多的CPU浪費(fèi)在了線程的創(chuàng)建、銷毀、調(diào)度等管理操作上。

所以為了充分發(fā)揮CPU的能力,支持更多的并發(fā)數(shù)量,,在Linux上有另外一種處理并發(fā)的方式:
內(nèi)核提供了監(jiān)聽大量網(wǎng)絡(luò)連接(句柄)可讀、可寫等事件的機(jī)制和接口。
應(yīng)用把需要監(jiān)聽對(duì)象以及關(guān)心的事件注冊(cè)給內(nèi)核,內(nèi)核在有事件達(dá)到時(shí)通知應(yīng)用處理。
基于這種機(jī)制處理并發(fā)就是事件驅(qū)動(dòng)。

事件驅(qū)動(dòng)機(jī)制的基本模型是:

create_listen_socket()
register_event_for_listen_socket()
main_loop:
    wait_for_event()
    check_events:
         if listen_socket has event(new client coming) :
               accept()
               register_event_for_client_socket()
        if client_socket has event(new data coming):
               recv()                       
               parse()
               send()              

但這里有一個(gè)問題,有可能一個(gè)客戶端剛讀取了一部分?jǐn)?shù)據(jù),就沒了,剩下的還在網(wǎng)絡(luò)中沒過來,需要繼續(xù)等待。
這就需要把當(dāng)前的讀取內(nèi)容和請(qǐng)求處理狀態(tài)(也即上下文)保存起來,繼續(xù)處理其他客戶端的事件。
然后下次這個(gè)客戶端再有事件到來時(shí)再找回上下文繼續(xù)處理。
這其實(shí)需要應(yīng)用自己做一些任務(wù)調(diào)度相關(guān)的上下文保存和切換工作。

當(dāng)使用多線程處理并發(fā)時(shí),操作系統(tǒng)幫我們做了這些工作,我們無需關(guān)心任務(wù)切換。
因?yàn)橐粋€(gè)線程就只處理一個(gè)客戶端,反復(fù)調(diào)用recv把一個(gè)請(qǐng)求的數(shù)據(jù)讀完然后解析處理就可以了,也不用擔(dān)心沒數(shù)據(jù)到來時(shí),recv阻塞了其他客戶端的處理。
所以多線程編寫并發(fā)代碼非常簡單直接。

如上,事件驅(qū)動(dòng)機(jī)制是Linux上解決并發(fā)問題的一種高效編程模型。
應(yīng)用反復(fù)探測(cè)事件,對(duì)接收到的事件進(jìn)行逐個(gè)處理的過程就是事件循環(huán)。

那么同步和異步概念體現(xiàn)在哪里呢?

所謂同步就是我們執(zhí)行一個(gè)任務(wù),一直等待任務(wù)執(zhí)行結(jié)束。
所謂異步就是我們執(zhí)行一個(gè)任務(wù),不等待任務(wù)執(zhí)行結(jié)束,繼續(xù)去干其他活兒,任務(wù)結(jié)果后有個(gè)通知,或者干脆不關(guān)心任務(wù)的執(zhí)行結(jié)果。

在多線程模型中,每接收到一個(gè)新的客戶端就創(chuàng)建一個(gè)線程處理,這就是一種異步處理。
在事件驅(qū)動(dòng)模型中,當(dāng)沒有數(shù)據(jù)可讀時(shí),就把這個(gè)客戶端繼續(xù)放到監(jiān)聽隊(duì)列中監(jiān)聽,也是一種異步。

如果我們考慮文件IO,把IO請(qǐng)求丟給另外一個(gè)或一組線程(線程池)處理,處理完后通知主線程,也是一種異步。

舊顏 回答

it needs to be installed alongside webpack to use the CLI

webpack-cli需要和webpack同時(shí)安裝才能生效。記?。。⊥瑫r(shí)安裝

yarn add webpack-cli webpack -D

逗婦惱 回答

個(gè)人拙見,webpack就是搞模塊化, 個(gè)人感覺你的項(xiàng)目里也用了babel。這倆經(jīng)常一起出現(xiàn),有了他倆就會(huì)有很多好處,比如說使用stage-0提案級(jí)的語法,讓代碼寫的更簡單,更模塊式開發(fā)一些。

胭脂淚 回答

看看scope.row.createTime有沒有問題。

心上人 回答

getElementsByTagNamequerySelector的區(qū)別了解一下?

Element.getElementsByTagName() 方法返回一個(gè)動(dòng)態(tài)的包含所有指定標(biāo)簽名的元素的HTML集合HTMLCollection。指定的元素的子樹會(huì)被搜索,不包括元素自己。返回的列表是動(dòng)態(tài)的,這意味著它會(huì)隨著DOM樹的變化自動(dòng)更新自身。所以,使用相同元素和相同參數(shù)時(shí),沒有必要多次的調(diào)用Element.getElementsByTagName() .

劃重點(diǎn)了啊。這意味著它會(huì)隨著DOM樹的變化自動(dòng)更新自身,他是動(dòng)態(tài)呢,那么結(jié)合console打出來的其實(shí)是快照,也是動(dòng)態(tài)的。那么得出結(jié)論,你那個(gè)時(shí)候video還沒有插入進(jìn)去。你可以用querySelector驗(yàn)證一下

傳送門-去MDN看看getElementsByTagName以及HTMLCollection

冷溫柔 回答
有效值:OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT

wx.request沒有

空痕 回答

1、前端開發(fā)的時(shí)候不是在blade模板里做的?徹底前后端分離,當(dāng)然是基于目前的laravel,配合vue做了;
2、我沒接觸過前端程序單獨(dú)放一個(gè)服務(wù)器的項(xiàng)目,應(yīng)該沒法這么做吧。。

舊言 回答

你這個(gè)是數(shù)據(jù)格式本身的問題吧。。。為什么要返回給你這個(gè)樣子的數(shù)據(jù),為什么你又要改成后面這種格式,我覺得你應(yīng)該先弄清楚這兩個(gè)問題,一般這種都是有自己的邏輯關(guān)系的。如果有邏輯關(guān)系,那你為什么要去改了,自己給自己找不痛快嗎?一般這種數(shù)據(jù)格式是用在級(jí)聯(lián)中的吧。如果沒有邏輯關(guān)系不是級(jí)聯(lián)類型,那你直接讓后端給你返回這個(gè)樣子的數(shù)據(jù)不就好了。
所以我覺得是你們項(xiàng)目這個(gè)地方的思路就錯(cuò)了,還是盡早看看需求到底是什么吧。不靠譜的產(chǎn)品可多了。