ESFフロントエンドの閉じたドアの後ろ

この記事では、Unified Frontal System（ESF）のコンポーネントのライブラリと、プラットフォームのフロントエンドの一般的な配置について説明します。



ESFプログラムの主な目的の1つは、すべてのフロントシステムを単一の技術スタックに変換することです。 ここでのフロントエンドシステムは、ユーザーが銀行とやり取りするためのインターフェイスです。 それはインターネット銀行である可能性があります-多くの人がビジネス向けのSberbank OnlineとSberbank Onlineのアプリケーションを知っています-ATM、端末、支店やコールセンターのオペレーターインターフェイス、ロシアの何千もの顧客や銀行員が使用するその他のシステム。

私たちが解決する主な問題は、古いコードの置き換えです。多くのフロントエンドシステムが銀行にあり、それぞれが独自のアーキテクチャと独自の設計を備えています。

明らかに、これは誰にとっても不便です。顧客、従業員、銀行全体にとっては不便です。
したがって、ESFフロントエンドの主な使命は、既存のhodgepodgeを置き換えて、すべてを単一のコードベースに、便利で理解しやすいユーザーシナリオで単一の技術スタックにまとめることです。

開発が直面している課題は何ですか？

• 信頼性とセキュリティ。これは、銀行ソフトウェアについて話しているからです。
  
  
• 耐障害性。 ここに99.99％などの数値が表示されます。これは、システムを一時停止できるときの年間約52分です。
  
  
• ユーザーのさまざまな社会人口統計カテゴリの利便性。 インターフェイスは、経験豊富な銀行員と初心者の両方で、上級ユーザーと祖母の両方にとって明確でなければなりません。 均一性と標準化により、ロシア全土の何千人もの従業員のトレーニングにかかる​​時間を大幅に節約できると付け加えました。
  
  
• 作業と実装の速度、いわゆる市場投入までの時間。

EFS時代の前に、新しい技術製品を市場に投入するまでの期間は最大1年でした。 ESFを使用して、市場投入までの時間を1か月に短縮するタスクを設定しました。
そして、これはほんの始まりです！

フロントエンドはESFでどのように配置されていますか？

ESFプラットフォームの開発者チームと、ビジネスロジックの実装をタスクとするアプリケーション開発者がいます。

プラットフォームチームは、内部使用のためのUIコンポーネントのライブラリを開発しています。 そのような開発のかなりの例があります-Google、Yandex、Avito、Mail.ruなどの企業にもコンポーネントライブラリがあります。 応用プロジェクトチームはこのライブラリを使用してプロジェクトを実装し、問題が発生した場合にフィードバックを提供します。
プラットフォームチームには現在8人がいます。 私たちは2週間のスプリントで作業し、それぞれの最後に、修正と、場合によっては新しいコンポーネントを含むライブラリの新しいバージョンをリリースします。 もちろん、コードレビューと独自のコードスタイルがあります。最高のプログラミング手法を採用し、自分たちに合わせて調整しました。

ツールキットとして、アトラシアンのツールセットを使用します。タスクの設定にはJIRA、gitリポジトリにはBitBucket、ドキュメントにはConfluenceを使用します。

ライブラリは何で構成されていますか？

• さまざまなUI要素：さまざまな種類の選択、ボタン、さまざまなデータ型のさまざまなフィールド、チェックボックス、ラジオボタン、およびユーザーが操作する他のフォーム要素。
  
  
  
  
• ボタンやヘッダーのあるテーブルやパネルなど、情報を表示する方法
  
  
  
  
  
  
• グリッド。 Bootstrapがどのように実装したかを見て、目的に合ったものを作成しました。 グリッドによると、コンポーネントはフォーム上に構築されます。
  
  
• コンポーネントビューの添付。 オペレーターが添付ファイルを操作するために役立ちます。たとえば、領収書のズームインや回転を行います。
  
  
• ファイルアップロードコンポーネント
  
  
• React-applicationsの非同期ロード用のコンポーネント：多くのビジネスプロセスがあり、それらを個別のReact-applicationsに分割します。これらは、あるプロセスから別のプロセスへの移行中にロードされます。
  
  
  

ブラウザのサポート

ターゲットブラウザはIE8 +です。 今ではIE8は、覚えているなら、かつてIE6のようでした。ひどいAPIとひどいデバッグです。 もちろん、IE8でデバッグに費やす時間は貴重です。 IE8のデバッグ用ツールは非常に貧弱であり、エラーがまったく別の場所で発生したことを示すことがあるため、開発者がエラーが発生した場所を見つけるために数日間を費やすケースがありました。

IEのサポートは偶発的なものではなく、RFIDタブレット、さまざまなプリンター、スキャナーなどのブラウザーのハードウェアを使用する必要があります。 Webにはハードウェアを操作するための単一の標準がありません。遠い昔、ActiveXはそれを操作するためのテクノロジーとして選択されていました。 ActiveXを使用して記述されたソフトウェアの量は膨大であり、これによりIEサポートを一夜にして放棄し、最新のブラウザーに切り替えることはできません。 計画には、レガシーActiveXをJavaアプレットに転送し、IE8を放棄することが含まれます。

技術スタック

私たちは大規模な組織内の一種のスタートアップであり、フロントエンドテクノロジーのスタックは、ほとんどのグローバルスタートアップ（react、redux、PostCSS）とそれほど変わりません。 これらの技術はすべてその価値を証明しており、さらにIE8をサポートすることもできます。 ただし、テクノロジースタックを劇的に変更することはできません。 特定のアプリケーションアーキテクチャが関連付けられています。たとえば、1つの巨大なアプリケーションを何百もの小さなアプリケーションに分割し、SystemJSを使用してオンデマンドで読み込むことができたのはReactでした。

反応する

これは、次の理由で選択した最初のテクノロジーです。

1. アプリケーションをコンポーネントに分割して、コンポーネントアプローチを開発に編成できます。
   
   
2. 簡単に習得できます-新しい同僚にReactを知ってもらう必要はありません。プロジェクトを理解するのに数日を与えるだけです。
   
   
3. IE8サポート。 実際、IE8をサポートしているフレームワークとライブラリを見ると、それらが非常に少ないことが判明したため、これから始めることができました。 最も人気のあるもの-Angular、Ember、Vue.js-はサポートしていないため、Reactでラッキーでした。

また、開発プロセス中に、React Nativeの実験を開始しました。これにより、UIコンポーネントのクロスプラットフォームライブラリをリリースできました。 それについては、 最初の記事で読むことができます。

どのようにしてReactとIE8を友達にしたのですか？

第一に、ある時点からIE8のサポートを拒否したため、Reactのバージョンを更新していません。 次に、es3ifyを使用します。これはwebpackのローダーであり、ES5コードを取得してES3に渡します。 IE8が機能しないものを置き換えるだけです。

TypeScript

私たちが選んだ2番目のテクノロジーはTypeScriptでした。

1. 強い型付け
   私たちの基準では、タイプanyは禁止されていますが、ルールには例外があります。 すべてのものからはほど遠く、generic'amiでカバーできます。
   
   
2. 誰にでもできる
   私たちは皆人間であり、時には間違った型を使用し、間違ったデータを渡し、コンパイラは単純で理解可能なエラーを表示します。
   
   
3. アプリケーション開発者との利便性
   上記のように、ライブラリをアプリケーション開発者に転送します。 それらの多くもTypeScriptを使用しており、コンパイル段階でコンポーネントを正しく操作する方法を理解しています。

ライブラリには約70のコンポーネントがあります。 開発を最初に開始したとき、すべてのコンポーネントは「スマート」でした。つまり、コンポーネントには状態が含まれており、すべてのロジックは内部にありました。 特定の問題は発生していません。 しかし、コンポーネントがより複雑になるとすぐに、それらは互いに投資し始め、それらの多くがありました。パフォーマンスの問題がまだあることに気付きました。どのようにそれらを解決したかを説明します。

性能

まず、コンポーネントを「ダム」にした、つまり状態を取り除き、アプリケーションレベルにしました。 現在、アプリケーション開発者は状態の変更方法を決定し、必要な小道具はコンポーネントにのみ転送されます。

例を挙げましょう：

export default class Input extends React.Component<Props, State> {    static defaultProps: Props = {        value: ''    }    state: State = {        value: this.props.value    }    handleChange = event => {        const value = event.nativeEvent.target.value;        this.setState(prevState => ({value}))        this.props.onChange(value);    };    render() {        return <input onChange={this.handleChange}                      value={this.state.value} />;    } } 

ライブラリコンポーネントInputがあり、状態に値が保存され、レンダリングでは入力を返し、onChangeでは状態を変更します。 そのようなコンポーネントには多くのコードがありますか？ 間違いなくたくさん、この例をリファクタリングしましょう：

 export default class Input extends React.Component<Props, {}> {   static defaultProps: Props = {       value: ''   }   handleChange = event =>       this.props.onChange(event.nativeEvent.target.value);   render() {       return <input onChange={this.handleChange}                     value={this.props.value} />;   } } 

コンポーネントコードが短くなり、上記のレベルで、コンポーネントの状態を管理する方法を決定するFormコンポーネントがあります：reduxまたは最も単純なsetStateを介して。 入力がよりシンプルになり、それに応じて生産性が向上しました。

第二に、純粋なコンポーネント（PureComponent）のアーキテクチャ、つまり すべての外部プロパティ、内部状態、およびコンテキストは、以前の状態に準拠しているかどうかチェックされます。 状態が変更されていない場合は、もう一度renderを呼び出しても意味がありません。 すべてのコンポーネントに追加されたshouldComponentUpdateメソッドでこのチェックを実行します。

そして第三に、コールバックのメモリリークを取り除きました。

 export default class Button extends React.Component<Props, {}> {   render() {       return (           <button onClick={event => this.props.onClick(event)}>               {this.props.children}           </button>       );   } } 

この例では、コンポーネントにonClickコールバックがあり、矢印関数が渡されます。
このように設定すると、リークが発生します。 IE8では、この関数がレンダリングされるたびに呼び出されるたびにこの関数が作成され、コンポーネントに蓄積されてブレーキが発生するため、特に表示されます。 サンプルを少し変更しましょう。

 export default class Button extends React.Component<Props, {}> {   handleClick = event => this.props.onClick(event);   render() {       return (           <button onClick={this.handleClick}>               {this.props.children}           </button>       );   } } 

コード自体はより簡潔になりました。さらに、コールバック関数はレンダリングの呼び出しごとに作成されなくなったため、リークを取り除きました。

将来の計画には、IE8のサポートの中止が含まれます。これにより、より高度なフロントエンドテクノロジーの使用が可能になります。 さらに、すでにESFモバイルプラットフォームとの大規模な統合プロジェクトの作業を開始しており、React Nativeを使用してWebとモバイルデバイスの両方に同じコードを使用できるハイブリッドライブラリの開発を開始しています。

ESFプログラムのフロントエンドに関する次の記事では、Reduxの使用方法とReduxがアーキテクチャの中心となった方法について説明します。見逃さないようにブログを購読してください！

アイデア、提案、提案-書いて、記事へのコメントであなたとチャットできることを嬉しく思います。