React + Redux Evolution

こんにちは、Habr、素晴らしいボードゲーム「Evolution：The Origin of Species」のオンラインバージョンを書いたので、アーキテクチャと技術的な問題に関するメモを共有したいと思います。 すぐに明確にします-宣伝するのではなく、エラーと機能について話すことに興味があり、その見返りに、私の決定とコードについて多くの新しくて良いことを聞きます。

まず、ゲームについて少し説明しますが、技術的な詳細を求める人のためにネタバレの下に隠れています。

一般に、ゲームにはかなり単純な基本ルールがありますが、すべての相互作用を計算することは非常に興味深く、時には複雑です。 それとは別に、追加について言及する価値があります。これは約3つの部分であり、すべてを逆さまにします。 つまり、最初のプロパティがまだ正常である場合、9つの新しいプロパティを追加します（トリッキーなメカニズムはありますが）。次に、2番目の大陸は、テーブルを3つの部分に分割し、ゲーム全体が3つの異なる大陸で行われます。 また、「植物」はゲームからキューブを削除し、制御可能な植物もフィードベースになります。

だから、今、プロジェクトについて、私はカットの下にそれを隠しません、あなたはこれのために来ました：

一度、私はまだ新しいReactとReduxを研究することに決めました...いいえ、すぐに始めるのは間違っています。まず、私の人生に少なくとも1つのゲームを追加し、プロジェクトを一般に保存したことについて：

テスト

実際、私は仕事の後の夜に書いており、もちろん毎日ではありませんが、1か月後でも何も覚えていないプロジェクトを開いて、静かに別の機能のコーディングを開始できました。 基本的に次のようにテストするので、ユニットテストを取得したかどうかはわかりません。

it('User0 creates Room, User1 logins', () => { const serverStore = mockServerStore(); //     mock,    ,    middleware const clientStore0 = mockClientStore().connect(serverStore); //   mock const clientStore1 = mockClientStore().connect(serverStore); //   clientStore0.dispatch(loginUserFormRequest('/test', 'User0', 'User0')); //    clientStore0.dispatch(roomCreateRequest()); const Room = serverStore.getState().get('rooms').first(); clientStore1.dispatch(loginUserFormRequest('/test', 'User1', 'User1')); expect(clientStore0.getState().get('room'), 'clientStore0.room').equal(Room.id); expect(clientStore0.getState().getIn(['rooms', Room.id]), 'clientStore0.rooms').equal(Room); expect(clientStore1.getState().get('room'), 'clientStore1.room').equal(null); expect(clientStore1.getState().getIn(['rooms', Room.id]), 'clientStore1.rooms').equal(Room); }); 

つまり、一方では最も孤立した機能をテストしようとしましたが、もう一方ではクライアントでアクションをディスパッチし、それ自体がサーバーに「送信」し、応答を受け取り、ルームの作成のみをチェックします。

ところで、あなたが気づいた場合-私のテストは同期的であり、socket.ioの同期モックのために動作します。 私はnpmでそのようなものを見つけられなかったので、自転車に乗りました。 いいえ、実際、これは非常に物議を醸す点です。なぜなら、プロジェクト全体も同期する必要があるからです。しかし、すべてのトマトについてKISSに答えます。 もちろん、非同期テスト（async / awaitを使用）にすべてを書き直そうとしましたが、クライアントのディスパッチはサーバーからの約束を与えなければならず、テストのためだけにネットワークミドルウェアをねじる必要があることに気付きましたが、どういうわけかすべてを変更したくありません。 ただし、理論的にはこれは可能です。

より高度なテストの例：

Predatorプロパティを持つクリーチャーがMimicryプロパティを持つクリーチャーを攻撃すると、可能であれば、同じプレイヤーの別のクリーチャーに攻撃をリダイレクトします。

 it('$A > $B m> $C', () => { //    A   B,     C const [{serverStore, ParseGame}, {clientStore0, User0, ClientGame0}, {clientStore1, User1, ClientGame1}] = mockGame(2); // mockGame( )          [{serverStore, ParseGame}, ...   ] // ParseGame     yml    ID' . //          . const gameId = ParseGame(` phase: 2 //   (      ) food: 10 //      = 10 ,   players: //   - continent: $A carn //   id "$A"   ,     TraitCarnivorous,    . - continent: $B mimicry, $C //   -   ID "$B"   ,     ID "$C". `); const {selectAnimal, selectTrait} = makeGameSelectors(serverStore.getState, gameId); //    reselect ( ),      expect(selectTrait(User1, 0, 0).type).equal('TraitMimicry'); //   ,                . //    ""    clientStore0.dispatch(traitActivateRequest('$A', 'TraitCarnivorous', '$B')); expect(selectAnimal(User0, 0).getFoodAndFat()).equal(2); //       expect(selectAnimal(User1, 0).id).equal('$B'); //    expect(selectAnimal(User1, 1)).undefined; //     =    . }); 

模倣のための7つのテストがあります：

Aは擬態でBを攻撃し、Cはカモフラージュで攻撃します（Bは攻撃が見えないためCにリダイレクトできず、AはBを食べます）

Aは模倣でBを攻撃し、Cのみ（上記の場合）

A（プレデター）、B（擬態）、C（擬態）：AはBを攻撃し、Bは攻撃をCにリダイレクトし、Cは攻撃をBにリダイレクトしますが、ゲームは無限サイクルに入りません、そしてAはBを食べます

A（捕食者）、B（擬態）、C、D：AはBを攻撃し、ゲームはプレイヤー2にどのクリーチャー（CまたはD）を生けlikeにしたいかを尋ねます。 彼はそのCに答え、AはCを食べる。

A（捕食者）、B（擬態）、C（擬態）、D：AはBを攻撃し、ゲームはプレイヤー2に、どのクリーチャー（CまたはD）を犠牲にしたいかを尋ねます。 彼は、Cが再び模倣することを返信し、ゲームは、今回、どのクリーチャー（BまたはD）を生けwillに捧げるのかをもう一度尋ねます。 プレイヤーはBと応答し、それは死にます。

A（捕食者）、B（擬態）、C、D：AはBを攻撃し、ゲームはプレイヤー2にどのクリーチャー（CまたはD）を生けlikeにしたいかを尋ねます。 しかし、彼は答えず、ゲーム自体が誰を殺すかを決定します。

前のものと同様ですが、1msの割り当てられた時間間隔に対してプレーヤーが責任を負わない非同期テスト 。 「プレイヤーが応答しなかった」として、私はawait new Promise(resolve => setTimeout(resolve, 1));を使用しますawait new Promise(resolve => setTimeout(resolve, 1));

そして最後のテストは、どうやら何らかのバグに関連しているようです：擬態を持つクリーチャーを探した後、新しいラウンドが始まることをチェックします。 理由は覚えていません。

なぜこれだけなのですか？ その上、私はどこかで私の模倣が正しく動作しないことを心配することはできません。 狩りや「質問」のロジック全体を書き直すことができ、テストでは 失敗した すべてが機能します。

したがって、ところで、詳細を確認しないでください。 Cが死亡した、Aが食物を受け取ったなど、有意な論理的結果のみ 一度、私はいくつかの隠されたパラメーターをチェックしようとしました（たとえば、プレーヤーには「いいね」というフラグがあります）。しかし、その結果、プレーヤーが再び似合わないことを確認し始めました。

私のプロジェクト、特に自宅のプロジェクトでは、テストでロジック全体をテストすることをお勧めします。 安定性の向上に加えて、プロジェクトへの復帰にも役立ちます。

クライアントテストについては別に-ここではすべてがそれほどバラ色ではないので、クライアントを頻繁に書き直し、4回目以降は書き込みを停止しました。

顧客とデザイン。

そして今、クライアントのゲームの部分は私にはまったく合わないが、私はこれ以上良いものを考えられない。 理想的には、「優れたデザインの古典的な原理と、技術と科学の革新と可能性を統合した」クールな「視覚的言語」を備えた「Material UI Hearthstone」を入手する必要があります。 はじめに 、ただし、Robotoが中央にある灰色の四角形が表示されました。 いいえ、実際、デザインはまったく私を動揺させませんが、「テーブル」自体、カード、食べ物、生き物がいる場所もあります。 そして、ここに完全な継ぎ目があります。すべての情報に対応できないという事実から始まり、逆説的に、私は多くの空きスペースがあるという事実で終わります。

ここに問題があります。まず、私は嫌なデザイナーであり、スタイルからは残忍なことを好みます。 第二に、私は怠け者です。 そして第三に、ゲーム自体に豚が入れられます-プレイヤーは1体または20体のクリーチャーを持つことができます。 また、1〜20個のプロパティを持つこともできます。 そして、プレイヤー自身-2から8まで。 そのため、数個のオブジェクトから数百個にスケールする正気なものを作る方法を想像することはできません。 「ボードゲームのような」という原則を備えた「ハースストーンのような」すべてのことを行うオプションは、おそらくここでは最良ではありません。

反応する

見た目はまあまあですが、動作します。これがReactとその決定論の大きなメリットです。

ハードMVC / MVVMの意志は必ずしも十分ではありませんが、Reactは外部のすべてのロジックを強制的に削除し、状態X（認識しやすい）でUIがこのようになるようにします。 誰かから読んだように、「Reactは状態を取得してUIを返す関数です」。 Reduxと併用することで、副作用と「確実性で満たされる」ことがなくなります。何が、どこで、いつ起こるかは確実です。 これは非常にクールです。加えて、jsxに嫌悪感を感じることはありません。逆に、{％< {{x | filter％sdfsdf}} >％}また、スコープを定義する必要はありません。 vueとangle 2でこれをどのように使用するかわかりませんが、最初は、これらのスコープです。 そして一般的には、借方記入する方が簡単です。

さて、ポータルなどのあらゆる種類の機能が私を直撃しました。 確かに、私は部屋のコンポーネントを書いています。その中のヘッダーに何かを広げてみませんか？ そこにプッシュしないでください。ただし、コンポーネント<PortalTarget name='header'/>そこに存在する場合のみ

 export class Room extends Component { ... render() { const {room, roomId, userId} = this.props; return (<div className='Room'> <Portal target='header'> <RoomControlGroup inRoom={true}/> // <=      Header' </Portal> <h1>{T.translate('App.Room.Room')} «{room.name}»</h1> <div className='flex-row'> <Card className='RoomSettings'> <CardText> <RoomSettings {...this.props}/> 

多言語主義はi18n-reactを介して行うのが最も便利であるように思えました。設計では、react-mdlを使用しています。 憎しみが散りばめられた愛の別の光線、私は反応したライブラリに送ります、それはクールです。

ただし、Reactにはマイナスのアニメーションがあります。 CSSトランジションよりも複雑なものは、それほど単純ではありません。 はい、状態は1であり、UIは異なるはずです。

怪物-AnimationServiceを生成して、この問題を嫌な方法で解決しました。 つまり、彼はミドルウェアをクライアントにポップし、すべてのアクションをキャッチして最初のアクションのアニメーションを開始し、残りをキューに入れ、アニメーションが完了するとすぐに次のアクションを起動します。 たとえば、カードがあなたの手の中に美しく飛んでいる間、ゲームを終了することができないという事実で、それは多くのバグを与えます。

一方、次のようなVelocity.jsを使用してコンポーネントをアニメーション化できます。

 export const createAnimationServiceConfig = () => ({ //     ,    animations: ({subscribe, getRef}) => { // subscribe -   Action, getRef -     //  : subscribe(" ", (done (    ), actionData, getState) => { //      ... 

実際、私はそれを無駄に書きましたが、このモンスターが便利になった唯一のアニメーションはカードの配布です（ただし、Hearthstone !! 11のように！）、それで十分です。

そのため、一般的に、Reactを使用すると、ほとんどすべてがうまくいきます。これは、主に彼が自分のビジネスに参入するのではなく、Reduxがロジックを扱うためです。

Redux

クライアントとサーバーの両方ですべての作業を行うのは彼です。 さらに、socket.ioのミドルウェアを介して互いに通信します。 私はある種のRPCを作成しました。これは次のように見えます（準備ができました。これでgame.jsから大量のコードが作成されます ）

 // Game Create // Request   ,    export const gameCreateRequest = (roomId, seed) => ({ type: 'gameCreateRequest' // ,     ,  , data: {roomId, seed} //   , meta: {server: true} // Middleware          }); //      ,    const gameCreateSuccess = (game) => ({ type: 'gameCreateSuccess' , data: {game} }); //   -   const gameCreateNotify = (roomId, gameId) => ({ type: 'gameCreateNotify' , data: {roomId, gameId} }); //    export const server$gameCreateSuccess = (game) => (dispatch, getState) => { //       Store dispatch(gameCreateSuccess(game)); //    Notify,    dispatch(Object.assign(gameCreateNotify(game.roomId, game.id) , {meta: {users: true}})); //       . selectPlayers4Sockets(getState, game.id).forEach(userId => { dispatch(Object.assign(gameCreateSuccess(game.toOthers(userId).toClient()) , {meta: {userId, clientOnly: true}})); }); //   ,           , ,       . //          - : // dispatch(Object.assign( // gameCreateSuccess(game.toOthers(null).toClient()) // , {meta: {clientOnly: true, users: selectPlayers4Sockets(getState, game.id)}} // )); //   .¯\(°_o)/¯ }; // ...  40  ... //    : export const gameClientToServer = { gameCreateRequest: ({roomId, seed = null}, {userId}) => (dispatch, getState) => { //   ,    ,   dispatch(server$gameCreateSuccess(game)); } // ... } export const gameServerToClient = { //   ,    gameCreateSuccess: (({game}, currentUserId) => (dispatch) => { dispatch(gameCreateSuccess(GameModelClient.fromServer(game, currentUserId))); dispatch(redirectTo('/game')); }) ... } 

gameClientToServerオブジェクトは、サーバーが受信できるアクションで構成されているため、「shutdownServer」タイプのアクションを直接送信することはできません。 そしてその逆は、単にJSONオブジェクトからいくつかのモデルまたは何かを実際にモデルに変換します。

次のように機能します。

1）ユーザーが「ゲームを開始」ボタンを押します。
2）React-reduxディスパッチgameCreateRequestアクション
3）クライアントミドルウェア：

 const nextResult = next(action); if (action.meta && action.meta.server) { action.meta.token = store.getState().getIn(['user', 'token']); socket.emit('action', action); } return nextResult; 

nextResultはテスト（同期であることを思い出します）に必要です。socket.emit（）の後にnext（アクション）を呼び出すと、クライアントレデューサーは後でサーバーから応答を送信するアクションを処理します。

4）サーバーがアクションを実行します。

 socket.on('action', (action) => { if (clientToServer[action.type]) { // clientToServer  ,    xxxClientToServer,   roomClientToServer  gameClientToServer const meta = {connectionId: socket.id} //    ActionCreator'  id . ,   . if (!~UNPROTECTED.indexOf(action.type)) { //       UNPROTECTED,    //   } const result = store.dispatch(clientToServer[action.type](action.data, meta)); //      gameClientToServer.gameCreateRequest    

5）上で書いたように、server $ gameCreateSuccessが呼び出され、gameCreateSuccessがサーバーにのみディスパッチされ、次にgameCreateNotifyとgameCreateSuccessが各プレーヤーにディスパッチされます。
6）レデューサーサーバーはgameCreateSuccessをキャッチし、ゲームを作成します
7）ミドルウェアサーバーはgameCreateNotifyをキャッチし、すべてのクライアントに送信します（そのため、そのような部屋でゲームが開始されたことがわかります）
8）また、次のgameCreateSuccess（各プレーヤーのゲームを含む）をキャッチし、サーバーReducerに送信させます（clientOnly：trueがメタで指定されているため）

それはどういうわけかそれはすべて動作します。

環境

無料アカウントのherokuappで動作します。 6時間のダウンタイムが必要なため、これはあまり良くありません。 ただし、半死者の出席（シベリアから3人の男が夜、平日にプレイすることもある）のため、これはあまり気にしません。

したがって、VC経由のログインがデータベースから読み取られるのではなく、毎回再度要求されることは気になりません。 もちろん、おもしろいです。プロジェクトがデータベースを使用するのに十分な規模になったと思ったら、mlab.comから無料のmongoをねじ込み、そこにVKトークンを書き込み、新しいトークンを要求します。 いいえ、いつかログイン時に統計情報とOauthトークンを要求することはありませんが、これまでのところ、データベースは完全に使い物になりません。

すべてのゲームの状態はreduxに直接保存されます。 どこかに自分の財産をデータベースに保存する悲観的な天才を見ましたが、個人的にはその理由がわかりません。 たぶん私は間違っています。

最初のwebpackに行きますが、2番目のwebpackはまだ残っていません。 開発では、クライアントはwebpackMiddlewareを経由し、サーバーはnodemon + babel-nodeを経由します。 唯一のマイナス点は、バックエンドを変更した場合、フロントエンドが再構築されるまで長時間待たなければならないことです。 ノードのホットリロードを試みましたが、どういうわけか機能しませんでした。 そして、なぜ、サーバーのテストをしています。

「非伝統的な」ロギングについて簡単に言及します-ファイルへの書き込みはオプションではありません。herokuがすべてを消去し、あらゆる種類の専門サービスが不便または有料であるため、winstonの素晴らしいモジュールwinston-google-spreadsheetを見つけました。 はい、彼はログをGoogleタグに書き込みます。 私は同じlogglyよりも好きです。

結論：

技術：

Reactは既に古くなっています（：trollface :)が、心は変わり、私の意見では、慣れる必要があります。
Reduxについても同じことが言えます。

同期テストは優れていますが、私はデスクトップまたはターンベースのゲームを非同期で約束通りに実行します。 つまり、送信-私は答えを待っていました。 そうすれば、サーバーはコールバックアクションを設定できないことに悩む必要がなくなります。

収集はMap'amiまたはオブジェクトによって行われる必要があります。 そもそも、KISS、動物をリストに保存できるのに、なぜ動物がいるオブジェクトが必要なのかと思いました。 その結果、game.getAnimalByIdは配列検索を実行します。 はい、間違いです。私は恥ずかしく思います。いつか書き直します。

人道的：

まず、デスクトップをオンラインで翻訳することは、ありがたい仕事です。 多くの微妙な点とルールがあるという意味で、ほんの数語でプレイヤー間で決定されることは、メガバイトのコード、リクエスト、松葉杖に変わります。 また、デスクトップゲーマーは、実行できない些細なことにも常に不満を抱いています。 さらに、常にマルチプレイヤーであり、ゲームプレイが長いため、プレイヤーはほとんどいません。

第二に-私は間違ったゲームを取りました。 進化の主な難しさとゲームプレイは、組み合わせとそれらの相互作用を計算することです。 コンピューターはそれ自体の計算ミスをすべて取り除き、ユーザーはいくつかのオプションからしか選択できません。 したがって、ゲームプレイは破壊されませんが、事前に考えておく必要があるため、悪名高い破壊されます。 まあ、著者のおかげで、彼らはすべてを逆さまにするアドオンに満足しています。 つまり、プレイヤーには動物がいる1つの「大陸」があり、その後3人がホップしました。 かっこいい！ おもしろい！ ゲームの半分を書き換えます、ええ、はい：D

要約すると、私は自分が欲しいものを手に入れました。 私の意見では、このコードは場所によっては美しくさえありますが、一般的には嫌ではありません（もちろんAnimationServiceを除く）。 ここでは、フォーク/プルリクエストの送信/開発のヘルプ/問題の投稿/ru-ru.jsonの英語への翻訳/デザインのヘルプ（これらはまだ微妙なヒントではありません）、あらゆる種類のヒップスターについて考えるすべてのことを言うことができます敬lyな卑劣な誤解に登るタラ。 私がPRに入らないように、コメントにサイトへのリンクをスローします。