鍍金池/ 問答/ 網(wǎng)絡(luò)安全問答
慢半拍 回答 
const dependencies = {
}

// page's mainFunction
function mainFunction() {
  // Do something with sphereData and orb, ...
  // Check if sphereData defined before use it
  if (dependencies.sphereData) {
    // show the animation
  }
}

// is it desktop?
if (isDesktop) {
  Promise.all([
    import('../../assets/animation/Sphere.json'),
    import('../../assets/animation/orb.png'),
    // other dependencies
  ]).then(([
    sphere,
    orb,
    // other dependencies
  ]) => {
    dependencies.sphere = sphere
    dependencies.orb = orb
    // ...
    
    mainFunction()
  })
} else {
  mainFunction()
}

Promise.all 的用法參見：https://developer.mozilla.org...

注意有些瀏覽器下 Promise 需要 polyfill
寫得我好累~~~

不討囍 回答

我是指的是less中呢，是 @import "@/styles/xxx" 嗎？

挽歌 回答

1.首先你說自己代碼質(zhì)量不好，需要改兩三次之后才基本上沒毛病，我覺得這個問題很重要，你一定要記住你犯過的錯然后養(yǎng)成一個良好的習(xí)慣和代碼質(zhì)量，這樣即使你提PR我覺得leader也不會反感的，畢竟不是常見錯誤
2.你可以不先請learder看代碼啊，你可以自己測試下自己的代碼是否走的通，各個方面的情況是否考慮周全，確定沒問題之后可以請同事也幫忙看下，因為找別人的bug總是比自己找要容易的多。等到這些都沒問題了，你再去找leader，我覺得出現(xiàn)問題的幾率很小了，到時候就不會被別人指出弱智錯誤了。
3.怎么樣讓別人幫你codereview，找同事互相幫忙啊，互相檢查代碼。這樣不就行了，但是這個前提是你要有一個良好的代碼習(xí)慣和質(zhì)量，不要總是發(fā)現(xiàn)些小問題這樣很浪費大家時間，久而久之人家就不愿意幫助你做codereview了

久舊酒 回答

設(shè)置右邊距寬一點（right: '30%'）試試

茍活 回答

樓主現(xiàn)在找到方法了嗎？

尕筱澄 回答
  1. A類中的foo()是private，不能被繼承，所以不存在重寫;
  2. test()繼承于A類，由于foo()是不能繼承的，所以B中的foo()可以認(rèn)為是一個全新的方法;
  3. 當(dāng)A中的foo()從private變?yōu)榭衫^承的時候，B中的foo()就屬于foo()的重寫了;
  4. 這樣想調(diào)用A中的foo()的話只能用parent::foo();
結(jié)論： test()是A的，$this也是A的，調(diào)用自己私有的foo()很正常嘛。
延伸：為什么A中的foo()改為public結(jié)果不一樣了呢？
因為B是繼承A的，B把foo()繼承又重寫了，所以A中的foo()不能再用$this訪問了，只能用parent::foo()

不能繼承是關(guān)鍵。

練命 回答

@"((?![^\\]").)*[^"\\n]+"
((?!xx).)* 是不包含xx的意思，這里((?![^\\]").)*就是不包含非\"之外的"。

最后發(fā)現(xiàn)原來只是Mac Numbers不支持而已

柚稚 回答

你的這種比較方式不太對，紅黑樹其實是2-3查找樹的一種比較優(yōu)雅的實現(xiàn)。
性能的量度不光光考慮時間復(fù)雜度，還有空間復(fù)雜度，以及工程難度。
紅黑樹出現(xiàn)的原因在于二叉查找樹的不平衡問題。紅黑樹能比較好的維持平衡。
當(dāng)然了，4階B樹也可以，但是其實他比2-3查找樹更復(fù)雜，但對于問題的解決卻沒有比較明顯的改善。

可以好好看看2-3查找樹的插入操作實現(xiàn)，對應(yīng)結(jié)合紅黑樹，會有意想不到的收獲

雨蝶 回答

clipboard.png

<router-link :to="{path:'storeIndex',query:{storeId:item.id}}" exact></router-link>

或者

this.$router.push({
  path: "orderSettlement",
  query: {
      id: goodId,
      optionid: optionid,
      total: goods_num
  }
});
雨萌萌 回答

你這個做法React官方稱為Lifting State Up，因此并不是野雞行為

如果你能保證結(jié)構(gòu)的扁平（至少在大部分情況下），同時控制共享狀態(tài)的組件的規(guī)模，沒必要用redux。

只有你的組件結(jié)構(gòu)太深，或者有很多個不同層次的組件同時依賴同一個狀態(tài)，才需要使用Redux。新技術(shù)是有成本的，redux的模板代碼也是廣為詬病，只有你覺得當(dāng)前的技術(shù)方案力不從心時再考慮新技術(shù)。

另外react在16.3會引入一個新的context API，redux的作者都戲稱“可以不用Redux”了，也許這個新的context API會改善你的處境

凝雅 回答

A2A

Your error is caused by printHello in print.h, it should be printfHello, so just a typo.

You can refer to another my answer here: https://segmentfault.com/q/10...

Update

it seems you write wrong compile commands, try simplest solution:

 gcc print.c test.c 
 ./a.out
焚音 回答

1.上傳的時候就把gif圖片處理好存儲靜態(tài)預(yù)覽圖和原始圖。
2.或者訪問時通過參數(shù)再處理，比如七牛就有圖片處理
https://developer.qiniu.com/d...

PS:客戶端處理是不現(xiàn)實的，因為如果原始獲取的就是gif的話流量和加載時間就用掉了，也沒必要在處理了

孤客 回答

不介意的話，把路由的代碼展示一下

凹凸曼 回答

請求參數(shù)和代理沒有關(guān)系。
首先單獨調(diào)一下后臺的接口，看看是不是能通。確定不是后臺的問題
然后前臺服務(wù)修改webpack 配置，最好重啟一下。另外仔細(xì)查看控制臺。有些代理會出現(xiàn)兩條

乖乖噠 回答

1、最簡單的做法

// html
<div>
    <img src="1.png" alt="">
</div>

// css
div {
    width: 200px;
    height: 200px;
    border: 1px solid #ddd;
}
img {
    width: 100%;
    height: 100%;
}

不管父容器有多高多寬，只要將img的寬高設(shè)置成100%（這里的100%是相對于父元素寬高而言）就能自適應(yīng)容器大小。不過該方法可能出現(xiàn)失真。

2、考慮失真的做法

img {
    max-width: 100%;
    max-height: 100%;
}

max-width:100%和width:100%到底有什么區(qū)別呢？max-width是相對于img自身的尺寸而言的，也就是圖片最大寬度為自身尺寸的寬。而width的100%是相對于父元素寬度的，所以max-*可以不讓圖片因放大而失真。不過該方法可能出現(xiàn)留白。

3、考慮留白的做法

假如你的img是作為background使用的就需要通過background-size: cover/contain。cover和contain到底有什么區(qū)別呢？cover把背景圖像擴展至足夠大，以使背景圖像完全覆蓋背景區(qū)域。背景圖像的某些部分也許無法顯示在背景定位區(qū)域中。而contain把圖像圖像擴展至最大尺寸，以使其寬度和高度完全適應(yīng)內(nèi)容區(qū)域。

首頁 上一頁 46 47 48 49 50 51 52 53 54 下一頁 尾頁