① app 與 內嵌webview同步登錄狀態，有哪些解決方案安全性如何
目前使用的方案：
1.h5通過js和app交互調用app的token
2.拿到token後使用ajax做非同步登錄並刷新頁面
目前的缺點：
1.會多次刷新頁面
2.通過js調用時H5需要做部分改動
優化的方向：
A.APP登陸狀態的變化是請求頁面,登錄後使用webview調用對應域名下的介面實現H5的登錄
B.每次請求H5url增加get登陸的信息，例如訪問 index.php變成 index.php?a=xxx 通過附加信 息同步登錄狀態
優化的方案不知道那個更好一點
② nodejs api怎麼實現私有調用
你可以通過如下的步驟，輕松進入開發狀態
1，獲得代碼
https://github.com/mz121star/taobao.git
2，進入項目目錄，執行如下命令安裝項目的依賴包
npm install
3，修改appconfig.js文件中的Appkey和Appsecret的值（該值從你的應用證書頁面獲得）
AppKey:"從淘寶獲得的Appkey",
AppSecret:"從淘寶獲得的AppSecret"
到此為止，你已經完成了項目運行起來所需要的全部步驟，你可以通過如下命令啟動web服務.
③ 使用mobx怎樣管理javascript應用狀態
1. 通過MobX來解決
MobX 是一個簡單、高效的前端狀態管理腳本庫。 根據文檔，Just do something to the state and MobX will make sure your app respects the changes。
var person = mobx.observable({
firstName: 'Matt',
lastName: 'Ruby',
age: 37,
fullName: function () {
this.firstName + ' ' + this.lastName;
}
});
注意下區別，mobx.observable是以下做的唯一區別，再來看下console.log輸出的內容。
mobx.autorun(function () {
console.log('first name: ' + person.firstName);
});
person.age = 38; // 不列印內容
person.lastName = 'RUBY!'; // 仍然不列印內容
person.firstName = 'Matthew!'; // 列印內容
通過使用autorun， MobX只會檢測使用到的內容。如果覺得不夠清楚，來看下下面的：
mobx.autorun(function () {
console.log('Full name: ' + person.fullName);
});
person.age = 38; // 不列印內容
person.lastName = 'RUBY!'; // 列印內容
person.firstName = 'Matthew!'; // 列印內容
相信你已經理解了。
MobX核心概念
observer
var log = function(data) {
$('#output').append('<pre>' +data+ '</pre>');
}
var person = mobx.observable({
firstName: 'Matt',
lastName: 'Ruby',
age: 34
});
log(person.firstName);
person.firstName = 'Mike';
log(person.firstName);
person.firstName = 'Lissy';
log(person.firstName);
MobX可觀察的對象都是普通的對象。這個例子中我們沒有觀察任何內容，這里例子也展示了怎樣將MobX使用到項目中。只需要使用mobx.observable()或 mobx.extendObservable()就可以了。
autorun
var person = mobx.observable({
firstName: 'Matt',
lastName: 'Ruby',
age: 0
});
mobx.autorun(function () {
log(person.firstName + ' ' + person.age);
});
// this will print Matt NN 10 times
_.times(10, function () {
person.age = _.random(40);
});
// this will print nothing
_.times(10, function () {
person.lastName = _.random(40);
});
當變數值改變時，肯定想做一些事情，所以使用autorun()，將會在任何一個觀察的內容改變時觸發回調。注意下上面的例子中age改變時autorun()不會觸發。
computed
var person = mobx.observable({
firstName: 'Matt',
lastName: 'Ruby',
age: 0,
get fullName () {
return this.firstName + ' ' + this.lastName;
}
});
log(person.fullName);
person.firstName = 'Mike';
log(person.fullName);
person.firstName = 'Lissy';
log(person.fullName);
2. 注意下fullName()方法沒有使用參數和get的用法，MobX會自動創建一個計算的值。。person.fullName有什麼不同的地方？這是一個函數，但是沒有調用就獲取到了結果！通常，使用的是person.fullName()，而不是person.fullName。這里就是遇到的第一個getter函數。
不僅如此，MobX還會監聽計算值得依賴的變數，並且只在它們修改的時候運行觸發更新。如果沒有修改，將會直接返回之前緩存中的值。看下面一個例子。
var person = mobx.observable({
firstName: 'Matt',
lastName: 'Ruby',
age: 0,
get fullName () {
// Note how this computed value is cached.
// We only hit this function 3 times.
log('-- hit fullName --');
return this.firstName + ' ' + this.lastName;
}
});
mobx.autorun(function () {
log(person.fullName + ' ' + person.age);
});
// this will print Matt Ruby NN 10 times
_.times(10, function () {
person.age = _.random(40);
});
person.firstName = 'Mike';
person.firstName = 'Lissy';
3. 這里使用了person.fullName很多次，但是函數只有在firstName和lastName修改時才會運行。這就是MobX可以提供應用速度的一種方式。
使用MobX進行項目實踐
直接看例子：
<h1>Test</h1>
<script>
var person = {
events: {},
firstName: 'Matt',
lastName: 'Ruby',
age: 37,
fullName: function() {
return this.firstName + ' ' + this.lastName;
},
setPersonData: function(personData) {
$.extend(this, personData);
$(this.events).trigger('changed', personData);
}
};
var renderCount = 0;
$(person.events).on('changed', function() {
renderCount += 1;
$('h1').text(person.fullName() + ' render count: '+ renderCount);
});
// this will trigger every time
_.times(10, function() {
person.setPersonData({age: _.random(20)});
});
</script>
4. 這里name被重復渲染了10次，盡管沒有修改firstName或lastName，可使用多個事件來優化這里，在渲染之前做判斷。但是太復雜了。下面是MobX的例子；
<h1>Test</h1>
<script>
var person = mobx.observable({
firstName: 'Matt',
lastName: 'Ruby',
age: 37,
get fullName () {
return this.firstName + ' ' + this.lastName;
}
});
var renderCount = 0;
mobx.autorun(function() {
renderCount++;
$('h1').text(person.fullName + ' render count: ' + renderCount);
});
// this will trigger the render one time
_.times(10, function() {
person.setPersonData({
age: _.random(20)
});
});
</script>
注意下這里為什麼沒有事件、觸發器或on綁定。使用MobX，你會使用修改後的最新值。而且它只被渲染一次，這是因為我們沒有修改內容時autorun只是一直在監聽。
// observable person
var person = mobx.observable({
firstName: 'Matt',
lastName: 'Ruby',
age: 37
});
// rece the person to simple html
var printObject = function(objectToPrint) {
return _.rece(objectToPrint, function(result, value, key) {
result += key + ': ' + value + '<br/>';
return result;
}, '');
};
// print out the person anytime there's a change
mobx.autorun(function(){
$('#person').html(printObject(person));
});
// watch all the input for changes and update the person
// object accordingly.
$('input').on('keyup', function(event) {
person[event.target.name] = $(this).val();
});
這里我們能編輯person的所有信息來觀察輸出的內容情況，現在這個例子中有個小小的問題，這里input的值和person的值不同步，這里改下：
mobx.autorun(function(){
$('#person').html(printObject(person));
// update the input values
_.forIn(person, function(value, key) {
$('input[name="'+key+'"]').val(value);
});
});
這里雖有重新渲染。看到的就是為什麼很多人選擇使用React的原因。React允許你將輸出內容拆分小的組件進行個別的渲染。
MobX不一定在實際項目中使用，如果需要這種細粒度的操作使用React就可以了。當在實際項目中使用MobX和jQuery時，使用autorun()就可以解決很多問題了。
④ 如何組織大型JavaScript應用中的代碼
以下為CSDN編譯：地板上堆放的衣服首先，我們來看看angular-seed，它是AngularJS應用開發的官方入門項目，其文件結構是這樣的：css/img/js/app.jscontrollers.jsdirectives.jsfilters.jsservices.jslib/partials/看起來就像是把衣服按類型堆在地板上，一堆襪子、一堆內衣、一堆襯衫等等。你知道拐角的那堆襪子里有今天要穿的黑色羊毛襪，但你仍需要花上一段時間來尋找。這種組織方式很凌亂。一旦你的代碼中存在6、7個甚至更多的控制器或者服務，文件管理就會變得難以處理：很難找到想要尋找的對象，源代碼控制中的文件也變更集變得難懂。襪子抽屜常見的JavaScript文件結構還有另一種形式，即按原型將文件分類。我們繼續用整理衣服來比喻：現在我們買了有很多抽屜的衣櫃，打算將襪子放在其中一個抽屜里，內衣放在另一個抽屜，再把襯衫整齊地疊在第三個抽屜……想像一下，我們正在開發一個簡單的電子商務網站，包括登陸流程、產品目錄以及購物車UI。同樣，我們將文件分為以下幾個原型：models（業務邏輯和狀態）、controllers以及services（HTTP/JSON端點加密），而按照Angular默認那樣非籠統地歸到「service」架構。因此我們的JavaScript目錄變成了這樣：controllers/LoginController.jsRegistrationController.jsProctDetailController.jsSearchResultsController.jsdirectives.jsfilters.jsmodels/CartModel.jsProctModel.jsSearchResultsModel.jsUserModel.jsservices/CartService.jsUserService.jsProctService.js不錯，現在已經可以通過樹形文件目錄或者IDE快捷鍵更方便地查找文件了，源代碼控制中的變更集（changeset）也能夠清楚地描述文件修改記錄。雖然已經獲得了極大的改進，但是仍有一定的局限性。想像一下，你現在正在辦公室，突然發現明天有個商務出差，需要幾套乾洗的衣服，因此給家裡打電話告訴另一半把黑色和藍色的西裝交給清潔工，還有黑紋領帶配灰色襯衫、白襯衫配純黃領帶。如果你的另一半並不熟悉衣櫃，又該如何從三條黃色的領帶中挑出你的正確需求？模塊化希望衣服的比喻沒有讓你覺得過於陳舊，下面舉一個實例：你的搭檔是新來的開發者，他被要求去修補這個復雜應用中的一處bug。他掃過這些文件夾，看到了controllers、models、services等文件夾整齊地排列著，但是他仍然不清楚對象間的依賴關系。處於某些原因，他希望能夠重用部分代碼，這需要從各個文件夾中搜集相關文件，而且常常會遺漏某些文件夾中的對象。信或不信，你確實很少會在新項目中重用很多代碼，但你很可能需要重用登陸系統這樣的整個模塊。所以，是不是按功能劃分文件會更好？下面的文件結構是以功能劃分後的應用結構：cart/CartModel.jsCartService.jscommon/directives.jsfilters.jsproct/search/SearchResultsController.jsSearchResultsModel.jsProctDetailController.jsProctModel.jsProctService.jsuser/LoginController.jsRegistrationController.jsUserModel.jsUserService.js雖然現實世界中有空間限制，難以隨意整理服裝，但是編程中類似的處理卻是零成本的。現在即使是新來的開發者也能通過頂級文件夾的命名理解應用的功能，相同文件夾下的文件會存在互相依賴等關系，而且僅僅通過瀏覽文件組織結構就能輕易理解登錄、注冊等功能的原理。新的項目也可以通過復制粘貼來重用其中的代碼了。使用AngularJS我們可以進一步將相關代碼組織為模塊：var userMole = angular.mole('userMole',[]); userMole.factory('userService', ['$http', function($http) { return new UserService($http); }]); userMole.factory('userModel', ['userService', function(userService) { return new UserModel(userService); }]); userMole.controller('loginController', ['$scope', 'userModel', LoginController]); userMole.controller('registrationController', ['$scope', 'userModel', RegistrationController]);如果我們將UserMole.js文件放到user文件夾，它就成了這個模塊中使用到的對象的「manifest」，這也是適合RequireJS或者Browserify中放置某些載入指令的地方如何處理通用代碼每個應用都會有某些代碼廣泛使用在多個模塊中，我們常常使用名為「commom」或者「shared」的文件夾來存放這些功能代碼。又該如何處理這些通用代碼呢？如果模塊中的對象需要直接訪問幾個「通用」對象，為這些對象提供幾個Facade（外觀模式）。這有助於減少每個對象的依賴者，而過多的關聯對象通常意味著糟糕的代碼結構。如果「通用」模塊變得過於龐大，你需要將它按功能領域細分為多個子模塊。確保每個應用模塊只使用它需要的「通用」模塊，這即是SOLID中「介面隔離原則」的變種。在根范圍（$rootScope）添加實體，這樣子范圍也可以使用，適合多個控制器都依賴同一個對象（比如「PermissionsModel」）的情況。在解耦兩個不明確互相引用的組件時，請使用事件。Angular中Scope對象的$emit、$broadcast以及$on方法使得這種方式變得現實。控制器能夠觸發一個事件來執行某些動作，然後再動作結束後收到相應地通知。
⑤ 在WEB中如何用JS打開APP
先看一下Web中，我們給h1標簽添加一個onclick事件，讓它在被點擊之後，修改當前的url。
Web中的HTML代碼：
<html>
<head>
<script>
function getInfo(name)
{
window.location = "/getInfo/"+name;
}
</script>
</head>
<body>
<h1 onclick="getInfo('why')">Name</h1>
</body>
</html>
iOS中，先拖拽WebView，訪問localhost，然後通過WebView的委託事件監聽url跳轉操作，並且把跳轉截取下來。
也就是說，在onclick的時候，普通瀏覽器灰跳轉到那個url，但是在iOS的這個WebView裡面，這個跳轉會被攔截，
用這種方式可以巧妙地實現JS調用iOS的原生代碼：
//
// DWViewController.m
// DareWayApp
//
// Created by why on 14-6-3.
// Copyright (c) 2014年 DareWay. All rights reserved.
//
#import "DWViewController.h"
@interface DWViewController ()
@property (weak, nonatomic) IBOutlet UIWebView *myWebview; // 主頁面
@end
@implementation DWViewController
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
// 適配iOS6的狀態欄
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 7) {
_myWebview.frame = CGRectMake(0,20,self.view.frame.size.width,self.view.frame.size.height-20);
}
// 載入制定的URL
NSURL *url =[NSURL URLWithString:@"http://localhost"];
NSURLRequest *request =[NSURLRequest requestWithURL:url];
[_myWebview setDelegate:self];
[_myWebview loadRequest:request];
}
// 網頁中的每一個請求都會被觸發
-(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
// 每次跳轉時候判斷URL
if([request.mainDocumentURL.relativePath isEqualToString:@"/getInfo/why"])
{
NSLog(@"why");
return NO;
}
return YES;
}
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}
⑥ vue的hook能將同一功能的代碼單獨抽成1個方法嗎
作者 | 零一 責編 | 張紅月
rex的作者是誰？Dan，他的全稱叫做Dan Abramov，同時他也是React的核心成員之一
為什麼我標題說Dan位元組一面掛了呢？
因為昨天晚上位元組的web infra團隊連線了遠在國外的Dan，並且提前收集了200多個網友的問題，從中精選了20幾個，讓Dan來給一一解答，在其中一個問題的回答中，Dan說他從來沒用過Vue，hhhhh，所以有小夥伴就說搞了個段子
Q1: 如何看待rex
我不會推薦任何一個庫，要看使用場景吧。比如針對數據和緩存的庫，就該用對應的庫
Q2: 很多開發者認為react的入門很難，有沒有什麼快速上手的方法
我認為這取決於大家為什麼認為React難，可能難點不同，因為你剛學javascript，這是你的入門，那就會覺得React很難。對於其它庫例如Vue，你可以運用一些已經封裝好的方法，慢慢的使用中你可以學會一些東西。而react你一上手就要編程，這就是難點所在。如果有人覺得入門很難的話，可能就意味著他們不知道怎麼去做一個單頁的應用程序，可能不是react本身的問題，但他們會認為是react難以理解的問題。可以先把javascript熟悉了，再來用React就很容易了。
Q3: 對於已經開始用react的人，給一些建議避坑
很重要的一點就是你要用Hook的話，我們推薦使用正確的方法把它們引入你的項目當中。對於react來說有兩點，一點是可模仿性，新手可以去學別人的庫，參考著去學習。另一點就是對於react渲染來說，你可以把它想成是一個計算，你不需要做很多工作，你只需要返回你需要的react UI即可，這很重要
Q4: 現在react更多關注的是函數編程，js卻不是這樣的
我認為react的確比其它工具更加偏向於函數，但真正喜歡函數編程的開發者會認為react並不是一個函數編程的工具。我們也不會把組件分解成一個個很小很小的函數。React其實是借用了一些函數的理念，並且基於函數，但不完完全全是一個函數編程工具
Q5: 現在前端發展迅速，你是怎麼跟上技術發展速度的
我不是這樣想的，但有可能是我沒有跟緊潮流，可能是每隔幾年就有這樣的趨勢，但很多像現在的新技術跟以前的技術概念其實很相似，這種情況下，我不會被這種新興的技術驚到，因為他們對我來說沒有什麼太大的不同，所以這其實就是對老事物一種新的理解，我們圍繞一些基本概念做一些開發而已。
Q6: react在未來如何進步呢？
你認為現在存在哪些重大的問題呢？對我來說我會注意到很多問題都是不同的，不同的問題用不同的手段去解決，其中一個問題比如說， 動畫領域我們還沒有涉足，很多ui框架會針對一些不同的問題提供一些解決方案， 我的感覺是這些領域看起來不一樣，但其實都類似，我們可以互相結合。 以後我們可能會有一個組件工具，或者提供更多的功能，這些功能是緊密結合的，這是我們希望的。
Q7: Concurrent mode，從18版本開始最新被放出來的模式，設計時面臨的挑戰有哪些？
我想說當前還沒有被發行出來，所以我們可以去官網看一下blog，上面有關於版本18更多的信息，關於他有什麼內容，信息等等。我們現在有相關的工作小組，並且每天從社區邀請50個人左右幫我們一起合作去發行18版本，保證整個生態系統和他發行的版本是一致的，我們在這方面已經有了很多的討論，大家都可以閱讀，評論，獲取更多的信息。我們所做出來的一個大的改變就是我們沒有mode了，它不叫concurrent mode，而負責的是render的一種機制，他不會有一個延長等待的時間，比如你如果有輸入，他也可以同步的處理，其實他是一種同步多線的處理，這也是我們一直想攻克的難關。這才有了我們現在的18 Alpha版本。
Q8: 很多人會將react跟vue做對比，你是怎麼看待這兩個框架的？
我自己沒用過vue的（what？？？React核心成員之一竟然沒有用過Vue，此處@尤大），所以沒法做很細節和全面的對比，從設計方法上來說，我們存在一些區別，比如vue直接改變狀態，這有一些好處，你可以隨心所欲的想寫代碼就寫代碼，很多人都很喜歡這樣的方式，但對於我們來說，我們會做一些transition，我們方式不一樣，所以從技術來說我們有很大的差異，是兩種完全不同的方向。vue可能是基於50年的編程的沉澱，對於我們來說基於我們自己的做法，當然他們的做法在技術上來說也是很棒的，vue更多會用一些實用的技術解決實用的問題，比如提供更加便利的動畫的解決方案，更便利的模板，但對於react來說，我們不想去做一些我們沒有辦法充分相信的解決方案，所以我們給出的東西可能沒有那麼直接便利，比如我們想做動畫功能的話，我們並不會去標准化一些存在的東西，我們會有自己對於動畫的想法，這跟現在很多框架都是不一樣的，vue可以更快的拿到你所想要的，但react我們有更豐富的庫，你就可以學會怎麼去做這些事，這就像安卓和ios一樣，ios其實很多功能都不包括的，但是它可以幫助你可以更好的完成一些事情。
Q9: vue3停止用flow了，react還用flow？
我並不認為這是一個很關鍵的問題，我認為這主要取決於庫本身是怎麼寫的。他更多的是關注框架本身如何建立的，跟用戶沒啥關系，它並不會影響用戶使用react的過程，我們並不在意這個點，我們並不是不能改變，只是不太值得
Q10: 你對一些新框架有什麼看法，他們都沒有使用vdom
我並沒有多麼細致的使用過這些工具，沒有什麼深度的見解，的確有很多的設計他們是很棒的，而且大家都走的不同的路，可能是完全相反，對於vdom這個詞我不太喜歡，大家理解都不太一樣，我認為這個跟性能沒什麼關系，我不太使用這個稱呼，因為這使人很困惑，他指的是UI的內存，我們想讓他保留下來，因為他能給我們更多的選擇。對於一些復雜的功能，我們的解決方式可能會使用UI的不同版本，比如最左邊是0%，右邊是100%，中間會有一個滾動條，在調整滾動條只需要調整幀就好了，我們如何產生這種幀，就需要很多的ui進行協助，這就需要vdom的協助，這和性能的關系不大。假設我們要看整個app的性能，需要看你每個組件的功能是什麼，它可以做什麼，看看app背後的代碼是什麼，而不是單純對幾行的代碼做分析和解讀。
Q11: 目前用的大多是vue和react，你對於前端來說如何看待五年後的前端領域
我對這個問題的理解是，ui代碼有很多不同的方式，比如放在伺服器上還是客戶端上，如何去整理它，那我覺得在這方面 框架也可以解決所有的問題，我覺得next.js是可以把react相關的觀念去簡化，所以他有可能會取代目前的功能，如果大家對Server Component 感興趣的話，你的思考模式是圍繞組件進行的，這是可控的，那你也可以做出自主的決定，吧什麼樣的組件在伺服器去運轉，不會佔用你太長的時間，代碼也是一樣的，他們會更加的清晰，你就不需要去思考你是在做渲染還是做別的事情，這是一種很不錯的優化。
Q12: 對於找工作的同學來說，什麼樣的科技公司更吸引人？
我覺得你身邊的人比較厲害，你能學到很多東西，這是良性的工作環境，可以學習新的知識，而且還需要你的自主性會比較強，不能命令式的工作（其實當時彈幕里全是一個字：錢！）
Q13: 說說你的個人經歷，你剛加入Facebook，如何學習react的相關知識的
react代碼其實比較復雜，在最開始需要研究代碼，去熟悉，主要還是去了解整個的架構，把它了解透徹了沒問題了，就Ok了。還會給一些人提供幫助，我會在一些公開的平台上幫助別人解決問題，回答他們的問題，在那段時間閱讀了各種人提出的問題，幾千條，這是一個非常好的方法幫我熟悉自己所做的東西，幫他們解決問題，也對自己有幫助。
Q14: react核心團隊或社區如何維護這么大的code
我們遇到很多有趣的挑戰，我並不認為我們的code很大，我們也是在慢慢的學習如何運行這樣的項目，我們有超過5000次的測試。react用戶只會用來rendering，不會深入到我們庫里。如果你去看我們的代碼，我們可能會有一個老js和新Js（即源碼文件中以.old.js或.new.js為結尾的文件），它們基本上是相同的，我們這么做是為了應對一些有風險的改變，我們沒有看到回歸，我們就會把新的改變復制到舊的當中，這聽起來很奇怪，但效果還不錯。
我認為Facebook就像一個測試機器一樣，我們會在工作中驗證，我們看到了百分之一的回歸，評論下降了1%，我們就花了一個月對各個組件做實驗區檢測，發現了一個bug並解決了。即使當時下降了1%，但是對於Facebook來說是一個很大的損失。
Q15: 作為react用戶，我們去看源碼，是不是一個好的做法
我並不認為很有必要，因為很難去理解我們的源碼，如果你直接去讀，你可能會很困惑，因為你不了解底層的框架，有人跟你解釋一下可能更好一些。我經常做的一件事，就是用一個debugger去看這些代碼不同的去向，比如在chrome performance里看到函數代碼的棧，你可以看到每一個函數發生的不同的事情，比如你在升級的時候就可以看到一些新的事件和功能，所以可以從性能這個方面看到這些基本的功能的目的是什麼
Q16: 你是如何保持對react的熱情的
我本身就很喜歡，react理念跟我對ui代碼的想法很一致，我在facebook之前，在初創公司，當時直接用了react，當時不流行，但給我們工作帶來了很大的便利，我們還可以清楚地看到各個功能的狀態，我們經常問自己想在屏幕上看到的功能是什麼，react就能解決當下這個問題
Q17: 如何像你一樣優秀，前端好的學習資源分享
我並不確定我有多麼優秀，如果你認為優秀可以做一個非常好看的app，那我並不是，所以說我並不是很確定大家想聽到什麼樣的建議。
建議的話，我覺得你可以不用vue或react這樣的框架去寫一些ui框架，或者做一些小游戲，比如貪吃蛇，這樣去促使你去做，即使它有一些復雜度，但能從中吸取一些經驗。
Q18: 休閑時間會做什麼呢？
偶爾玩玩堡壘之夜，但是也很久沒玩游戲了，平時就聽聽歌、散散步
Q19: 對於中國開發者的建議
我覺得我不太確定一些事，我不知道react在中國多少人在用，在這個社區里，大家可以有不同的選擇，非常感謝他們在翻譯上做出的工作（此處@印記中文），我不太確定react在未來能否風靡中國，希望大家去多推薦一下react，讓更多人了解到，我們將來做出更多的改變。
Q20: 未來是否願意會在中國的react社區更多得活躍一下
必須滴！
最後辛苦Dan啦，全程一個半小時一直在解答大家的問題，一口水都沒喝。而且他回答問題都回答得非常詳細，都盡可能地多說一些，所以遠不止我記錄的那麼點文字，真的是很有愛了~ 期待下一次Dan與國內程序員的互動！！！也感謝 Web infra 團隊提供的這次機