剝開比原看代碼09：經過dashboard建立密鑰時，前端的數據是如何傳到後端的?

時間  2019-11-26
標籤 剝開 代碼 經過 dashboard 建立 密鑰 前端 數據 如何 傳到 後端 简体版
原文   原文鏈接

做者：freewind前端

比原項目倉庫：git

Github地址：https://github.com/Bytom/bytomgithub

Gitee地址：https://gitee.com/BytomBlockchain/bytomweb

在前面一篇文章，咱們粗略的研究了一下比原的dashboard是如何作出來的，可是對裏面提到的各類細節功能，並無深刻的去研究。那麼從本文開始，咱們將在這一段時間，分別研究裏面提到的每一項功能。json

在前一篇文章中，當咱們第一次在瀏覽器中打開dashboard時，由於尚未建立過密鑰，因此比原會提示咱們輸入一些別名和密碼，爲咱們建立一個密鑰和相應的賬戶。就是下面這張圖所對應的： 那麼本文就將研究一下，當咱們點擊了"Register"按鈕之後，咱們在前端頁面上填寫的參數，究竟是如何一步步的傳到比原的後端的。redux

跟以前同樣，咱們將對這個問題進行細分，而後各個擊破：後端

  1. 前端：當咱們填完表單，點了提交之後，比原在前端是如何發送數據的？
  2. 後端：比原的後端是如何接收到數據的？

前端：當咱們填完表單，點了提交之後，數據會發送到後端的哪一個接口？

當咱們點擊了"Register"按鈕，在前端頁面中，必定會在某個地方觸發一個向比原節點webapi接口發出請求的操做。到底是訪問的哪一個web api？提交的數據又是什麼樣的呢？讓咱們先從前端代碼中尋找一下。api

注意，比原的前端代碼位於另外一個項目倉庫bytom/dashboard中。爲了能與咱們在本系列文章中使用的比原v1.0.1的代碼相匹配，我找到了dashboard中的v1.0.0的代碼，而且提交到了一個單獨的項目中：freewind/bytom-dashboard-v1.0.0。注意該項目代碼未作任何修改，其master分支對應於官方代碼倉庫的v1.0.0分支。之因此要弄一個單獨的出來，這是由於咱們在文章中，每次引用一段代碼的時候，都會給出相應的github上的連接，方便讀者跳過去查看全貌，使用一個獨立項目，會讓這個過程更簡便一些。瀏覽器

因爲比原的前端頁面是使用React爲主的，因此我猜測在代碼中，也該會有一個名爲Register的組件，或者某個表單中有一個名爲Register的按鈕。通過搜索，咱們幸運的發現了Register.jsx 這個組件文件，它正好是咱們須要的。app

通過高度簡化後的代碼以下：

src/features/app/components/Register/Register.jsx#L9-L148

class Register extends React.Component {
  // ...
  // 4. 
  submitWithErrors(data) {
    return new Promise((resolve, reject) => {
      // 5. 
      this.props.registerKey(data)
        .catch((err) => reject({_error: err.message}))
    })
  }
  // ...

  render() {
    // ...
    return (
      // ...
      // 3.
      <form className={styles.form} onSubmit={handleSubmit(this.submitWithErrors)}>
        // 1.
        <TextField
          title={lang === 'zh' ? '帳戶別名' : 'Account Alias'}
          placeholder={lang === 'zh' ? '請輸入帳戶別名...' : 'Please enter the account alias...'}
          fieldProps={accountAlias} />
        <TextField
          title={lang === 'zh' ? '密鑰別名' : 'Key Alias'}
          placeholder={lang === 'zh' ? '請輸入密鑰別名...' : 'Please enter the key alias...'}
          fieldProps={keyAlias}/>
        <TextField
          title={lang === 'zh' ? '密鑰密碼' : 'Key Password'}
          placeholder={lang === 'zh' ? '請輸入密鑰密碼...' : 'Please enter the key password...'}
          fieldProps={password}
          type='password'/>
        <TextField
          title={lang === 'zh' ? '重複輸入密鑰密碼' : 'Repeat your key password'}
          placeholder={lang === 'zh' ? '請重複輸入密鑰密碼...' : 'Please repeat the key password...'}
          fieldProps={repeatPassword}
          type='password'/>

        // 2. 
        <button type='submit' className='btn btn-primary' disabled={submitting}>
          {lang === 'zh' ? '註冊' : 'Register'}
        </button>
        // ....
        </form>
      // ...
    )
  }
}

上面的代碼，共有5個地方須要注意，被我用數字標示出來了。注意這5個數字並非從上到下標註，而是按照咱們關注的順序來的：

  1. 表單上的各個輸入框，就是咱們填寫別名和密碼的地方。這裏須要關注的是每一個TextField的fieldProps屬性，它對應咱們提交到後臺的數據的name
  2. 就是那個「Register」按鈕了。須要注意的是，它的type是submit，也就是說，點擊它之後，將會觸發所在form的onSubmit方法
  3. 回到了form的開頭。注意它的onSubmit裏面，調用的是handleSubmit(this.submitWithErrors)。其中的handleSubmit是從該表單所使用的第三方redux-form中傳入的，用來處理表單提交，咱們在這裏不關注它，只須要知道咱們須要把本身的處理函數this.submitWithErrors傳給它。而在後者中，咱們將會調用比原節點提供的web api
  4. 第3步中的this.submitWithErrors最終將走到這裏定義的submitWithErrors函數
  5. submitWithErrors將會發起一個異步請求，最終調用由外部傳進來的registerKey函數

從這裏咱們還看不到調用的是哪一個api，因此咱們必須繼續去尋找registerKey。很快就在同文件中找到了registerKey：

src/features/app/components/Register/Register.jsx#L176-L180

(dispatch) => ({
    registerKey: (token) => dispatch(actions.core.registerKey(token)),
    // ...
  })

它又將會調用actions.core.registerKey這個函數：

src/features/core/actions.js#L44-L87

const registerKey = (data) => {
  return (dispatch) => {
    // ...
    // 1.1
    const keyData = {
      'alias': data.keyAlias,
      'password': data.password
    }
    // 1.2
    return chainClient().mockHsm.keys.create(keyData)
      .then((resp) => {
        // ...
        // 2.1
        const accountData = {
          'root_xpubs':[resp.data.xpub],
          'quorum':1,
          'alias': data.accountAlias}
        // 2.2
        dispatch({type: 'CREATE_REGISTER_KEY', data})

        // 2.3
        chainClient().accounts.create(accountData)
          .then((resp) => {
            // ...
            // 2.4
            if(resp.status === 'success') {
              dispatch({type: 'CREATE_REGISTER_ACCOUNT', resp})
            }
          })
    // ...
      })
    // ...
  }
}

能夠看到，在這個函數中，作的事情仍是不少的。並且並非我一開始預料的調用一次後臺接口就好了，而是調用了兩次（分別是建立密鑰和建立賬戶）。下面進行分析：

  1. 1.1是爲了讓後臺建立密鑰而須要準備的參數，一個是alias，一個是password，它們都是用戶填寫的
  2. 1.2是調用後臺用於建立密鑰的接口，把keyData傳過去，而且拿到返回的resp後，進行後續的處理
  3. 2.1是爲了讓後臺建立賬戶而須要準備的參數，分別是root_xpubs, quorum和alias，其中root_xpubs是建立密鑰後返回的公鑰，quorum目前不知道（TODO），alias是用戶填寫的賬戶別名
  4. 2.2這一句沒有做用（通過官方確認了），由於我在代碼中沒有找處處理CREATE_REGISTER_KEY的代碼。能夠看這個issue#28
  5. 2.3調用後臺建立賬戶，把accountData傳過去，能夠拿到返回的resp
  6. 2.4調用成功後，再使用redux的dispatch函數分發一個CREATE_REGISTER_ACCOUNT信息。不過這個信息好像也沒有太大用處。

關於CREATE_REGISTER_ACCOUNT，我在代碼中找到了兩處相關：

  1. src/features/core/reducers.js#L229-L234
const accountInit = (state = false, action) => {
  if (action.type == 'CREATE_REGISTER_ACCOUNT') {
    return true
  }
  return state
}
  1. src/features/app/reducers.js#L10-L115
export const flashMessages = (state = {}, action) => {
  switch (action.type) {
    // ...
    case 'CREATE_REGISTER_ACCOUNT': {
      return newSuccess(state, 'CREATE_REGISTER_ACCOUNT')
    }
    // ...
  }
}

第一個看起來沒什麼用，第二個應該是用來在操做完成後，顯示相關的錯誤信息。

那就讓咱們把關注點放在1.2和2.3這兩個後臺調用的地方吧。

  1. chainClient().mockHsm.keys.create(keyData)對應的是：

src/sdk/api/mockHsmKeys.js#L3-L31

const mockHsmKeysAPI = (client) => {
  return {
    create: (params, cb) => {
      let body = Object.assign({}, params)
      const uri = body.xprv ? '/import-private-key' : '/create-key'

      return shared.tryCallback(
        client.request(uri, body).then(data => data),
        cb
      )
    },
    // ...
  }
}

能夠看到在create方法中，若是找不到body.xprv（就是本文對應的狀況），則會調用後臺的/create-key接口。通過一長串的跟蹤，咱們終於找到了一個。

  1. chainClient().accounts.create(accountData)對應的是：

src/sdk/api/accounts.js#L3-L30

const accountsAPI = (client) => {
  return {
    create: (params, cb) => shared.create(client, '/create-account', params, {cb, skipArray: true}),
    // ...
  }
}

很快咱們在這邊，也找到了建立賬戶時調用的接口爲/create-account

前端這邊，咱們終於分析完了。下一步，將進入比原的節點（也就是後端）。

後端：比原的後端是如何接收到數據的？

若是咱們對前一篇文章還有印象的話，會記得比原在啓動以後，會在Node.initAndstartApiServer方法中啓動web api對應的http服務，而且在API.buildHandler()方法中會配置不少的功能點，其中必定會有咱們這裏調用的接口。

讓咱們看看API.buildHandler方法：

api/api.go#L164-L244

func (a *API) buildHandler() {
    walletEnable := false
    m := http.NewServeMux()

    if a.wallet != nil {
        walletEnable = true
        // ...
        m.Handle("/create-account", jsonHandler(a.createAccount))
        // ...
        m.Handle("/create-key", jsonHandler(a.pseudohsmCreateKey))
        // ...

很快，咱們就發現了：

  1. /create-account: 對應a.createAccount
  2. /create-key: 對應a.pseudohsmCreateKey

讓咱們先看一下a.pseudohsmCreateKey：

api/hsm.go#L23-L32

func (a *API) pseudohsmCreateKey(ctx context.Context, in struct {
    Alias    string `json:"alias"`
    Password string `json:"password"`
}) Response {
    // ...
}

能夠看到，pseudohsmCreateKey的第二個參數，是一個struct，它有兩個字段，分別是Alias和Password，這正好和前面從前端傳過來的參數keyData對應。那麼這個參數的值是怎麼由提交的JSON數據轉換過來的呢？上次咱們說到，主要是由a.pseudohsmCreateKey外面套着的那個jsonHandler進行的，它會處理與http協議相關的操做，以及把JSON數據轉換成這裏須要的Go類型的參數，pseudohsmCreateKey就能夠直接用了。

因爲在這個小問題中，咱們問題的邊界是比原後臺是如何拿到數據的，因此咱們到這裏就能夠中止對這個方法的分析了。它具體是怎麼建立密鑰的，這在之後的文章中將詳細討論。

再看a.createAccount：

api/accounts.go#L15-L30

// POST /create-account
func (a *API) createAccount(ctx context.Context, ins struct {
    RootXPubs []chainkd.XPub `json:"root_xpubs"`
    Quorum    int            `json:"quorum"`
    Alias     string         `json:"alias"`
}) Response {
    // ...
}

與前面同樣，這個方法的參數RootXPubs、Quorum和Alias也是由前端提交，而且由jsonHandler自動轉換好的。

當咱們清楚了在本文中，先後端數據是如何交互的，就很容易推廣到更多的情景。在前端還在不少的頁面和表單，在不少地方都須要調用後端的接口，我相信按照本文的思路，應該均可以快速的找到。若是有比較特殊的狀況，咱們之後會再專門寫文章講解。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程