デリー-短縮、またはモバイル2GISオンラインの方法

モバイルWebは飛躍的に発展しています。 2017年の庭で。 モバイルトラフィックがデスクトップを超えました 。現在、全ページの半分以上が電話またはタブレットで開かれています。 Google は 2015年に、ランキングの発行時にモバイルフレンドリーサイトを優先することを発表し 、2016年にはYandex がそれを行いました。 ユーザーは、モバイルデバイスからインターネット上で月に60〜70時間を費やし、非適応サイトを侵害して使用する準備ができていません。 また、2GISも例外ではありません。 2年間で2GIS Onlineモバイルトラフィックの増加は74％に達し、月間視聴者は600万人を超えました。

4月17日に、 m.2gis.ruで利用可能な1ページのアプリケーションである新しいモバイルオンライン（「Monline」）を開始しました。 このアプリケーションは、ウファとノボシビルスクの2つの都市で開始され、近い将来、ロシア全体でのリリースが計画されています。

モバイル開発では、次の3つの問題に直面することがわかっていました。

モバイルインターネット

モバイルインターネット（2G、3G、4G）またはWi-Fiは低速で、ケーブルほど安定していません。

モバイル機器

携帯電話の問題は、プロセッサが弱いことです。 これは、JSの解析、レンダリング、およびアニメーションに影響します。

モバイルブラウザ

一部の一般的なモバイルブラウザは、一部のCSSプロパティまたはJS APIメソッドをサポートしていません。 IE8の開発の暗黒時代に戻ったと思うこともありました。 モバイルインターネットとプロセッサは、ポリファイルの使用を許可しませんでした。つまり、自分で出なければなりませんでした。

デスクトップオンラインバージョンの機能を保持し、ペンザ近くの祖父の死んだ電話でもMonlineを動作させました。 これについては以下で説明します。

デリー-削減

モバイルWebの世界では、JS開発者は1つのモットー、Delhi-Cutに従います。 モバイルアプリケーションの最終的なバンドルは、少し重くて細かく分割する必要があります。

フレームワークとライブラリの選択

メインで唯一のフロントエンドフレームワークはPreactです。 これはタイプミスではありません。 Preactは、同じAPIを使用し、仮想DOMで動作するReactの軽量の代替です。 このフレームワークの利点は、その軽量性（3 kB gzip対45 kB for React）と高いレンダリング速度です。 Reactの代わりにPreactを使用することにより、ベンダーのサイズが90％削減されました。

PreactはReactとは異なります。 たとえば、propTypeがありませんが、この問題は静的型付けを導入することで解決しました。これについてはセクション3で説明します。フレームワーク間の違いの詳細は、公式のgithubリポジトリに記載されています。

さらに、私たちは自分で書いて、サードパーティの親友と重いライブラリを接続しないようにします。 必要なポリファイルはrequire.ensureを介して非同期にロードされ、バンドルに分類されません。 各ポリフィルは、条件に応じてのみ接続されます。 たとえば、Androidブラウザ用のpolyfilの場合、gzipで5 kBのコードを保存しました。

遅延読み込み

JSが形成されます。 今、それを破る時間です。 JSコードは3つのグループに分けられます。

• ベンダー-サードパーティライブラリ。
• メインアプリケーションコードを保存するアプリバンドル。
• ブラウザのバージョンなどの条件に応じて接続されるライブラリとポリファイル。

ベンダーはPreactを選択することで最小化され、必要に応じて非同期で多フィルを接続します。 最後のヒーローが残った。 gzipでgzip圧縮された143キロバイトのアプリバンドル。 モバイル開発には贅沢です。 そのため、ユーザーが組織のカードにログインしている場合、メトロカードまたはアトラクションのレンダリングを担当するコードを即座に読み込むことは意味がありません。 アプリバンドルのサイズを縮小し、できるだけ少ないコードをクライアントに配信するために、遅延ダウンロードを行いました。

Montlineのコード番号1の要件には、「コードはできるだけ単純で、知らないことややりすぎないことが必要です。」 UI構造は、このルールに基づいています。 プロジェクトには11個のコンテナと85個の「ダム」コンポーネントがあります。 愚かなコンポーネントはお互いを知りません。 コンテナはコンポーネントを構造に結合し、小道具を介してデータを送信します。 組織または失効カード、建物の発行-コンテナの例。 11個のコンテナのうち6個は相互に接続されていないため、アプリバンドルを...陰謀... 6個の追加チャンクに分割できます。 リカバリ中に、ブラウザはアプリバンドルと目的のチャンクをロードし、その後、非アクティブなコンテナーを担当する残りのJSファイルが非同期にロードされます。 これはアプリケーションをブロックしません。 遅延読み込みのリリース後、アプリバンドルの重量は38％減少しました。

クライアントでのデータの保存と正規化

モバイルウェブでは、ページをすばやく表示することが重要です。 99.9％SPAのように、Montlineでは、コンテナ内の情報の一部が交差しています。 企業の発行と別の組織のカードを受け取ります。 問題には、見出し、住所、スケジュールなどが表示されます。同じ情報が会社のカードに表示されます。 ユーザーがアプリケーションを使用している間、そのような情報は変わりません。 ユーザーが過去にこの情報を既に表示している場合、サーバーからの応答を待つことは意味がありません。これは、クライアントに1つのコピーで保存し、ここでデータを表示できるためです。

クライアント上のデータの正規化とは、コンテナ内で再利用されるスタック内の一意のデータの保存です。 クライアントにデータを保存すると、コンテンツの表示速度が向上し、正規化により重複が削除され、静的データと状況依存データが分離されます。

正規化は状態をクリーンに保ちます。 静的データが表示される場合、それは別のテーブルの記事に保存されます。 たとえば、ユーザーが1つの会社を複数回開いた場合、ストーリー内ではIDによるアクセス権を持つ1つのインスタンスに格納されます。 この会社に関する情報は、組織のカード、問題、レビュー、写真など、あらゆるニーズに使用されます。コンテナセレクターは、データのフォーマットを担当します。

もう1つの例を示します。 検索クエリを介して会社のカードにアクセスするか、セクションをクリックするか、単にそのIDのリンクから回復することができます。 検索クエリまたはカテゴリIDは、回復中にルーターが解析するURLに追加されます。 URLに会社のID以外のものがある場合、州は、その情報と、検索クエリまたはカテゴリに一致する最初の10社のデータを保存します。 会社のカードから発行に切り替えると、ユーザーはすぐに組織のリストを受け取り、各会社のページをすばやく開くことができます。

人々は、コンテンツのダウンロードだけでなく、フォームを介してデータを送信する際の応答も待ちたくない。 クライアントにデータを保存すると、情報を保存する際の待ち時間が短縮されます。 ストーリー内の情報は、楽観的なインターフェイスを自由に作成できます。 楽観的なUIデザインは、アプリケーションが実際に操作を完了する（または開始する）前の最終状態を示します。 データを送信すると、ユーザー情報はクラスに保存され、バックグラウンドでサーバーに送信されるため、ユーザーはストレージに関する情報を即座に受信します。 サーバーからエラー応答を受信した場合にのみ、アプリケーションは対応するメッセージでユーザーに通知します。それ以外の場合、サーバーの応答は表示されません。

自分で簡単に

34人の開発者がMontlineの作成に参加しました。 2,000件のコミットがマスターにマージされ、77,000行のコードが書き込まれ、1,425個のファイルが作成されました。 このプロジェクトには他のチームの人々が参加し、彼らはインターンシップに参加しました。 コードを理解しやすく文書化するために、開発プロセスをスピードアップしたかったのです。 そのため、JavaScriptでの動的型付けを放棄することにしました。

静的型付け

アプリケーションのクライアント部分は、TypeScriptで記述されています。 静的型付けは、JSに対するTypeScriptの主な利点です。 コンパイルエラーが発生した場合に手を振って、内部からコードを文書化し、リファクタリングとデバッグを容易にします。

プロジェクトはReduxを使用して、アプリケーションの状態を制御します。 ReduxはTypeScriptと組み合わせます。 開発者は、ペイロードまたはメタに転送されるものと、それに応じてリデューサーに送られるものを知っています。 例：

export const setScrollTop = (payload: number) => ({ type: APPCONTEXT_CHANGE_SCROLL_TOP, payload }); export const setErrorToFrame = (errorCode: ErrorCodeType) => ({ type: APPCONTEXT_SET_ERROR_TO_FRAME, payload: { errorCode } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TypeScriptを使用すると、reducer（状態の新しいバージョンを計算して返す純粋な関数）を簡単に操作できます。 たとえば、記事内の現在のアプリケーションコンテキストに関する情報を更新するレデューサーは、69個のアクションを処理します。 出力では、新しい状態を返す100行のコードのスイッチを持つメソッドを取得します。 このような大きなキャンバスでは、必要なアクションのみを処理することが重要です。

 export default function (state: AppContext = defaultState, action: AppAction): AppContext { switch (action.type) { case APPCONTEXT_ADD_FRAME: return appAddFrame(state, action.payload); case APPCONTEXT_REMOVE_ACTIVE_FRAME: return appRemoveActiveFrame(state); .... case APPCONTEXT_HIDE_MENU: return { ...state, isSideMenuShown: false }; default: return state;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Discriminated Unionsは、reducerの一連のアクションとペイロードまたはメタのデータとの混乱を避けるのに役立ちます。 上記のコードは、アクション引数が次のようなAppActionタイプで記述されていることを示しています。

 export type AppAction = AppAddFrameAction | AppRemoveActiveFrame | AppChangeFramePos | AppChangeMode | AppChangeLandscape…
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AppActionは60個のインターフェース（appAddFrameAction、AppRemoveActiveFrameなど）を組み合わせます。 各インターフェースはアクションを記述します。 アクションのタイプ-文字列リテラル-は判別式です。 ペイロードやメタなど、オブジェクトの内部の存在と内容を決定します。

 export interface AppAddFrameAction { type: 'APPCONTEXT_ADD_FRAME'; payload: Frame; } export interface AppRemoveActiveFrame { type: 'APPCONTEXT_REMOVE_ACTIVE_FRAME'; } export interface AppChangeFramePos { type: 'APPCONTEXT_CHANGE_FRAME_POS'; payload: FramePos; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、TypeScriptは、判別式 'APPCONTEXT_ADD_FRAME'を使用したアクションの場合、ペイロードをフレームインターフェイスで転送する必要があり、 'APPCONTEXT_REMOVE_ACTIVE_FRAME'の場合、何も送信する必要がないことを理解しています。

また、PreactはTypeScriptと組み合わせます。 Preactには、コンポーネントのタイプチェックの問題を解決するリアクションpropTypeがありません。 しかし、TypeScriptはその損失を補います。 たとえば、開発者は、小道具を介してコンポーネントに送信されるものと、スタックに保存されるものを知っています。

 export interface IconProps { icon: SVGIcon; width?: number; height?: number; color?: string; className?: string; } export class Icon extends React.PureComponent<IconProps, {}> { constructor(props: IconProps) { super(props); } public render() { const { color, icon } = this.props; const iconStyle = color ? { color: this.props.color } : undefined; return ( <svg width={this.props.width || icon.width} height={this.props.height || icon.height} style={iconStyle} className={this.props.className}> <use xlinkHref={icon.id} /> </svg> ); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TypeScriptは文書化されており、サンドボックスがあります。 もちろん、言語は全能ではありません、2017年7月の時点で、2,200の問題が開かれました。 マイクロソフト製品は、ES6の革新の一部をサポートしていません。 しかし、これらの問題は新しいリリースごとにゆっくりと確実に解決されます。

レイアウトの作成とテスト

モバイルオンライン-85の「愚かな」コンポーネント。 「愚かな」コンポーネントは、受信したデータの表示を担当する視覚的なエンティティです。 まず、アプリケーション内でこれらのコンポーネントのレイアウトと統合を分離したかったのです。 これにより、開発者リソースによるコードのレビューとテストが高速化されます。 これらの目標を達成するために、メイクアップが使用されます。



構成-レイアウトの迅速かつ快適な手動回帰テストのためのグラフィカルインターフェイス。 このツールの詳細についてはこちらをご覧になり、 こちらをタップしてください 。

Makeupを使用すると、コンポーネントのレイアウトは、アプリケーションに関連付けられることなく、ロックされたデータを持つ別のホストで実行されます。 これにより、開発レベルでコンポーネントの視覚化をテストし、ピクセルパーフェクトにレイアウトをカスタマイズし、後で統合することができます。

そのため、Makeupでは、デザイナーが描いたものと開発者がしたことの間に違いがあります。

そして、 「11年生」をチェックして、何も行かないことを確認します。

おわりに

まとめると。 バンドルを減らし、ページの読み込み速度を上げるという素晴らしい仕事をしました。 データはクライアントに保存されます。 ベンダーの重量は、当初よりも90％少なくなりました。 バンドルには不必要なライブラリーとポリフィルが含まれておらず、必要なものは必要に応じて断片的に提供されます。 TypeScriptを使用すると、アプリケーションをより細かく制御できます。また、Makeupは、Monlineのビジュアルコンポーネントでの作業を簡素化します。

計画は、コンテキストに応じて「太字」モジュールを分割し（たとえば、会社または地理オブジェクトカードを個別のチャンクに分割する）、レデューサーを分割しようとします。

この記事はJSコードに関するものです。 しかし、Delhi-Reduceの開発信条はCSSバンドルにまで及びます。 将来的には、スタイルを分割することも計画しています。