Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to transfer the front-end data to the back-end when dashboard creates a key". In daily operation, I believe that many people have doubts about how the front-end data is transmitted to the back-end when dashboard creates a key. Xiaobian consulted all kinds of information and sorted out a simple and easy-to-use method of operation. I hope it will be helpful for everyone to answer the doubt of "how to transfer the front-end data to the back-end when dashboard creates a key". Next, please follow the editor to study!

We create a key and a corresponding account, which corresponds to the following figure:

When we click the "Register" button, how the parameters we filled in on the front page are passed to the back end of Biyuan step by step.

As before, we will break down the problem and break it down one by one:

Front-end: when we fill out the form and click submit, how does the original front-end send data?

Backend: how does the original backend receive data?

Front-end: when we fill out the form and click submit, which interface will the data be sent to the back end?

When we click the "Register" button, a request to the webapi interface of the original node must be triggered somewhere on the front-end page. Which web api are you visiting? What does the submitted data look like? Let's take a look at the front-end code.

Note that Beehara's front-end code is in another project repository, bytom/dashboard. To match the v1.0.1 code we used in this series, I found the v1.0.0 code in dashboard and submitted it to a separate project: freewind/bytom-dashboard-v1.0.0. Note that the project code has not been modified and its master branch corresponds to the v1.0.0 branch of the official code repository. The reason for making a separate one is that every time we quote a piece of code in the article, we will give a link on the corresponding github, so that the reader can skip over to see the whole picture and use a separate project, which will make the process easier.

Since the original front-end page is dominated by React, I guess there should also be a component called Register in the code, or a button named Register in some form. After searching, we were lucky to find the component file Register.jsx, which is exactly what we need.

The highly simplified code is as follows:

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. / 1. / 2. {lang = = 'zh'? 'Register': 'Register'} / /.... / /.)}}

The above code, a total of five places to pay attention to, was marked by me with numbers. Note that these five numbers are not marked from top to bottom, but in the order in which we pay attention:

The input boxes on the form are where we fill in aliases and passwords. What we need to pay attention to here is the fieldProps attribute of each TextField, which corresponds to the name of the data we submitted to the backend.

That's the "Register" button. It should be noted that its type is submit, that is, after clicking it, it will trigger the onSubmit method of the form.

Back to the beginning of form. Notice that in its onSubmit, handleSubmit (this.submitWithErrors) is called. The handleSubmit is passed in from the third-party redux-form used by the form to handle the form submission, and we don't care about it here, we just need to know that we need to pass our handler this.submitWithErrors to it. In the latter, we will call the web api provided by the original node

The this.submitWithErrors in step 3 will eventually end up with the submitWithErrors function defined here

SubmitWithErrors will initiate an asynchronous request and eventually call the registerKey function passed in from the outside

We can't see which api is being called from here, so we have to keep looking for registerKey. RegisterKey was quickly found in the same file:

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

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

It will call the function actions.core.registerKey again:

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

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

As you can see, there are a lot of things to do in this function. And instead of calling the background interface once as I expected at first, it was called twice (creating a key and an account, respectively). The following is an analysis:

1.1 parameters that need to be prepared for the backend to create keys. One is alias and the other is password. They are all filled in by the user.

1.2 is to call the API used by the backend to create the key, pass the keyData, and get the returned resp for subsequent processing.

2.1The parameters that need to be prepared for the backend to create an account are root_xpubs, quorum and alias, where root_xpubs is the public key returned after the key is created, quorum does not know (TODO), and alias is the account alias entered by the user

2.2 this sentence doesn't work (officially confirmed) because I can't find the code in the code to handle CREATE_REGISTER_KEY. You can see this issue#28.

2.3 call the backend to create an account, pass the accountData, and you can get the returned resp

2.4.After a successful call, use the dispatch function of redux to distribute a CREATE_REGISTER_ACCOUNT message. But this information doesn't seem to be of much use.

With regard to CREATE_REGISTER_ACCOUNT, I found two correlations in the code:

Src/features/core/reducers.js#L229-L234

Const accountInit = (state = false, action) = > {if (action.type = = 'CREATE_REGISTER_ACCOUNT') {return true} return state}

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')} / /...}}

The first one seems useless, and the second one should be used to display the relevant error message after the operation is completed.

So let's focus on the two background calls 1.2 and 2.3.

ChainClient () .mockHsm.keys.create (keyData) corresponds to:

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)}, / /.}}

You can see that in the create method, if the body.xprv is not found (which is the case for this article), the / create-key interface in the background is called. After a long trail, we finally found one.

ChainClient () .accounts.create (accountData) corresponds to:

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

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

Soon we found here that the interface we called when creating the account was / create-account

At the front end, we finally finished the analysis. Next, you will enter the original node (that is, the backend).

Backend: how does the original backend receive data?

If we remember the previous article, we will remember that after starting, the http service corresponding to web api will be started in the Node.initAndstartApiServer method, and a lot of function points will be configured in the API.buildHandler () method, among which there must be the interface we call here.

Let's look at the API.buildHandler method:

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)) / /...

Soon, we found out:

/ create-account: corresponding to a.createAccount

/ create-key: corresponding to a.pseudohsmCreateKey

Let's first take a look at 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 {/ /.}

As you can see, the second parameter of pseudohsmCreateKey is a struct, which has two fields, Alias and Password, which correspond to the parameter keyData passed from the front end. So how is the value of this parameter converted from the submitted JSON data? As we mentioned last time, it is mainly carried out by the jsonHandler attached to the a.pseudohsmCreateKey, which handles the operations related to the http protocol and converts the JSON data into the parameters of the Go type needed here, so that pseudohsmCreateKey can use it directly.

Since in this small problem, the boundary of our problem is more than how the original background got the data, we can stop the analysis of this method here. Exactly how it creates the key will be discussed in more detail in a future article.

Take a look at a.createAccount:

Api/accounts.go#L15-L30

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

As before, the parameters RootXPubs, Quorum, and Alias of this method are also submitted by the front end and automatically converted by jsonHandler.

At this point, the study on "how the front-end data is transmitted to the back-end when dashboard creates the key" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.