回顧：上一次已經把消息的布局以及樣式做好了

效果圖：

 

 在removeList.js文件中，messageId就是發起這個消息的用戶了

先查看一下自定義組件的生命周期

https://developers.weixin.qq.com/miniprogram/dev/framework/custom-component/lifetimes.html

 lifetimes: {
    attached: function() {
      // 在組件實例進入頁面節點樹時執行
    },
    detached: function() {
      // 在組件實例被從頁面節點樹移除時執行
    },
  }

直接就是在lifttimes裏面進行定義的（直接就是在methods的同級的下面加上即可了）

因為要對用戶的信息進行渲染，就可以看成是一個一個的對象，所以就可以在removeLIst.js中定義一個對象

然後遇到的問題就和之前是一樣的了，就是我們得到的數據太多了，沒必要全部都要，可以選擇性的要，只需要頭像和昵稱

（所以就可以在get前面來一個field）

lifetimes: {
    attached: function () {
      // 一進來就會進行它了
      db.collection('users').doc(this.data.messageId)
      .field({
        userPhoto : true,
        nickName : true
      })
      .get().then((res)=>{
        this.setData({
            userMessage　: res.data
        });
      });
    }
  }

這樣的話我們在這個頁面裏面就可以得到用戶的數據了，剩下的就是直接可以在wxml中用了

<!--components/removeList/removeList.wxml-->
<movable-area class="area">
     <movable-view direction="horizontal" class="view">{{ userMessage.nickName }}</movable-view>
     <image src="{{ userMessage.userPhoto }}" />
     <view class="delete">刪除</view>
 </movable-area>

效果圖：

 

 在之後設置刪除功能之前，先設置一下就是只要點擊了消息列表中用戶的頭像之後，就可以跳轉到這個用戶的詳情頁了

可以直接 在編輯個人信息的頁面 editUserInfo.wxml中COPY代碼　　

在設置這個跳轉頁面的url的時候，因為同時要給這個url傳遞參數的，所以這個時候就要用大括號括起來了

<!--components/removeList/removeList.wxml-->
<movable-area class="area">
     <movable-view direction="horizontal" class="view">{{ userMessage.nickName }}</movable-view>
     <navigator url="{{'/pages/detail/detail?userId=' + userMessage._id}}" open-type="navigate">
     <image src="{{ userMessage.userPhoto }}" />
     </navigator>
     <view class="delete">刪除</view>
 </movable-area>

即可實現，點擊頭像跳轉到個人的詳情頁面

 

二、下面就是對刪除功能進行設計

一開始的就是，點擊了之後，要給用戶一個提示信息，讓用戶可以選擇是取消還是確定的，這裏用的是一個wx.showModel這樣一個內置的方法

 

所以就要另外的給“點擊了確定”加邏輯了，就要在微信開放文檔裏面細看這個API了

https://developers.weixin.qq.com/miniprogram/dev/api/ui/interaction/wx.showModal.html

wx.showModal({
  title: '提示',
  content: '這是一個模態彈窗',
  success (res) {
    if (res.confirm) {
      console.log('用戶點擊確定')
    } else if (res.cancel) {
      console.log('用戶點擊取消')
    }
  }
})

把查到的賦值給list，然後在用數組的filter進行刪除即可了

通過fileter過濾之後，就是過濾初和我們不想要的東西，然後把這些東西再次賦值為list，然後我們把前後的list打印出來會發現：

 

 確實是過濾掉了的

 由於如果要刪掉的話，就設計了removeList這個組件和message這各頁面之間的通信了，並且是子組件像父組件，用到事件來做的

https://developers.weixin.qq.com/miniprogram/dev/framework/custom-component/events.html

<!-- 當自定義組件觸發“myevent”事件時，調用“onMyEvent”方法 -->
<component-tag-name bindmyevent="onMyEvent" />
<!-- 或者可以寫成 -->
<component-tag-name bind:myevent="onMyEvent" />

所以在message.wxml中隊子組件remove-list設置

<remove-list wx:for="{{ userMessage }}" wx:key="{{index}}" messageId="{{ item }}"
     bindmyevent="onMyEvent"/> 
    

這樣事件監聽就寫好了，但是如何在組件中觸發呢，我們回到removelist.js中

繼續查看山脈的鏈接-微信開發文檔

Component({
  properties: {},
  methods: {
    onTap: function(){
      var myEventDetail = {} // detail對象，提供給事件監聽函數
      var myEventOption = {} // 觸發事件的選項
      this.triggerEvent('myevent', myEventDetail, myEventOption)
    }
  }
})

在removelist.js中通過：

 this.triggerEvent('myevent',list) 

前面參數，要和在 message.wxml設置的 bindmyevent，後面的myevent對應上

第二個參數就是我們 過濾剩下的list

給message傳過去之後

  onMyEvent(ev){
  this.setData({
    userMessage : ev.detail
  });

通過這樣的設置出現了一個bug，就是我們刪除第一條信息的時候，直接把第二條刪掉了，第一條被留下來了

當我們查看數據庫的時候，留下來的就是第二條信息，但是在前端显示的是第一條信息留下，第二條信息沒了

要這樣修改：

onMyEvent(ev){
    this.setData({
      userMessage : []
    },()=>{
        this.setData({
          userMessage : ev.detail
        });
    });
  }
  

先賦值為空，之後再次調用removelist，再把過濾的數組進行賦值　　

 

 

 也就是全部清空之後，再重新渲染的

 

 整個邏輯：

1、在數據庫中用戶的頭像和昵稱找到，然後獲取數據

 

2、點擊刪除按鈕的時候，彈出提示框，如果用戶點了缺點刪除的話，之後我們先查詢

 找到之後，把那個消息在message列表中過濾掉

 

 3、然後再重新的更新，之後就觸發子父通信，把更新之後的list傳給

 

4、父組件拿到removelist這組件的信息

 

 拿到就更新我們的列表，這樣的話列表就發送了變化了

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

本文來自作者投稿，原作者：上帝愛吃蘋果

目前在魔都，貝殼找房是我的僱主，平時關注一些 java 領域相關的技術，希望你們能在這篇文章中找到些有用的東西。個人水平有限，如果文章有錯誤還請指出，在留言區一起交流。

我想大家肯定都或多或少的看過各種“策略模式”的講解、佈道等等，這篇文章就是來好好“澄清”一下策略模式，並嘗試回答以下的問題：

1. 策略模式是如何優化業務邏輯代碼結構的？

2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！

3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？

策略模式是如何優化業務邏輯代碼結構的？

要回答這個問題，我們還得先扒一扒策略模式的定義，從定義着手來理解它

策略模式的教科書定義

它的定義很精簡：一個類的行為或其算法可以在運行時更改。我們把它降維到代碼層面，用人話翻譯一下就是，運行時我給你這個類的方法傳不同的“key”，你這個方法會執行不同的業務邏輯。細品一下，這不就是 if else 乾的事嗎？

策略模式優化了什麼？

其實策略模式的核心思想和 if else如出一轍，根據不同的key動態的找到不同的業務邏輯，那它就只是如此嗎？

實際上，我們口中的策略模式其實就是在代碼結構上調整，用接口+實現類+分派邏輯來使代碼結構可維護性好點。

一般教科書上講解到接口與實現類就結束了，其他博客上會帶上提及分派邏輯。這裏就不啰嗦了。

小結一下，即使用了策略模式，你該寫的業務邏輯照常寫，到邏輯分派的時候，還是變相的if else。而它的優化點是抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。

殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！

我想小夥伴們經常有這樣的不滿，我的業務邏輯就3 4 行，你給我整一大堆類定義？有必要這麼麻煩嗎？我看具體的業務邏輯還需要去不同的類中，簡單點行不行。

其實我們所不滿的就是策略模式帶來的缺點：

1、策略類會增多

2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯視整個業務邏輯

針對傳統策略模式的缺點，在這分享一個實現思路，這個思路已經幫我們團隊解決了多個複雜if else的業務場景，理解上比較容易，代碼上需要用到Java8的特性——利用Map與函數式接口來實現。

直接show代碼結構：為了簡單演示一個思路，代碼用String 類型來模擬一個業務BO

其中：

1. getCheckResult() 為傳統的做法

2. getCheckResultSuper()則事先在Map中定義好了“判斷條件”與“業務邏輯”的映射關係,具體講解請看代碼註釋

/**
 * 某個業務服務類
 */
@Service
public class BizService {

    /**
     * 傳統的 if else 解決方法
     * 當每個業務邏輯有 3 4 行時，用傳統的策略模式不值得，直接的if else又顯得不易讀
     */
    public String getCheckResult(String order) {
        if ("校驗1".equals(order)) {
            return "執行業務邏輯1";
        } else if ("校驗2".equals(order)) {
            return "執行業務邏輯2";
        }else if ("校驗3".equals(order)) {
            return "執行業務邏輯3";
        }else if ("校驗4".equals(order)) {
            return "執行業務邏輯4";
        }else if ("校驗5".equals(order)) {
            return "執行業務邏輯5";
        }else if ("校驗6".equals(order)) {
            return "執行業務邏輯6";
        }else if ("校驗7".equals(order)) {
            return "執行業務邏輯7";
        }else if ("校驗8".equals(order)) {
            return "執行業務邏輯8";
        }else if ("校驗9".equals(order)) {
            return "執行業務邏輯9";
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 業務邏輯分派Map
     * Function為函數式接口，下面代碼中 Function<String, String> 的含義是接收一個Stirng類型的變量，返回一個String類型的結果
     */
    private Map<String, Function<String, String>> checkResultDispatcher = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherInit() {
        checkResultDispatcher.put("校驗1", order -> String.format("對%s執行業務邏輯1", order));
        checkResultDispatcher.put("校驗2", order -> String.format("對%s執行業務邏輯2", order));
        checkResultDispatcher.put("校驗3", order -> String.format("對%s執行業務邏輯3", order));
        checkResultDispatcher.put("校驗4", order -> String.format("對%s執行業務邏輯4", order));
        checkResultDispatcher.put("校驗5", order -> String.format("對%s執行業務邏輯5", order));
        checkResultDispatcher.put("校驗6", order -> String.format("對%s執行業務邏輯6", order));
        checkResultDispatcher.put("校驗7", order -> String.format("對%s執行業務邏輯7", order));
        checkResultDispatcher.put("校驗8", order -> String.format("對%s執行業務邏輯8", order));
        checkResultDispatcher.put("校驗9", order -> String.format("對%s執行業務邏輯9", order));
    }

    public String getCheckResultSuper(String order) {
        //從邏輯分派Dispatcher中獲得業務邏輯代碼，result變量是一段lambda表達式
        Function<String, String> result = checkResultDispatcher.get(order);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }
}

通過http調用一下看看效果：

/**
 * 模擬一次http調用
 */
@RestController
public class BizController {

    @Autowired
    private BizService bizService;

    @PostMapping("/v1/biz/testSuper")
    public String test2(String order) {
        return bizService.getCheckResultSuper(order);
    }
}

這是個簡單的demo演示，之後會舉一些複雜的場景案例。

魯迅曾說過，“每解決一個問題，就會因出更多的問題”。我們一起來看看這樣的實現有什麼好處，會帶來什麼問題。

好處很直觀：

1. 在一段代碼里直觀的看到”判斷條件”與業務邏輯的映射關係
2. 不需要單獨定義接口與實現類，直接使用現有的函數式接口（什麼？不知道函數式接口？快去了解），而實現類直接就是業務代碼本身。

不好的點：

1. 需要團隊成員對lambda表達式有所了解(什麼？Java14都出來了還有沒用上Java8新特性的小夥伴？)

接下來我舉幾個在業務中經常遇到的if else場景，並用Map+函數式接口的方式來解決它

在真實業務場景問題的解決思路

有的小夥伴會說，我的判斷條件有多個啊，而且很複雜，你之前舉個例子只有單個判斷邏輯，而我有多個判斷邏輯該怎麼辦呢？

很好解決：寫一個判斷邏輯的方法，Map的key由方法計算出

/**
 * 某個業務服務類
 */
@Service
public class BizService {

    private Map<String, Function<String, String>> checkResultDispatcherMuti = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherMuitInit() {
        checkResultDispatcherMuti.put("key_訂單1", order -> String.format("對%s執行業務邏輯1", order));
        checkResultDispatcherMuti.put("key_訂單1_訂單2", order -> String.format("對%s執行業務邏輯2", order));
        checkResultDispatcherMuti.put("key_訂單1_訂單2_訂單3", order -> String.format("對%s執行業務邏輯3", order));
    }

    public String getCheckResultMuti(String order, int level) {
        //寫一段生成key的邏輯：
        String ley = getDispatcherKey(order, level);

        Function<String, String> result = checkResultDispatcherMuti.get(ley);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 判斷條件方法
     */
    private String getDispatcherKey(String order, int level) {
        StringBuilder key = new StringBuilder("key");
        for (int i = 1; i <= level; i++) {
            key.append("_" + order + i);
        }
        return key.toString();
    }
}

用http模擬一下：

/**
 * 模擬一次http調用
 */
@RestController
public class BizController {

    @Autowired
    private BizService bizService;

    @PostMapping("/v1/biz/testMuti")
    public String test1(String order, Integer level) {
        return bizService.getCheckResultMuti(order, level);
    }
}

只要設計好你的key的生成規則就好。

還有小夥伴會問：我的業務邏輯有很多很多行，在checkResultDispatcherMuitInit()方法的Map中直接寫不會很長嗎？

直接寫當然長了，我們可以抽象出一個service服務專門放業務邏輯，然後在定義中調用它就好了：

提供一個業務邏輯單元：

/**
 * 提供業務邏輯單元
 */
@Service
public class BizUnitService {

    public String bizOne(String order) {
        return order + "各種花式操作1";
    }
    public String bizTwo(String order) {
        return order + "各種花式操作2";
    }
    public String bizThree(String order) {
        return order + "各種花式操作3";
    }
}

/**
 * 某個業務服務類
 */
@Service
public class BizService {
    @Autowired
    private BizUnitService bizUnitService;

    private Map<String, Function<String, String>> checkResultDispatcherComX = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherComXInit() {
        checkResultDispatcherComX.put("key_訂單1", order -> bizUnitService.bizOne(order));
        checkResultDispatcherComX.put("key_訂單1_訂單2", order -> bizUnitService.bizTwo(order));
        checkResultDispatcherComX.put("key_訂單1_訂單2_訂單3", order -> bizUnitService.bizThree(order));
    }

    public String getCheckResultComX(String order, int level) {
        //寫一段生成key的邏輯：
        String ley = getDispatcherComXKey(order, level);

        Function<String, String> result = checkResultDispatcherComX.get(ley);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 判斷條件方法
     */
    private String getDispatcherComXKey(String order, int level) {
        StringBuilder key = new StringBuilder("key");
        for (int i = 1; i <= level; i++) {
            key.append("_" + order + i);
        }
        return key.toString();
    }
}

調用結果：

總結

最後，我們一起嘗試回答以下幾個問題：

1. 策略模式是如何優化業務邏輯代碼結構的？

抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。

2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！

我們所不滿的其實就是傳統接口實現的缺點： 1、策略類會很多。 2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯覽整個業務邏輯

3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？

針對傳統策略模式的缺點，分享了利用Map與函數式接口來實現的思路。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

目錄

• 序言
• DOM事件流
  • 事件捕獲階段、處於目標階段、事件冒泡階段
  • addEventListener 方法
• React 事件概述
• 事件註冊
  • document 上註冊
  • 回調函數存儲
• 事件分發
• 小結
• 參考

1.序言

React 有一套自己的事件系統，其事件叫做合成事件。為什麼 React 要自定義一套事件系統？React 事件是如何註冊和觸發的？React 事件與原生 DOM 事件有什麼區別？帶着這些問題，讓我們一起來探究 React 事件機制的原理。為了便於理解，此篇分析將盡可能用圖解代替貼 React 源代碼進行解析。

2.DOM事件流

首先，在正式講解 React 事件之前，有必要了解一下 DOM 事件流，其包含三個流程：事件捕獲階段、處於目標階段和事件冒泡階段。

W3C協會早在1988年就開始了DOM標準的制定，W3C DOM標準可以分為 DOM1、DOM2、DOM3 三個版本。

從 DOM2 開始，DOM 的事件傳播分三個階段進行：事件捕獲階段、處於目標階段和事件冒泡階段。

（1）事件捕獲階段、處於目標階段和事件冒泡階段

示例代碼：

<html>
    <body>
        <div id="outer">
	    <p id="inner">Click me!</p>
	</div>
    </body>
</html>

上述代碼，如果點擊 <p>元素，那麼 DOM 事件流如下圖：

（1）事件捕獲階段：事件對象通過目標節點的祖先 Window 傳播到目標的父節點。

（2）處於目標階段：事件對象到達事件目標節點。如果阻止事件冒泡，那麼該事件對象將在此階段完成后停止傳播。

（3）事件冒泡階段：事件對象以相反的順序從目標節點的父項開始傳播，從目標節點的父項開始到 Window 結束。

（2）addEventListener 方法

DOM 的事件流中同時包含了事件捕獲階段和事件冒泡階段，而作為開發者，我們可以選擇事件處理函數在哪一個階段被調用。

addEventListener() 方法用於為特定元素綁定一個事件處理函數。addEventListener 有三個參數：

element.addEventListener(event, function, useCapture)

另外，如果一個元素（element）針對同一個事件類型（event），多次綁定同一個事件處理函數（function），那麼重複的實例會被拋棄。當然如果第三個參數capture值不一致，此時就算重複定義，也不會被拋棄掉。

3.React 事件概述

React 根據W3C 規範來定義自己的事件系統，其事件被稱之為合成事件 (SyntheticEvent)。而其自定義事件系統的動機主要包含以下幾個方面：

（1）抹平不同瀏覽器之間的兼容性差異。最主要的動機。

（2）事件”合成”，即事件自定義。事件合成既可以處理兼容性問題，也可以用來自定義事件（例如 React 的 onChange 事件）。

（3）提供一個抽象跨平台事件機制。類似 VirtualDOM 抽象了跨平台的渲染方式，合成事件（SyntheticEvent）提供一個抽象的跨平台事件機制。

（4）可以做更多優化。例如利用事件委託機制，幾乎所有事件的觸發都代理到了 document，而不是 DOM 節點本身，簡化了 DOM 事件處理邏輯，減少了內存開銷。（React 自身模擬了一套事件冒泡的機制）

（5）可以干預事件的分發。V16引入 Fiber 架構，React 可以通過干預事件的分發以優化用戶的交互體驗。

注：「幾乎」所有事件都代理到了 document，說明有例外，比如audio、video標籤的一些媒體事件（如 onplay、onpause 等），是 document 所不具有，這些事件只能夠在這些標籤上進行事件進行代理，但依舊用統一的入口分發函數（dispatchEvent）進行綁定。

4.事件註冊

React 的事件註冊過程主要做了兩件事：document 上註冊、存儲事件回調。

（1）document 上註冊

在 React 組件掛載階段，根據組件內的聲明的事件類型（onclick、onchange 等），在 document 上註冊事件（使用addEventListener），並指定統一的回調函數 dispatchEvent。換句話說，document 上不管註冊的是什麼事件，都具有統一的回調函數 dispatchEvent。也正是因為這一事件委託機制，具有同樣的回調函數 dispatchEvent，所以對於同一種事件類型，不論在 document 上註冊了幾次，最終也只會保留一個有效實例，這能減少內存開銷。

示例代碼：

function TestComponent() {
  handleFatherClick=()=>{
		// ...
  }

  handleChildClick=()=>{
		// ...
  }

  return <div className="father" onClick={this.handleFatherClick}>
	<div className="child" onClick={this.handleChildClick}>child </div>
  </div>
}

上述代碼中，事件類型都是onclick，由於 React 的事件委託機制，會指定統一的回調函數 dispatchEvent，所以最終只會在 document 上保留一個 click 事件，類似document.addEventListener('click', dispatchEvent)，從這裏也可以看出 React 的事件是在 DOM 事件流的冒泡階段被觸發執行。

（2）存儲事件回調

React 為了在觸發事件時可以查找到對應的回調去執行，會把組件內的所有事件統一地存放到一個對象中（listenerBank）。而存儲方式如上圖，首先會根據事件類型分類存儲，例如 click 事件相關的統一存儲在一個對象中，回調函數的存儲採用鍵值對（key/value）的方式存儲在對象中，key 是組件的唯一標識 id，value 對應的就是事件的回調函數。

React 的事件註冊的關鍵步驟如下圖：

5.事件分發

事件分發也就是事件觸發。React 的事件觸發只會發生在 DOM 事件流的冒泡階段，因為在 document 上註冊時就默認是在冒泡階段被觸發執行。

其大致流程如下：

1. 觸發事件，開始 DOM 事件流，先後經過三個階段：事件捕獲階段、處於目標階段和事件冒泡階段
2. 當事件冒泡到 document 時，觸發統一的事件分發函數 ReactEventListener.dispatchEvent
3. 根據原生事件對象（nativeEvent）找到當前節點（即事件觸發節點）對應的 ReactDOMComponent 對象
4. 事件的合成
   1. 根據當前事件類型生成對應的合成對象
   2. 封裝原生事件對象和冒泡機制
   3. 查找當前元素以及它所有父級
   4. 在 listenerBank 中查找事件回調函數併合成到 events 中
5. 批量執行合成事件（events）內的回調函數
6. 如果沒有阻止冒泡，會將繼續進行 DOM 事件流的冒泡（從 document 到 window），否則結束事件觸發

注：上圖中阻止冒泡是指調用stopImmediatePropagation 方法阻止冒泡，如果是調用stopPropagation阻止冒泡，document 上如果還註冊了同類型其他的事件，也將會被觸發執行，但會正常阻斷 window 上事件觸發。了解兩者之間的詳細區別

示例代碼：

class TestComponent extends React.Component {

  componentDidMount() {
    this.parent.addEventListener('click', (e) => {
      console.log('dom parent');
    })
    this.child.addEventListener('click', (e) => {
      console.log('dom child');
    })
    document.addEventListener('click', (e) => {
      console.log('document');
    })
    document.body.addEventListener('click', (e) => {
      console.log('body');
    })
    window.addEventListener('click', (e) => {
      console.log('window');
    })
  }

  childClick = (e) => {
    console.log('react child');
  }

  parentClick = (e) => {
    console.log('react parent');
  }

  render() {
    return (
      <div class='parent' onClick={this.parentClick} ref={ref => this.parent = ref}>
        <div class='child' onClick={this.childClick} ref={ref => this.child = ref}>
          Click me!
        </div>
      </div>)
  }
}

點擊 child div 時，其輸出如下：

在 DOM 事件流的冒泡階段先後經歷的元素：child <div> -> parent <div> -> <body> -> <html> -> document -> window，因此上面的輸出符合預期。

6.小結

React 合成事件和原生 DOM 事件的主要區別:

（1）React 組件上聲明的事件沒有綁定在 React 組件對應的原生 DOM 節點上。

（2）React 利用事件委託機制，將幾乎所有事件的觸發代理（delegate）在 document 節點上，事件對象(event)是合成對象(SyntheticEvent)，不是原生事件對象，但通過 nativeEvent 屬性訪問原生事件對象。

（3）由於 React 的事件委託機制，React 組件對應的原生 DOM 節點上的事件觸發時機總是在 React 組件上的事件之前。

7.參考

javascript中DOM0,DOM2,DOM3級事件模型解析

Event dispatch and DOM event flow

EventTarget.addEventListener() – Web API 接口參考| MDN

合成事件

談談React事件機制和未來(react-events)

React源碼解讀系列 – 事件機制

一文吃透 react 事件機制原理

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

 

BMW i3 純電動汽車今年 8 月在美銷量為 1,025 輛，首次超過特斯拉 Model S，後者 8 月銷量僅為 600 輛。

寶馬 i3 純電動車型在美國市場已上市 3 個月，之前由於寶馬內部的運轉效率問題，其銷量一直低於特斯拉 Model S。但該問題解決後，寶馬 i3 的銷量也迎頭趕上。特斯拉 8 月整體需求較去年同期下降 54%，7 月更是下降了 72%。與 2013 年同期相比，特斯拉今年上半年銷量下降了 26%。

專家稱，特斯拉目前正處發展壯大的階段，而寶馬在歐洲和亞洲市場則以紮穩腳跟。在產品創新度、更新速度及售價方面，特斯拉 Model S 的優勢愈來愈不明顯，而隨著寶馬 i3 的銷量逐步上升，預計歐洲將會成為其最大銷售市場。

 

（圖片來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?