292020-4

函數(shù)節(jié)流與函數(shù)防抖的區(qū)別

函數(shù)節(jié)流與函數(shù)防抖是我們解決頻繁觸發(fā)DOM事件的兩種常用解決方案，但是經(jīng)常傻傻分不清楚。。。這不，在項目中又用遇到了，在此處記錄一下

函數(shù)防抖 debounce

原理：將若干函數(shù)調(diào)用合成為一次，并在給定時間過去之后，或者連續(xù)事件完全觸發(fā)完成之后，調(diào)用一次(僅僅只會調(diào)用一次?。。。。。。。。。?。

舉個栗子：滾動scroll事件，不?；瑒訚L輪會連續(xù)觸發(fā)多次滾動事件，從而調(diào)用綁定的回調(diào)函數(shù)，我們希望當我們停止?jié)L動的時，才觸發(fā)一次回調(diào)，這時可以使用函數(shù)防抖。

原理性代碼及測試：

// 給盒子較大的height，容易看到效果

<style>

* {

padding: 0;

margin: 0;

}

.box {

width: 800px;

height: 1200px;

}

</style>

<body>

<div class="container">

<div class="box" style="background: tomato"></div>

<div class="box" style="background: skyblue"></div>

<div class="box" style="background: red"></div>

<div class="box" style="background: yellow"></div>

</div>

<script>

window.onload = function() {

const decounce = function(fn, delay) {

let timer = null

return function() {

const context = this

let args = arguments

clearTimeout(timer) // 每次調(diào)用debounce函數(shù)都會將前一次的timer清空，確保只執(zhí)行一次

timer = setTimeout(() => {

fn.apply(context, args)

}, delay)

}

}

let num = 0

function scrollTap() {

num++

console.log(看看num吧 ${num})

}

// 此處的觸發(fā)時間間隔設(shè)置的很小

document.addEventListener('scroll', decounce(scrollTap, 500))

// document.addEventListener('scroll', scrollTap)

}

</script>

</body>

此處的觸發(fā)時間間隔設(shè)置的很小，如果勻速不間斷的滾動，不斷觸發(fā)scroll事件，如果不用debounce處理，可以發(fā)現(xiàn)num改變了很多次，用了debounce函數(shù)防抖，num在一次上時間的滾動中只改變了一次。

調(diào)用debouce使scrollTap防抖之后的結(jié)果：

直接調(diào)用scrollTap的結(jié)果：

補充：瀏覽器在處理setTimeout和setInterval時，有最小時間間隔。

setTimeout的最短時間間隔是4毫秒；

setInterval的最短間隔時間是10毫秒，也就是說，小于10毫秒的時間間隔會被調(diào)整到10毫秒。

事實上，未優(yōu)化時，scroll事件頻繁觸發(fā)的時間間隔也是這個最小時間間隔。

也就是說，當我們在debounce函數(shù)中的間隔事件設(shè)置不恰當（小于這個最小時間間隔），會使debounce無效。

函數(shù)節(jié)流 throttle

原理：當達到了一定的時間間隔就會執(zhí)行一次；可以理解為是縮減執(zhí)行頻率

舉個栗子：還是以scroll滾動事件來說吧，滾動事件是及其消耗瀏覽器性能的，不停觸發(fā)。以我在項目中碰到的問題，移動端通過scroll實現(xiàn)分頁，不斷滾動，我們不希望不斷發(fā)送請求，只有當達到某個條件，比如，距離手機窗口底部150px才發(fā)送一個請求，接下來就是展示新頁面的請求，不停滾動，如此反復(fù)；這個時候就得用到函數(shù)節(jié)流。

原理性代碼及實現(xiàn)

// 函數(shù)節(jié)流 throttle

// 方法一：定時器實現(xiàn)

const throttle = function(fn,delay) {

let timer = null

return function() {

const context = this

let args = arguments

if(!timer) {

timer = setTimeout(() => {

fn.apply(context,args)

clearTimeout(timer)

},delay)

}

}

}

// 方法二：時間戳

const throttle2 = function(fn, delay) {

let preTime = Date.now()

return function() {

const context = this

let args = arguments

let doTime = Date.now()

if (doTime - preTime >= delay) {

fn.apply(context, args)

preTime = Date.now()

}

}

}

需要注意的是定時器方法實現(xiàn)throttle方法和debounce方法的不同：

在debounce中：在執(zhí)行setTimeout函數(shù)之前總會將timer用setTimeout清除，取消延遲代碼塊，確保只執(zhí)行一次

在throttle中：只要timer存在就會執(zhí)行setTimeout，在setTimeout內(nèi)部每次清空這個timer，但是延遲代碼塊已經(jīng)執(zhí)行啦，確保一定頻率執(zhí)行一次

我們依舊可以在html頁面中進行測試scroll事件，html和css代碼同debounce，此處不贅述，運行結(jié)果是（可以說是一場漫長的滾輪滾動了）：

最后再來瞅瞅項目中封裝好的debounce和throttle函數(shù)，可以說是很優(yōu)秀了，考慮的特別全面，希望自己以后封裝的函數(shù)也能考慮的這么全面吧，加油！

/*

空閑控制返回函數(shù)連續(xù)調(diào)用時，空閑時間必須大于或等于 wait，func 才會執(zhí)行

@param {function} func 傳入函數(shù)，最后一個參數(shù)是額外增加的this對象，.apply(this, args) 這種方式，this無法傳遞進函數(shù)

@param {number} wait 表示時間窗口的間隔

@param {boolean} immediate 設(shè)置為ture時，調(diào)用觸發(fā)于開始邊界而不是結(jié)束邊界

@return {function} 返回客戶調(diào)用函數(shù)

/

const debounce = function(func, wait, immediate) {

let timeout, args, context, timestamp, result;

const later = function() {

// 據(jù)上一次觸發(fā)時間間隔

let last = Number(new Date()) - timestamp;

// 上次被包裝函數(shù)被調(diào)用時間間隔last小于設(shè)定時間間隔wait

if (last < wait && last > 0) {

timeout = setTimeout(later, wait - last);

} else {

timeout = null;

// 如果設(shè)定為immediate===true，因為開始邊界已經(jīng)調(diào)用過了此處無需調(diào)用

if (!immediate) {

result = func.call(context, ...args, context);

if (!timeout) {

context = args = null;

}

}

}

};

return function(..._args) {

context = this;

args = _args;

timestamp = Number(new Date());

const callNow = immediate && !timeout;

// 如果延時不存在，重新設(shè)定延時

if (!timeout) {

timeout = setTimeout(later, wait);

}

if (callNow) {

result = func.call(context, ...args, context);

context = args = null;

}

return result;

};

};

/*

頻率控制返回函數(shù)連續(xù)調(diào)用時，func 執(zhí)行頻率限定為次 / wait

@param {function} func 傳入函數(shù)

@param {number} wait 表示時間窗口的間隔

@param {object} options 如果想忽略開始邊界上的調(diào)用，傳入{leading: false}。

如果想忽略結(jié)尾邊界上的調(diào)用，傳入{trailing: false}

@return {function} 返回客戶調(diào)用函數(shù)

*/

const throttle = function(func, wait, options) {

let context, args, result;

let timeout = null;

// 上次執(zhí)行時間點

let previous = 0;

if (!options) options = {};

// 延遲執(zhí)行函數(shù)

let later = function() {

// 若設(shè)定了開始邊界不執(zhí)行選項，上次執(zhí)行時間始終為0

previous = options.leading === false ? 0 : Number(new Date());

timeout = null;

result = func.apply(context, args);

if (!timeout) context = args = null;

};

return function(..._args) {

let now = Number(new Date());

// 首次執(zhí)行時，如果設(shè)定了開始邊界不執(zhí)行選項，將上次執(zhí)行時間設(shè)定為當前時間。

if (!previous && options.leading === false) previous = now;

// 延遲執(zhí)行時間間隔

let remaining = wait - (now - previous);

context = this;

args = _args;

// 延遲時間間隔remaining小于等于0，表示上次執(zhí)行至此所間隔時間已經(jīng)超過一個時間窗口

// remaining大于時間窗口wait，表示客戶端系統(tǒng)時間被調(diào)整過

if (remaining <= 0 || remaining > wait) {

clearTimeout(timeout);

timeout = null;

previous = now;

result = func.apply(context, args);

if (!timeout) context = args = null;

//如果延遲執(zhí)行不存在，且沒有設(shè)定結(jié)尾邊界不執(zhí)行選項

} else if (!timeout && options.trailing !== false) {

timeout = setTimeout(later, remaining);

}

return result;

};

};

評論(0) 瀏覽(2484)

282020-4

超簡單入門Vuex小示例

seo達人

寫在前面

本文旨在通過一個簡單的例子，練習(xí)vuex的幾個常用方法，使初學(xué)者以最快的速度跑起來一個vue + vuex的示例。

學(xué)習(xí)vuex需要你知道vue的一些基礎(chǔ)知識和用法。相信點開本文的同學(xué)都具備這個基礎(chǔ)。

另外對vuex已經(jīng)比較熟悉的大佬可以忽略本文。

生成基于vue的項目

基于vue-cli腳手架生成一個vue項目
常用npm命令：

npm i vue-vli -g vue --version vue init webpack 項目名

進入項目目錄，使用npm run dev先試著跑一下。

一般不會出現(xiàn)問題，試跑成功后，就可以寫我們的vuex程序了。

使用vue完成的示例

使用vuex首先得安裝vuex，命令：

npm i vuex --save

介紹一下我們的超簡單Demo，一個父組件，一個子組件，父組件有一個數(shù)據(jù)，子組件有一個數(shù)據(jù)，想要將這兩個數(shù)據(jù)都放置到vuex的state中，然后父組件可以修改自己的和子組件的數(shù)據(jù)。子組件可以修改父組件和自己的數(shù)據(jù)。

先放效果圖，初始化效果如下：

如果想通過父組件觸發(fā)子組件的數(shù)據(jù)，就點“改變子組件文本”按鈕，點擊后效果如下：

如果想通過子組件修改父組件的數(shù)據(jù)，就在子組件點擊“修改父組件文本”按鈕，點擊后效果如下：

代碼文件介紹

首先是Parent.vue組件

<template> <div class="parent"> <h3>這里是父組件</h3> <button type="button" @click="clickHandler">修改自己文本</button> <button type="button" @click="clickHandler2">修改子組件文本</button> <div>Test: {{msg}}</div> <child></child> </div> </template> <script> import store from '../vuex' import Child from './Child.vue' export default { computed: {
            msg(){ return store.state.testMsg;
            }
        }, methods:{
            clickHandler(){
                store.commit('changeTestMsg', '父組件修改自己后的文本')
            },
            clickHandler2(){
                store.commit('changeChildText', '父組件修改子組件后的文本')
            }
        }, components:{ 'child': Child
        },
        store,
    } </script> <style scoped> .parent{ background-color: #00BBFF; height: 400px;
    } </style>

下面是Child.vue子組件

<template> <div class="child"> <h3>這里是子組件</h3> <div>childText: {{msg}}</div> <button type="button" @click="clickHandler">修改父組件文本</button> <button type="button" @click="clickHandler2">修改自己文本</button> </div> </template> <script> import store from '../vuex' export default { name: "Child", computed:{
            msg(){ return store.state.childText;
            }
        }, methods: {
            clickHandler(){
                store.commit("changeTestMsg", "子組件修改父組件后的文本");
            },
            clickHandler2(){
                store.commit("changeChildText", "子組件修改自己后的文本");
            }
        },
        store
    } </script> <style scoped> .child{ background-color: palegreen; border:1px solid black; height:200px; margin:10px;
    } </style>

最后是vuex的配置文件

 import Vue from 'vue' import Vuex from 'vuex';

Vue.use(Vuex) const state = { testMsg: '原始文本', childText:"子組件原始文本" } const mutations = {
    changeTestMsg(state, str){
        state.testMsg = str;
    },
    changeChildText(state, str){
        state.childText = str;
    }

} const store = new Vuex.Store({ state: state, mutations: mutations
}) export default store;

后記

通過該vuex示例，了解vuex的常用配置及方法調(diào)用。希望對不怎么熟悉vuex的同學(xué)快速上手vuex項目有點幫助。

因為沒太多東西，我自己也是剛接觸，本例就不往GitHub扔了，如果嘗試了本例，但是沒有跑起來的同學(xué)，可以一起交流下。

評論(0) 瀏覽(2543)

282020-4

為何深色模式看起來不自然？

ui設(shè)計分享達人

為何深色模式看起來不自然？它的實用性到底怎么樣？深色模式是不是對眼睛更健康？結(jié)合文獻，我們一起來探究深色模式的種種！

在過去的幾年中，深色模式一直是用戶最期待的一個功能。你可以自由切換你喜歡的模式來適應(yīng)當前的場景，iOS和Android也都在2019年布局了系統(tǒng)級的深色模式，深色模式可獲得出色的視覺體驗，尤其是在弱光環(huán)境中……有助于你專注地開展工作，因為內(nèi)容會較為顯眼，而顏色加深的控制項和窗口則會隱入背景之中。但真是這樣嗎，或者只是一種實際上弊大于利的操作？

文章內(nèi)容：

1、什么是深色模式

2、從可用性角度看深色模式

3、為什么深色模式看起來不自然

4、從設(shè)計角度看深色模式

5、結(jié)論

什么是深色模式？

雖然各種軟件界面的色調(diào)和顏色會有所不同，但是對深色模式的處理方式都是在深色背景上顯示明亮文本和界面元素的配色方案。相比之下，在淺色背景上顯示深色文本和界面元素的配色方案，在這里我們稱之為淺色模式。

而事實上，深色模式比淺色模式早了幾十年。在其最初的階段，深色模式并不是一種有意的解決方案，而僅僅是當時計算顯示設(shè)備是陰極射線管（CRT），且只能顯示單色的顯示，屏幕看上去就是黑的，黑底白字或者黑底綠字就是計算機行業(yè)的早期狀態(tài)。直到1980年代彩色顯示器發(fā)明后，微軟視窗系統(tǒng)上線之后，黑底顯示才退出主流。蘋果在1984年推出“麥金塔”個人電腦，第一次發(fā)布采用圖形用戶界面，由此開啟了計算機屏幕白底顯示的主流之路。

ibm 5151單色監(jiān)視器

淺色模式出現(xiàn)的確切時間很難確定，但可以追溯到施樂Parc圖形用戶界面，它也極大地影響了早期蘋果的“麥金塔”和其他操作系統(tǒng)，該界面使用了以白色背景為主的深色文本和界面元素。它與顯示技術(shù)的進步和現(xiàn)代圖形用戶界面的出現(xiàn)密切相關(guān)。這種能夠顯示色彩的且更先進的RGB CRT顯示器拉開了淺色模式的序幕。

1973年的施樂Alto是最早使用輕型接口模式的計算機之一

從可用性角度看深色模式

深色模式的實用性有多少，每個人看法也不一樣。盡管深色模式的界面可能不像淺色模式那樣觀感清晰，但深色模式的界面卻具有一定的魅力，可以讓你聯(lián)想到新穎，高端，精致，神秘，力量，奢華這些詞。但是，黑色也是一種會引起人們強烈的情感一個顏色，并且在過度使用時很容易使人無法承受。

2019年9月，蘋果公司上線深色模式（Dark Model）時，在官網(wǎng)上如是宣傳道。從iPhone到Mac，當庫克決定在蘋果公司幾乎所有產(chǎn)品上線深色模式、甚至要求所有在AppStore上架的應(yīng)用都必須兼容深色模式時，安卓陣營的谷歌、華為、三星等頭部公司也紛紛在其手機中推出了深色模式，相應(yīng)地從WhatsApp到微信等全球主流的應(yīng)用也都推出了深色模式。

但是，想要獲得良好的深色模式是相對比較難的。一方面，深色模式迫使放大瞳孔來捕獲必要的視覺信息，從而導(dǎo)致整體清晰度的降低。而同時界面中高亮的部分又迫使我們的瞳孔縮小去適應(yīng)亮度，以便提高清晰度。這也就能理解為什么白色背景上的黑色文本在你的眼睛中通常會顯得更清晰的原因。

擴大的瞳孔讓光線更多，但感覺到的銳度受到損害

行業(yè)對深色模式追逐的群羊效應(yīng)，也進一步加劇、放大了一個見解：深色模式對眼睛更友好更健康！

但是，事實并非如此。對于一些有散光的人來說，在某種程度上深色模式對他們的眼睛來說更糟糕，深色模式比淺色模式更友好更健康的科學(xué)仍有待討論。斯坦?！ぐ轄査寡劭蒲芯克难劭茖＜覍Υ吮硎荆骸拌b于文獻中的數(shù)據(jù)，我認為深色模式對眼睛沒有任何的友好和健康?！?nbsp;這種深色模式對眼睛疲勞和潛在的眼睛健康的影響時，使用時間可能比設(shè)備的亮度或亮度更重要。

根據(jù)美國驗光協(xié)會的說法稱，大多數(shù)人的眼睛在某種程度上都患有散光，但通常不會引起注意。據(jù)美國眼科學(xué)院統(tǒng)計，每三個美國人中就一個存在散光的情況，1.5億美國人需要佩戴眼鏡來矯正視力；香港理工大學(xué)針對2700多人的臨床檢測發(fā)現(xiàn)，在21歲的30歲的香港人中，近40%以上患有100度以上散光。

一起看下面的說明性圖像。即使你有完美的視覺，你也很可能在黑色背景上看到白色文字周圍的光暈。

淺色模式與深色模式

如果增加文字并降低文字的大小，這種效果可能會更強：

右邊的圖像你應(yīng)該會看到更多的光暈，如果你有散光癥狀，深色模式可能會讓你看屏幕更費勁。在深色模式下，虹膜打開以接收更多的光，并且瞳孔的變形在眼睛上產(chǎn)生了更加模糊的焦點，因此，當你在深色屏幕上看到淺色文本時，其邊緣似乎滲入黑色背景，也就是所謂的“光暈效果”。雖然深色模式可能更適合夜晚等弱光環(huán)境下使用，但不一定能幫助更好地閱讀，對于散光患者來說，可能還會加劇視疲勞。

當然，從實用性上講，深色模式也有它的好處，深色模式利用OLED屏幕在純黑的背景下不發(fā)光的特性，確實能有效的省電，讓你的電子設(shè)備續(xù)航上提升很大，這也是很多人一直在追求深色模式的一個重要原因，只要手機續(xù)航強比啥都重要！這也可能是蘋果公司決定在幾乎所有產(chǎn)品上線深色模式的一個原因。

另外深色模式更有利于給用戶營造一種沉浸體驗，對于視覺娛樂應(yīng)用尤為如此。當你想突出顯示特定類型的內(nèi)容時，深色模式會特別有用。豆瓣、數(shù)字尾巴、網(wǎng)易云音樂是我常用的幾個軟件，它們都已經(jīng)適配了深色模式。在這種模式下你的目光會更加注意到電影的海報、數(shù)碼產(chǎn)品和充滿活力的音樂專輯上。

豆瓣、數(shù)字尾巴、網(wǎng)易云音樂的深色模式

為什么深色模式看起來不自然

一是由于我們?nèi)四X的組織結(jié)構(gòu)造成的，從多年來的多項科學(xué)研究和調(diào)查得出的結(jié)論是，從物種進化來看，人類99%的時間都是在白天中活動，人腦更傾向于在淺的背景上顯示深色的圖像。所以無論白天還是黑夜，淺色的背景都可以讓你更快地專注于顯示的元素，而深色的背景則使其難以辨別文字和視覺界面元素，從而影響你的閱讀效果并最終使你的眼睛疲勞。其實從世界各地多個洞穴中發(fā)現(xiàn)的史前壁畫也能說明為什么我們傾向于喜歡淺色模式。

追逐獵物的獅子，法國Chauvet Cave，約公元前30,000-28,000

德國帕紹大學(xué)曾經(jīng)做過一次測試。在該研究要求參與者閱讀屏幕上的正極性（白色背景上的黑色文本）或負極性（黑色背景上的白色文本）的文本。隨后，參與測試的人員會執(zhí)行基本的校對任務(wù)，例如查找拼寫或語法錯誤。研究人員還測量了每種模式下參與者的閱讀速度。結(jié)果是所有參與者在正極性條件下的表現(xiàn)都會更好，他們檢查出更多的錯誤以及閱讀的速度更快。

可讀性差異

另一個學(xué)習(xí)發(fā)現(xiàn)正極性對于在顯示器上讀取小文本特別有利。人腦具有更快的可讀性，更喜歡在光線背景下顯示的深色文本和物體。

二是由于含有大量藍光的光源會使我們眼睛不舒服，當我們談?wù)撈聊粚ρ劬Φ臐撛谄茐男杂绊憰r，我們通常是在談?wù)摗八{光”，這是由短、高能量波長構(gòu)成的光譜的一部分。研究發(fā)現(xiàn)藍光可能是導(dǎo)致眼睛疲勞的一個因素，但指出長時間不眨眼的干眼也是導(dǎo)致眼睛疲勞的一個更嚴重的原因，當然也有是因為字體太小，以及散光這樣的原因。

當我們身處暗室或是在黃昏或夜晚時，眼睛會切換成不同的視覺模式；在弱光環(huán)境下，人眼會從對綠色敏感變成對高能量藍光敏感，這代表我們在大量的接收藍光，因此對刺眼強光的敏感度會增強。這類情形對駕駛?cè)硕圆⒉荒吧斔麄儽粊碥囓囶^燈的強光照射時，特別是使用現(xiàn)代化氙氣燈或LED頭燈的車輛，可能會暫時喪失視力。

平板電腦、智能手機和其他電子顯示屏，不僅改變了我們所接觸的光譜，也使我們的視覺行為發(fā)生轉(zhuǎn)變。我們必須意識到，我們現(xiàn)在用于“近距離”視物的時間比以往多得多，這通常是因為背景亮度太暗所致。

在德國光學(xué)公司蔡司官方網(wǎng)站上，對于藍光也作一分為二的評價：“好處是當外界環(huán)境變亮也就是藍光較多時，身體便釋放出血清素—它是其中一種快樂荷爾蒙以及皮質(zhì)醇—這是一種壓力荷爾蒙。這兩種荷爾蒙能讓我們保持清醒，富有活力，同時也應(yīng)用于冬季抑郁和失眠的治療中。但過多的紫外光和藍紫光可能會對肉眼造成損傷，除了可能導(dǎo)致令人難受的結(jié)膜和角膜發(fā)炎，也可能會破壞眼睛的晶狀體（例如白內(nèi)障），尤其是傷害我們的視網(wǎng)膜（黃斑病變）?！?

從設(shè)計角度看深色模式

在WWDC 2019大會上，蘋果宣布了iOS13的深色模式功能，在令人興奮之余，作為設(shè)計師和開發(fā)人員，我們應(yīng)該考慮的該如何去實現(xiàn)它。蘋果和安卓已經(jīng)發(fā)布了為應(yīng)用程序設(shè)計深色模式的設(shè)計指南。當然，沒有硬性規(guī)定要求遵循他們提供的設(shè)計指南，這些只是指導(dǎo)原則。

由于Material Design設(shè)計語言的原因，投影的占比是非常大的。在淺色模式下還好，但這不太適用于深色模式，因為深色背景上的黑色陰影在視覺上不容易察覺，為此安卓還提供了在深色模式下不同層級的卡片與投影上的參考。

根據(jù)設(shè)計文檔來看，iOS背景為純黑色，色值為＃000000，Google 則更喜歡深灰色，色值為＃121212。

通過提供的設(shè)計指南，我們可以輕易上手來設(shè)計和開發(fā)我們的軟件，但要注意的是深色模式并不是簡單的與淺色模式顏色對調(diào)，必須為所有的元素進行單獨配色。

淺色模式下的白色不會在深色模式下轉(zhuǎn)換成純黑色

這樣也就能理解為什么很多軟件并沒有全部去適配新的深色模式，一方面使用場景決定的，另一方面就是深色模式并不是簡單地換個換個顏色就行，很多元素需要重新設(shè)計和開發(fā)。

結(jié)論：該選擇哪種模式

在去年的 WWDC 大會上，蘋果人機交互團隊的設(shè)計師曾對 macOS 的深色模式使用場景做了進一步的解釋。

他指出，只有閱讀瀏覽或是內(nèi)容創(chuàng)作型 App 才需要長期啟用深色模式，比如文字或代碼編輯。它們會借助黑底白字的高對比度特性來讓用戶視線保持集中，其它大部分軟件對于深色模式的需求反而并不強烈。

或則你可以通過使用場景去選擇，在明亮的環(huán)境中使用淺色模式，在昏暗的環(huán)境中使用深色模式。

但是在大多數(shù)情況下，真正幫助你避免眼睛疲勞的是不要整天盯著屏幕，而不是糾結(jié)到底用深色還是淺色模式。

轉(zhuǎn)自：站酷-

評論(0) 瀏覽(3164)

272020-4

移動端列表查詢最佳實踐

seo達人

無論是 pc 端還是移動端，無可避免都會涉及到列表查詢有關(guān)的操作，但對于這兩種不同的設(shè)備，其列表查詢的最佳處理方式也是完全不同。

對于 pc 端列表查詢來說，前端通常是給與服務(wù)端當前需要獲取的數(shù)據(jù)量(如 pageCount，limit 等參數(shù))以及所需要獲取數(shù)據(jù)的位置(如 pageSize，offset 等參數(shù))作為查詢條件。然后服務(wù)端然后返回數(shù)據(jù)總數(shù)，以及當前數(shù)據(jù)，前端再結(jié)合這些數(shù)據(jù)顯示頁面總數(shù)等信息。這里我稱為相對位置取數(shù)。

對于移動端而言，沒有pc 端那么大的空間展示以及操作，所以基本上都會采用下拉取數(shù)這種方案。

那么我們在處理移動端列表查詢時候使用這種相對位置取數(shù)會有什么問題呢？

相對位置取數(shù)存在的問題

性能劣勢

通過相對位置取數(shù)會具有性能問題，因為一旦使用 offset 信息來獲取數(shù)據(jù)，隨著頁數(shù)的增加，響應(yīng)速度也會變的越來越慢。因為在數(shù)據(jù)庫層面，我們每次所獲取的數(shù)據(jù)都是“從頭開始第幾條”，每次我們都需要從第一條開始計算，計算后舍棄前面的數(shù)據(jù)，只取最后多條數(shù)據(jù)返回前端。

當然了，對于相對位置取數(shù)來說，數(shù)據(jù)庫優(yōu)化是必然的，這里我就不多做贅述了。對于前端開發(fā)來說，優(yōu)秀的的查詢條件設(shè)計可以在一定方面解決此問題。

數(shù)據(jù)顯示重復(fù)

事實上，對于一個實際運行的項目而言，數(shù)據(jù)更新才是常態(tài)，如果數(shù)據(jù)更新的頻率很高或者你在當前頁停留的時間過久的話，會導(dǎo)致當前獲取的數(shù)據(jù)出現(xiàn)一定的偏差。

例如：當你在獲取最開始的 20 條數(shù)據(jù)后，正準備獲取緊接著的后 20 條數(shù)據(jù)時，在這段時間內(nèi) ，發(fā)生了數(shù)據(jù)增加，此時移動端列表就可能會出現(xiàn)重復(fù)數(shù)據(jù)。雖然這個問題在 pc 端也存在，但是 pc 端只會展示當前頁的信息，這樣就避免了該問題所帶來的負面影響。

結(jié)合列表 key 維持渲染正確

我們在上面的問題中說明了，移動端下拉加載中使用相對位置查詢?nèi)?shù)是有問題的。

那么，如果當前不能迅速結(jié)合前后端進行修改 api 的情況下，當服務(wù)端傳遞過來的數(shù)據(jù)與用戶想要得的數(shù)據(jù)不一致，我們必須在前端進行處理，至少處理數(shù)據(jù)重復(fù)問題所帶來的負面影響。

因為當前分頁請求時無狀態(tài)的。在分頁取到數(shù)據(jù)之后前端可以對取得的數(shù)據(jù)進行過濾，過濾掉當前頁面已經(jīng)存在的 key(例如 id 等能夠確定的唯一鍵)。

通過這種處理方式，我們至少可以保證當前用戶看到的數(shù)據(jù)不會出現(xiàn)重復(fù)。同時當列表數(shù)據(jù)可以編輯修改的時候，也不會出現(xiàn)因為 key 值相同而導(dǎo)致數(shù)據(jù)錯亂。

通過絕對位置獲取數(shù)據(jù)

如果不使用相對位置獲取數(shù)據(jù)，前端可以利用當前列表中的最后一條數(shù)據(jù)作為請求源參數(shù)。前端事先記錄最后一條數(shù)據(jù)的信息。例如當前的排序條件為創(chuàng)建時間，那么記錄最后一條數(shù)據(jù)的創(chuàng)建時間為主查詢條件(如果列表對應(yīng)的數(shù)據(jù)不屬于個人，可能創(chuàng)建時間不能唯一決定當前數(shù)據(jù)位置，同時還需要添加 ID 等信息作為次要查詢條件)。

當我們使用絕對位置獲取數(shù)據(jù)時候，雖然我們無法提供類似于從第 1 頁直接跳轉(zhuǎn) 100 頁的查詢請求，但對于下拉加載這種類型的請求，我們不必擔(dān)心性能以及數(shù)據(jù)重復(fù)顯示的問題。

對于相對位置取數(shù)來說，前端可以根據(jù)返回數(shù)據(jù)的總數(shù)來判斷。但當使用絕對位置取數(shù)時，即使獲取數(shù)據(jù)總數(shù)，也無法判斷當前查詢是否存在后續(xù)數(shù)據(jù)。

從服務(wù)器端實現(xiàn)的角度來說，當用戶想要得到 20 條數(shù)據(jù)時候，服務(wù)端如果僅僅只向數(shù)據(jù)庫請求 20 條數(shù)據(jù)，是無法得知是否有后續(xù)數(shù)據(jù)的。服務(wù)端可以嘗試獲取當前請求的數(shù)據(jù)條數(shù) + 1, 如向數(shù)據(jù)庫請求 21 條數(shù)據(jù)，如果成功獲得 21 條數(shù)據(jù)，則說明至少存在著 1 條后續(xù)數(shù)據(jù)，這時候，我們就可以返回 20 條數(shù)據(jù)以及具有后續(xù)數(shù)據(jù)的信息。但如果我們請求 21 條數(shù)據(jù)卻僅僅只能獲取 20 條數(shù)據(jù)(及以下)，則說明沒有后續(xù)數(shù)據(jù)。

如可以通過 “hasMore” 字段來表示是否能夠繼續(xù)下拉加載的信息。

{ data: [], hasMore: true }

結(jié)合 HATEOAS 設(shè)計優(yōu)化

事實上，前面我們已經(jīng)解決了移動端處理列表查詢的問題。但是我們做的還不夠好，前端還需要結(jié)合排序條件來處理并提供請求參數(shù)，這個操作對于前端來說也是一種負擔(dān)。那么我們就聊一下 HATEOAS 。

HATEOAS (Hypermedia As The Engine Of Application State, 超媒體即應(yīng)用狀態(tài)引起) 這個概念最早出現(xiàn)在 Roy Fielding 的論文中。REST 設(shè)計級別如下所示:

REST LEVEL 0: 使用 HTTP 作為傳輸方式
REST LEVEL 1: 引入資源的概念(每一個資源都有對應(yīng)的標識符和表達)
REST LEVEL 2: 引入 HTTP 動詞(GET 獲取資源/POST 創(chuàng)建資源/PUT 更新或者創(chuàng)建字樣/DELETE 刪除資源等)
REST LEVEL 3: 引入 HATEOAS (在資源的表達中包含了鏈接信息。客戶端可以根據(jù)鏈接來發(fā)現(xiàn)可以執(zhí)行的動作)

HATEOAS 會在 API 返回的數(shù)據(jù)中添加下一步要執(zhí)行的行為，要獲取的數(shù)據(jù)等 URI 的鏈接信息?？蛻舳酥灰@取這些信息以及行為鏈接，就可以根據(jù)這些信息進行接下來的操作。

對于當前的請求來說，服務(wù)端可以直接返回下一頁的信息，如

{ data: [], hasMore: true, nextPageParams: {}    
}

服務(wù)端如此傳遞數(shù)據(jù)，前端就不需要對其進行多余的請求處理，如果當前沒有修改之前的查詢以及排序條件，則只需要直接返回 “nextPageParams” 作為下一頁的查詢條件即可。

這樣做的好處不但符合 REST LEVEL 3,同時也減輕了前端的心智模型。前端無需配置下一頁請求參數(shù)。只需要在最開始查詢的時候提供查詢條件即可。

當然，如果前端已經(jīng)實現(xiàn)了所有排序添加以及查詢條件由服務(wù)端提供，前端僅僅提供組件，那么該方案更能體現(xiàn)優(yōu)勢。前端是不需要知道當前業(yè)務(wù)究竟需要什么查詢條件，自然也不需要根據(jù)查詢條件來組織下一頁的條件。同時，該方案的輸入和輸出都由后端提供，當涉及到業(yè)務(wù)替換( 查詢條件，排序條件修改)時候，前端無需任何修改便可以直接替換和使用。

其他注意事項

一旦涉及到移動端請求，不可避免的會有網(wǎng)絡(luò)問題，當用戶在火車或者偏遠地區(qū)時候，一旦下拉就會涉及取數(shù)，但是當前數(shù)據(jù)沒有返回之前，用戶多次下拉可能會有多次取數(shù)請求，雖然前端可以結(jié)合 key 使得渲染不出錯，但是還是會在緩慢的網(wǎng)絡(luò)下請求多次，無疑雪上加霜。這時候我們需要增加條件變量 loading。

偽代碼如下所示：

// 查詢 function search(cond) {
  loading = true api.then(res => {
      loading = false }).catch(err => {
      loading = false })
} // 獲取下一頁數(shù)據(jù) function queryNextPage() { if (!nextPageParams) return if (!loading) return search(nextPageParams)
}

評論(0) 瀏覽(2859)

272020-4

焦點配色法

資深UI設(shè)計者

今天跟大家聊聊設(shè)計中焦點配色這個話題。焦點這個詞對于設(shè)計師來說應(yīng)該不會感到陌生，但是這節(jié)課我們主要是從色彩的角度，來看看焦點在設(shè)計中的作用以及色彩焦點的重要性。首先我們要知道設(shè)計的目的就是通過視覺來傳達信息，而視覺的表現(xiàn)形式是有一定規(guī)律性的，在這些眾多的規(guī)律性當中，其中有一條就是通過色彩來實現(xiàn)，而焦點配色就是色彩設(shè)計中最有效的一個手段。

其實無論是繪畫、攝影還是我們的設(shè)計，都存在大量的焦點配色，只是我們平時沒有特別去注意而已。比如莫奈的這幅《日出·印象》，我們來嘗試分析一下焦點的設(shè)置和移動。

我想絕大多數(shù)人都應(yīng)該是這種移動路線，也就是在大面積灰色調(diào)和冷色調(diào)中先被強暖色的太陽所吸引，然后是近景全黑色的船，接著順延到另一條船上，當然每個人都會有所不同。

比如也可能是這種從遠景到近景的順序。

也可能有的人是從近到遠的觀看順序，但是無論你是哪一種，都不重要，為什么？

因為無論你的視線是怎么移動的，都不會影響到我們最終焦點的歸屬。大家可以感受一下，當你看這幅畫的時候，無論你先看哪后看哪，最終你的眼睛都會被這個橙紅色的太陽所吸引，這就是色彩焦點的魅力。

我們再來看一個攝影作品，這個跟剛才那幅畫來比，焦點就更加清晰了，而且這里也不需要焦點的移動，很明顯焦點就是這個人物。

但是這個焦點是怎么通過色彩得到強化的呢？可能有的人會說這么明顯的人物肯定是焦點啊，但是你可以嘗試把人物后面的暖色光去掉看看，雖然人物同樣是這個畫面的焦點，但是一定沒有現(xiàn)在這樣搶眼，因為暖色和背景的冷色形成了強烈的對比。

所以無論是繪畫、攝影還是我們接下來會看到的設(shè)計，其中都會包含一種故意的或者是有意識的色彩焦點的安排，而這種焦點的形成是怎么實現(xiàn)的呢？其實就是通過色彩對比，因為有色彩對比必定產(chǎn)生焦點，即使沒有焦點我們也會努力去尋找焦點。我們聯(lián)想下平時的生活就會發(fā)現(xiàn)，無論是我們看到一幅畫面，或者是置身于一個真實的環(huán)境中，我們都會不自覺地去尋找色彩最突出或者最醒目的東西，這就是作為人的一種本能，也就是自然而然地去尋找焦點。

下面我們來看一些設(shè)計作品，我們看這三個界面，不能說沒有焦點，有，就是圖片，準確地說應(yīng)該是沒有色彩焦點，所以我們接收到的就是圖片加上信息排在一起，我們很難在短時間內(nèi)區(qū)分出哪些是重要信息哪些是次要信息。我們不知道視線應(yīng)該落在哪里，因為沒有突出的東西，這種不知所措會讓看的人感到不舒服，這就是沒有焦點會造成的一種情況。

同樣這三個界面，我們什么都不變，只是在想強調(diào)的部分填充一個顏色，這樣就會讓看的人可以通過色彩毫不猶豫地感受到焦點，這種交互才是人性化的交互，而這個簡單的過程其實就是色彩設(shè)計。

我們再來看一個更加簡單易懂的，比如現(xiàn)在這個，就是在一個藍色背景上編排純白的文字，可能通過字號和距離的安排我們也知道孰輕孰重，但是如果從色彩的角度來看還不夠，因為沒有形成讓人快速識別的焦點。

如果在想強調(diào)的地方，適當?shù)奶畛湟粋€顏色，那么瞬間就有了焦點，而這個顏色和背景色的對比越強，焦點就越明顯。

我們看這個海報，當我們看到這個畫面的時候首先注意到的是什么？

首先注意的肯定是上方的圖片，其次會根據(jù)信息的層級大小去看主標題，然后是次要信息。這種沒有設(shè)置色彩焦點的形式，雖然不太會影響信息的閱讀，但我們不妨試試有色彩焦點的情況。

當原本就是畫面中比較重要的標題信息和突出的英文被填充紅色之后，焦點就產(chǎn)生了并且得到強化。

這時候當我們再看這個作品，就可以在短時間內(nèi)迅速獲得信息，如果想繼續(xù)了解也可以繼續(xù)閱讀，這就是有焦點和沒焦點或者焦點不突出的差別。

我們看這個 banner，這里我們不說它的版式怎么樣，我們就看色彩和焦點，這個畫面有什么問題呢？就是焦點設(shè)置錯誤，什么意思？

也就是大家看這個畫面的時候，雖然都會先看月餅的圖片，然后是標題到進入專場，但是大家發(fā)現(xiàn)沒有，你的視線總會被中間這個粉色的花瓣吸引。

就是那種你不想看它，但是又不得不看的感覺，因為這個花瓣的顏色完全沒必要出現(xiàn)在這里，因為它不是信息，為什么要充當焦點呢？這就是焦點錯誤。

我們把花瓣去掉試試，這樣焦點就很清晰明確了。

現(xiàn)在我們知道了有焦點和沒焦點的差別，那焦點的設(shè)置其實也是有多種情況的。我們就拿這個網(wǎng)頁來舉例，版式部分保持不變，你想突出哪里就在哪里設(shè)置焦點。我們來看看通過色彩把焦點安排在不同的地方，這個頁面產(chǎn)生什么樣的效果。

比如我們可以把焦點設(shè)置在上半部分，也就是頂部的品牌和導(dǎo)航區(qū)域。

也可以把焦點設(shè)置在主標題的文字信息上。

還可以設(shè)置在底部區(qū)域，形成色塊。

當然也可以是自由式的焦點設(shè)置，強調(diào)你想強調(diào)的部分，這種情況下就有了焦點的移動。

通過之前的案例分析我們總結(jié)一下有焦點的好處：首先它滿足了人的生理需求，其次滿足了視覺傳達的需求，最后滿足了審美的需求。也就是說我們所要做的視覺設(shè)計是需要傳達信息的，你得讓受眾看到你的信息才行，而要想有效的讓人看到信息，焦點的設(shè)置就要滿足前面三個需求，如果沒有滿足，一定程度上說明你的作品是失敗的。實際人都是充滿惰性的，也都不喜歡延遲，當人們看到所有的信息在它應(yīng)該在的位置，不需要眼睛和大腦再去閱讀，這時候就得到了一種觀看和閱讀的滿足感。

說了這么多焦點的好處，下面我們就來看看如何通過配色形成或者強化焦點。首先我們要知道的就是焦點是通過對比實現(xiàn)的，而這里包括了色相對比形成焦點、冷暖對比形成焦點、深淺對比形成焦點、有彩色與無彩色對比形成焦點、花色與純色對比形成焦點、色彩面積對比形成焦點。

首先我們來看色相對比形成焦點，這里的色相對比通常是指互補色或?qū)Ρ壬g的對比，因為色相差異越大越容易產(chǎn)生焦點。比如這個海報就是藍色和黃色的互補色對比，當然需要注意的是，我們所列舉出的這些對比并不是單獨存在的，它們往往都是相互結(jié)合的，比如這個海報最明顯的就是色相上的互補色對比，當然你也可以說是冷暖對比，同時也包括面積對比。

這個網(wǎng)頁作品，藍色與綠色形成了色相上的對比，同時它們二者又與背景形成了有彩色與無彩色的對比。

這個圣誕主題的 banner，整體是大面積的暗紅色，這就讓人物頭頂?shù)木G色圣誕樹成為了焦點，也就是色相對比中通過對比色形成焦點。

然后是冷暖色對比產(chǎn)生焦點，這個版面很簡單，就是文字編排加上背景，但是很明顯，通過在強調(diào)的地方使用藍色與背景的粉紅色形成一種冷暖對比，讓焦點一目了然。

這個同樣也是紅色與藍色的冷暖對比強調(diào)焦點，讓人一眼就能抓住重點。

這個同樣也是通過冷暖對比形成焦點，只不過這個畫面并不是單一焦點的形式，是多個焦點從大到小或從近到遠的移動。

如果色相對比不夠明顯，那么通過單一色彩或近似色彩的深淺對比也可以很好的形成焦點，同樣純度和明度差異越大越容易產(chǎn)生焦點。比如這個畫面中的焦點面包與背景形成的就是深淺對比。

這個畫面整體是褐色的基調(diào)，但是杯子中的茶湯是比背景更亮一些的顏色，所以它自然而然地就成為了畫面的焦點，而且這個焦點也是符合這個版面的設(shè)計邏輯的。

這個頁面的背景是偏深一些的粉紅色，當然圖片肯定是這個畫面的第一焦點，但除此之外，這個畫面中還有另外兩個焦點，就是比背景偏暗一些的嘴唇，這就是利用深淺色對比形成焦點。

焦點的作用以及如何強調(diào)焦點都很好理解和操作，但是設(shè)置焦點背后的原理是什么呢？就是我們之前講過的色彩營銷，因為設(shè)計的目的是通過視覺傳達信息，而傳遞信息的目的是為了營銷，所以答案也就很明了了。也就是如何設(shè)置焦點以及讓誰成為焦點，這背后的邏輯要依據(jù)營銷的目的，換句話說焦點的設(shè)置一定要滿足以上的需求，假如設(shè)置了錯誤的焦點，就會適得其反，倒不如不設(shè)置焦點了，這個道理大家一定要明白。

我們接著往下看，下一個就是有彩色與無彩色對比產(chǎn)生焦點。比如我們看上面這個海報，圖片整體是黑白的，只有雨傘的部分是紅色，非常醒目的被凸顯出來，當然就是第一焦點，其次就是紅色的標題性文字。因為黑色與紅色很好的對比效果，所以類似這種形式的攝影作品大家也一定見過很多，就是整體是黑白，個別地方用紅色的形式。

雖然這個網(wǎng)頁頁面上的有彩色并不是單一色彩，但是與背景黑色的搭配，整體上依然是有彩色與無彩色搭配所產(chǎn)生的對比，從而產(chǎn)生焦點。

這個雖然也是有彩色與無彩色的對比，但是這個很巧妙，因為設(shè)計者并沒有直接在主標題上填充有彩色，而是在標題下方使用了一個有彩色的色塊，這也是一種變相突顯焦點的方式。

接下來是花色與純色對比產(chǎn)生焦點，這個算是很常見很通用的一種形式了，尤其是照片上編排文字的形式，如果圖片本身的色彩就比較豐富，那么文字色必然要使用單一的色彩才能保證很好的識別。

這個雜志封面的背景是由多種色彩所形成的插畫圖形，而人物一身黑色位于中間形成了第一焦點，其次是位于人物上的綠色文字，可以說既是有彩色與無彩色的對比，又是有彩色與花色之間的對比。

這個海報上的圖片雖然色彩并沒有多純，但是由于色彩比較分散，所以可想而知，在它上方編排文字難免會造成識別度很低的情況，所以設(shè)計師也很巧妙地使用了添加色塊的方式，利用這種圖片花色與色塊純色的對比來突出焦點。

最后就是通過色彩面積大小產(chǎn)生焦點，這種面積的對比可以說是非常常見的，可以說大部分有色彩焦點的畫面都是之前的那幾種形式與面積對比的一個結(jié)合，但是并沒有誰重要誰不重要一說，就比如這個海報上的紅色圓形，無論你是把它的面積放大，還是把它換成和藍色相近的顏色，焦點的效果都沒有現(xiàn)在的好。所以我們在具體設(shè)計配色的時候千萬不要有強迫癥，因為這些方法往往都是結(jié)合使用的。

這個也是面積對比產(chǎn)生的焦點，同時又有藍色與紅色的冷暖對比。

這個頁面也是，通過在大面積綠色調(diào)中使用一個紅色塊，快速形成對比，從而確定焦點。

以上我們主要講解了通過配色形成焦點的一些方法，但其實細心的同學(xué)就會發(fā)現(xiàn)，這里面還是有一些潛規(guī)則的，有的是和色彩有關(guān)，有的可能和色彩無關(guān)。比如說同樣的色彩或同樣大小的對象，具象的東西比抽象的東西容易形成焦點、人物比場景或風(fēng)景容易形成焦點、圖像比文字容易形成焦點、標題文字比內(nèi)文容易形成焦點、暖色比冷色容易形成焦點、強對比比弱對比容易形成焦點，最后我們就分別來看一下。

具象的事物比抽象的事物容易形成焦點，這個似乎沒什么可說的，大家應(yīng)該都能明顯的感覺到，就比如這個海報，即使人臉的周圍有著密密麻麻的抽象圖像，我們的注意力依然在人臉的部分。

人物要比場景更容易產(chǎn)生焦點，比如這個海報，同時存在兩張圖片，雖然上方的圖片是一匹馬不是人，但是道理是一樣的，我們的視線總是想關(guān)注這個馬的眼睛，而下方的海水我們可能只是一掃而過。

圖片比文字更容易形成焦點，這個也是無需多說的一點，因為即使都是黑白的圖片和文字，我們也會首先注意到圖片，這是圖片所具有的天然魅力。比如這個海報，假如我們把圖片遮掉，那么紅色的「魂」字毋庸置疑就是第一焦點，因為在一堆黑色文字中它實在太顯眼了，但是加上人物圖片的話，就沒有多少人會去關(guān)注「魂」字了。

標題比內(nèi)文更容易產(chǎn)生焦點，這是因為標題所具有的天然優(yōu)勢，也就是面積優(yōu)勢，比如我們看這個海報，其實它這里的標題使用與圖片一樣的藍色并不是很突出，雖然日期和副標題使用了色相對比，也確實成為了焦點，但是對于主標題的影響并不是很大，我們依然不會忽略掉主標題，這就是面積原因所造成的，因為它足夠大。

暖色比冷色更容易形成焦點，這個海報就是一個很好的說明，因為海報中兩個圖片大小相當，唯一的區(qū)別就是一個是暖色一個是冷色，那么哪個更吸引你呢？一定是暖色，如果你說你就是被冷色所吸引那也沒關(guān)系，但是你自己保留意見，我不接受反駁。

最后就是強對比大于弱對比，比如我們看這個海報，其實本身背景色上有色相的對比，但是因為對比不夠強，所以就讓上方的紅色成為了焦點，因為紅色與整體背景形成了強烈的深淺對比。

簡單總結(jié)一下，首先我們通過一些案例說明了色彩焦點的重要性，也就是滿足了人的三種需求：生理需求、視覺傳達的需求以及審美的需求。其次我們講解了如何形成或強調(diào)焦點，也就是通過一些色彩對比來實現(xiàn)。最后補充了一些焦點配色中存在的潛規(guī)則，也就是哪些內(nèi)容或形式具有形成焦點的天然優(yōu)勢。當然這一切的落腳點還要歸到視覺傳達以及色彩營銷上。

文章來源：優(yōu)設(shè) 作者：研習(xí)設(shè)

評論(0) 瀏覽(2830)

272020-4

從免費圖庫、影片到字體，這個網(wǎng)站全包了！

資深UI設(shè)計者

距離上一次介紹 The Stocks 已經(jīng)超過五年，前段時間無意間瀏覽到這個網(wǎng)站，才想起我以前好像也寫過文章，不過網(wǎng)站現(xiàn)在變得不太一樣而且內(nèi)容又更完整了，非常推薦加入收藏，因為真的很方便。如果你還不知道 The Stocks，它整合各種設(shè)計相關(guān)免費資源，最早只有將一些免費圖庫整合在一起，讓找圖的使用者透過側(cè)邊欄選單快速切換各個不同圖庫網(wǎng)站，加速搜尋圖庫的效率。

在全新的 The Stocks 2 除了免費圖庫，加入配色工具、免費圖標、免費影片、免費字體和 Mockups 素材網(wǎng)站共六種項目，相較于早期來說在資源數(shù)量上增加不少，現(xiàn)在一樣可以從網(wǎng)站側(cè)邊選單選取你要瀏覽的素材類型，The Stocks 就會出現(xiàn)一整排的網(wǎng)站列表讓使用者直接選擇，再從這些網(wǎng)站去尋找你要的免費資源。

對于平常會需要搜尋設(shè)計相關(guān)資源的使用者來說，The Stocks 是很好用的工具。

不過 The Stocks 現(xiàn)在會加入一些贊助商「推薦」內(nèi)容，如果使用者進入這些服務(wù)，也有付費購買的話 The Stocks 開發(fā)者就能獲得回饋（其實就是 Affiliate），網(wǎng)站主要還是以收錄免費服務(wù)為主。

The Stocks 2

網(wǎng)站鏈接：http://thestocks.im/

使用教學(xué)

開啟 The Stocks 網(wǎng)站后會隨機顯示一個免費圖庫，The Stocks 主要功能列在左側(cè)，點選選單上的網(wǎng)站名稱會將網(wǎng)頁顯示于右側(cè)，方便在各個外部網(wǎng)站跳轉(zhuǎn)和搜尋，不過有些網(wǎng)站不允許被嵌入其他頁面，這時候就會以開新分頁方式替代。

左上角是 The Stocks 收錄的免費資源類型，包括免費圖庫、配色工具、免費圖標、免費影片、免費字體和 Mockups 素材網(wǎng)站，點選后下方的網(wǎng)站列表就會實時更新。

有些標示為 Featured 就是本文前面提到的贊助商推薦內(nèi)容，大多都是付費服務(wù)，例如銷售相片圖片的 Shutterstock、iStock 圖庫，如果有在找圖的朋友應(yīng)該不陌生，其實很多免費圖庫也是透過刊登付費圖庫廣告來獲取收益。

當然 The Stocks 收錄的網(wǎng)站仍以免費資源居多，點選后就能快速瀏覽網(wǎng)站，如果操作上發(fā)現(xiàn)有些問題或無法正確顯示，亦可搜尋該網(wǎng)站名稱直接在瀏覽器開啟。

最近因為疫情關(guān)系，很多公司改為在家上班，如果要開會就會透過一些視頻會議軟件例如 Zoom ，The Stocks 也有提供 Zoom 適用的免費虛擬背景（特別是家里背景很雜亂的朋友可以稍微隱藏一下），這些素材可以在網(wǎng)站右上角 Zoom Virtual Backgrounds 找到。

值得一試的三個理由：

整合免費圖庫、配色工具、免費圖標、免費影片、免費字體等相關(guān)網(wǎng)站
點選網(wǎng)站鏈接即可在同一頁面快速切換瀏覽

對于要搜尋素材來說很方便很有用

文章來源：優(yōu)設(shè) 作者：Pseric

評論(0) 瀏覽(2586)

242020-4

前端架構(gòu)演進及主流UI

前端達人

總結(jié)

前端三要素

JavaScript 框架

NodeJs

常用UI框架

前后端分離的演進

為了降低開發(fā)的復(fù)雜度，以后端為出發(fā)點，比如:Struts、SpringMVC 等框架的使用，就是后端的 MVC 時代;

以 SpringMVC 流程為例:

優(yōu)點:

前后端職責(zé)很清晰: 前端工作在瀏覽器端，后端工作在服務(wù)端。清晰的分工，可以讓開發(fā)并行，測試數(shù)據(jù)的模擬不難，前端可以本地開發(fā)。后端則可以專注于業(yè)務(wù)邏輯的處理，輸出 RESTful等接口。
前端開發(fā)的復(fù)雜度可控: 前端代碼很重，但合理的分層，讓前端代碼能各司其職。這一塊蠻有意思的，簡單如模板特性的選擇，就有很多很多講究。并非越強大越好，限制什么，留下哪些自由，代碼應(yīng)該如何組織，所有這一切設(shè)計，得花一本書的厚度去說明。
-部署相對獨立: 可以快速改進產(chǎn)品體驗
缺點:

代碼不能復(fù)用。比如后端依舊需要對數(shù)據(jù)做各種校驗，校驗邏輯無法復(fù)用瀏覽器端的代碼。如果可以復(fù)用，那么后端的數(shù)據(jù)校驗可以相對簡單化。
全異步，對 SEO 不利。往往還需要服務(wù)端做同步渲染的降級方案。性能并非最佳，特別是移動互聯(lián)網(wǎng)環(huán)境下。
SPA 不能滿足所有需求，依舊存在大量多頁面應(yīng)用。URL Design 需要后端配合，前端無法完全掌控。
NodeJS 帶來的全棧時代

前端為主的 MV* 模式解決了很多很多問題，但如上所述，依舊存在不少不足之處。隨著 NodeJS 的興起，JavaScript 開始有能力運行在服務(wù)端。這意味著可以有一種新的研發(fā)模式:
————————————————
版權(quán)聲明：本文為CSDN博主「叁有三分之一」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/iME_cho/article/details/105654633

評論(0) 瀏覽(2442)

242020-4

【CSS基礎(chǔ)學(xué)習(xí)】行內(nèi)元素，塊級元素，行內(nèi)塊級元素

前端達人

文章目錄

元素的顯示方式和轉(zhuǎn)換

塊級元素
行級元素
行內(nèi)塊級元素

顯示方式之間的轉(zhuǎn)化

元素的顯示方式和轉(zhuǎn)換

塊級元素

塊級元素（inline）：
塊級元素可以包含行內(nèi)元素和其它塊級元素，且占據(jù)父元素的整個空間，可以設(shè)置 width 和 height 屬性，瀏覽器通常會在塊級元素前后另起一個新行。
常見塊級元素：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        div{
            width: 150px;
            height: 150px;
            background-color: cadetblue;
        }
    </style>
</head>
<body>
    <div>塊級元素1</div>
    <div>塊級元素2</div>
</body>
</html>

分析：
塊級元素的高和寬可以被修改，而且塊級元素會在一個塊級元素之后另起一行。

行級元素
行級元素（block）：
一般情況下，行內(nèi)元素只能包含內(nèi)容或者其它行內(nèi)元素，寬度和長度依據(jù)內(nèi)容而定，不可以設(shè)置，可以和其它元素和平共處于一行。
常見行級元素：
a,b,strong,span,img,label,button,input,select,textarea
特點：

和相鄰的行內(nèi)元素在一行上
高度和寬度無效，但是水平方向上的padding和margin可以設(shè)置，垂直方向上的無效
默認的寬度就是它本身的寬度
行內(nèi)元素只能容納純文本或者是其他的行內(nèi)元素（a標簽除外）
例如：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        span{
            width: 150px;
            height: 150px;
            font-size: 40px;
            background-color: cadetblue;
        }
    </style>
</head>
<body>
    <span>行級元素1</span>
    <span>行級元素2</span>
</body>
</html>

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        span{
            width: 150px;
            height: 150px;
            font-size: 20px;
            background-color: cadetblue;
            display: inline-block;
        }
    </style>
</head>
<body>
    <span>以前我是行級元素，</span>
    <span>現(xiàn)在我只想做行內(nèi)塊級元素。</span>
</body>
</html>

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        div{
            width: 150px;
            height: 150px;
            font-size: 30px;
            background-color: cadetblue;
            display: inline;
        }
    </style>
</head>
<body>
    <div>我以前是塊級元素，</div>
    <div>現(xiàn)在我是行級元素！</div>
</body>
</html>

分析：
在VSC中，修改寬高的代碼已經(jīng)出現(xiàn)了波浪線，證明他是錯誤的，所以現(xiàn)在的div已經(jīng)變成了行級元素。

————————————————
版權(quán)聲明：本文為CSDN博主「董小宇」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lolly1023/article/details/105715892

評論(0) 瀏覽(2357)

242020-4

帶你快速了解VSCode的10個特性，極大提高開發(fā)效率

前端達人

其實VSCode編輯器本身自帶了一個功能（Interactive Editor Playground ：可以讓你快速了解VSCode的特性，并且是可以交互的），

但很可惜它的內(nèi)容是全英文的（將VSCode設(shè)置為中文也沒用哦~），

我將每一部分截圖下來，并為你說明關(guān)鍵內(nèi)容，教你學(xué)會使用 Interactive Editor Playground

還有一些顯而易見的特性，我不會再用文字敘述一遍（它們都是潛移默化的）

在下文中會涉及到大量快捷鍵的介紹，如果看不懂快捷鍵請自行百度

鼠標 = 文本光標 = 光標

本文成于2020年4月22日，隨著VSCode的版本更迭，此部分內(nèi)容可能會略有差異（小更改不影響觀看，有較大影響的更新請在評論區(qū)告之，我會及時更新的）

打開VSCode > Help > Interactive Playground

你將會打開 Interactive Editor Playground 頁面

互動式編輯游樂場

VS代碼中的核心編輯器包含許多特性。此頁高亮顯示了10個特性，每個特性介紹中都提供了代碼行供你編輯

接下來的10行內(nèi)容（你可以理解為目錄，對應(yīng)10個特性）

多光標編輯（Multi-Cursor Editing）- 選擇一塊區(qū)域，選擇所有匹配項，添加其余光標等
智能感應(yīng)（intelliSense）- 獲取代碼和外部模塊的代碼幫助和參數(shù)建議
行操作（Line Actions ）- 快速移動行以重新排序代碼
重命名重構(gòu)（Rename Refactoring）- 快速重命名代碼庫中的符號（比如變量名、函數(shù)名）
格式化（Formatting）- 使用內(nèi)置文檔和選擇格式使代碼看起來很棒
代碼折疊（Code Folding） - 通過折疊其他代碼區(qū)域，關(guān)注代碼中最相關(guān)的部分
錯誤和警告（Errors and Warnings）- 寫代碼時請參閱錯誤和警告
片段（Snippets）- 花更少的時間輸入片段
Emmet - 只需要敲一行代碼就能生成你想要的完整HTML結(jié)構(gòu)等（極大方便前端開發(fā)）
JavaScript Type Checking- 使用零配置的TypeScript對JavaScript文件執(zhí)行類型檢查。
Multi-Cursor Editing

使用多光標編輯可以同時編輯文檔的多個部分，極大地提高了工作效率

框式選擇
鍵盤同時按下 Shift + DownArrow（下鍵）、Shift + RightArrow（右鍵）、Shift + UpArrow（上鍵）、Shift + LeftArrow（左鍵）的任意組合可選擇文本塊
也可以用鼠標選擇文本時按 Shift + Alt 鍵
或使用鼠標中鍵拖動選擇（可用性很高）
添加光標
按 Ctrl + Alt + UpArrow 在行上方添加新光標
或按 Ctrl + Alt + DownArrow 在行下方添加新光標
您也可以使用鼠標和 Alt + Click 在任何地方添加光標（可用性很高）
在所有出現(xiàn)的字符串上創(chuàng)建光標
選擇字符串的一個實例，例如我用鼠標選中所有background，然后按 Ctrl + Shift + L，文本中所有的background都將被選中（可用性很高）
IntelliSense

Visual Studio Code 預(yù)裝了強大的JavaScript和TypeScript智能感知。

在代碼示例中，將文本光標放在錯誤下劃線的上面，會自動調(diào)用IntelliSense

這只是智能提示的冰山一角，還有懸停在函數(shù)名上可以看到參數(shù)及其注釋（如果有）等等，它會潛移默化的帶給你極大幫助

其他語言在安裝對應(yīng)插件后，會附帶對應(yīng)語言的IntelliSense

Line Actions

分別使用 Shift + Alt + DownArrow 或 Shift + Alt + UpArrow 復(fù)制光標所在行并將其插入當前光標位置的上方或下方
分別使用 Alt + UpArrow 和 Alt + DownArrow 向上或向下移動選定行（可用性很高）
用 Ctrl + Shift + K 刪除整行（可用性很高）
通過按 Ctrl + / 來注釋掉光標所在行、切換注釋（可用性很高）
Rename Refactoring

重命名符號（如函數(shù)名或變量名）

將光標選中符號，按F2鍵
或者選中該符號，鼠標右鍵 > Rename Symbol

重命名操作將在項目中的所有文件中發(fā)生（可用性很高）

Formatting

代碼如果沒有良好的編寫格式，閱讀起來是一個折磨

Formatting可以解決編寫格式問題：無論你的代碼的格式寫的有多么糟糕，它可以將代碼格式化為閱讀性良好的格式

格式化整個文檔 Shift + Alt + F （可用性很高）
格式化當前行 Ctrl + K Ctrl + F（即先按Ctrl，再按K，最后按F）
鼠標右鍵 > Format Document （格式化整個文檔）
將格式化操作設(shè)置為自動化（保存時自動格式化整個文檔）：Ctrl + , 輸入 editor.formatOnSave

Code Folding

鼠標操作，自己嘗試一下，秒懂

快捷鍵：

折疊 Ctrl + Shift + [
展開 Ctrl + Shift + ]

折疊代碼段是基于基于縮進

Errors and Warning

錯誤和警告將在你出現(xiàn)錯誤時，高亮該代碼行

在代碼示例中可以看到許多語法錯誤（如果沒有，請你隨便修改它，讓它出現(xiàn)錯誤）

按F8鍵可以按順序在錯誤之間導(dǎo)航，并查看詳細的錯誤消息（可用性很高）

Snippets

通過使用代碼片段，可以大大加快編輯速度

在代碼編輯區(qū)，你可以嘗試輸入try并從建議列表中選擇try catch，

然后按Tab鍵或者Enter，創(chuàng)建try->catch塊

你的光標將放在文本error上，以便編輯。如果存在多個參數(shù)，請按Tab鍵跳轉(zhuǎn)到該參數(shù)。

Emmet

Emmet將代碼片段的概念提升到了一個全新的層次（前端開發(fā)的大寶貝）

你可以鍵入類似Css的可動態(tài)解析表達式，并根據(jù)在abrevision中鍵入的內(nèi)容生成輸出

比如說：

然后Enter

JavaScript Type Checking

————————————————
版權(quán)聲明：本文為CSDN博主「索兒呀」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/Zhangguohao666/article/details/105676173

評論(0) 瀏覽(2763)

242020-4