タダム！ （そして最後に面白い話）
tamtakoe.github.io/oi.select
まず第一に、私はAPIなし、サードパーティ製ライブラリなし、デザインなしを決定しました。 選択は、オートコンプリートと新しいオプションの作成の可能性がある場合にのみ、標準にできるだけ近づける必要があります。 APIは、Angular selectと互換性がある必要があり、Angular selectはHTML selectと互換性があります。 標準の外観はブラウザによって決定されるため、使用できませんでした。そのため、最も一般的なBootstrapをベースとして使用しました。 実際、新しいコンポーネントではなく、既存のコンポーネントの拡張であることが判明しました。
同僚が長い間できることをするために、新しい形式のパラメータを研究するように強制するのではなく、同僚の時間を大切にする必要があります。 コンポーネントから見慣れた外観と動作を期待するユーザーのスキルを考慮してください。 インターフェース要素を設計するときに開発者が最初にすべきことは、彼の中でデザイナーを殺すことです。 何とかしてデザインを作成するという意味ではなく、既存の動作を最大限に活用するために、最後の手段として追加し、最後の手段で変更します。
<option>
介してオプションを設定することを除いて、APIが完全に互換性を持つようになりました。 HTMLでは、他に方法がないため、このメソッドが使用されます。 Angularには、互換性のためにこの方法が残されたコントローラーとモデルがあります。 私はそのような互換性をするのが面倒でした。 たぶんいつか...
当初、このようなコンポーネントを作成する方法は3つありました。DOM操作を使用した純粋なJSへの実装など、Angular selectディレクティブの拡張、主にAngularでの実装です。 なぜなら 私は頭の中でそのような決定を下すほど頭が良くないので、次の3つの方法すべてを取り入れて実装しました。
- 最も魅力的なのは、Angularとの類推によってselectを記述することです。 純粋なJS、最大のパフォーマンス、すべてを制御します。 しかし、これを行うのは簡単ではありませんでした：あまりにも多くのニュアンス、Angularの知識が最低レベルで必要であり、Angularが内部で実現する多くのコピー＆ペースト機能です。 その結果、これはすべての結果を伴う数千行のコードに分類されます。 単純なコンポーネントには適していますが、私はこのベンチャーを拒否しました。
- ディレクティブ定義オブジェクトディレクティブでAngularのselectを使用できます。 それを拡張したり、メソッドを再定義したりするために。それは良いように聞こえますが、実際にはあまりにも過酷であることが判明しました。 それでも、Angularはそのコンポーネント、特にディレクティブを（残念ながら）拡張する機会をまだ提供していないため、JSツールで拡張することにより、内部実装に縛られ、後方互換性を失うリスクがあります。 このメソッドは、 Angular-bootstrap popoverなど、開発者が拡張機能を提供するディレクティブで使用できます。
- Angularの手段の実装は、よりシンプルで視覚的になりました。
ng-options
からパラメーターを解析するための正規表現のみをコピーペーストしng-options
。 コードは純粋なJSよりも単純であり、Angular選択の内部構造に関する知識は必要ありません。 パフォーマンスは良好です（私はこれが最も恐れていました）。 この方法は、ほとんどのコンポーネントの実装に適していると思います。
APIとの互換性にもかかわらず、十分な固有のパラメーターがあります。 そこではすべてがスムーズで明白ではないと信じているので、コメントのコメントを喜んでいます。 入力行から新しい要素を作成するには、多くのことが当てはまります。 いくつかの分析の後、プロンプトで入力フィールドを使用する場合が2つあるという結論に達しました。
-
prompt
-フィールドは通常の入力のように機能し、プロンプトはリストに表示されるだけです。 Enterキーを押すと、フィールドの値がモデルに入ります。 フィールドをクリアすると、モデルの文字列が空になります。 この動作は、検索フォームの特徴です。
-
autocomplete
-フィールドはオプション付きのリストとして機能します。 Enterを押すと、リストの最初のオプションがモデルに入り、何もなかった場合にのみ、内容が入力フィールドになります。 モデルに空の文字列を書き込むことはできません。 この動作は、タグ入力フォームの典型的なものです。
別の論争点：カスタムデザインオプション。 標準コンポーネント（Angular、ブートストラップさえ）には、そのようなものはありません。 しかし、誰もが望んでいます。 妥協の決断に至りました-すべての人とすべての人にフィルターをサポートすることです。 もちろん、HTMLをJSで記述する必要がありますが、テンプレートサポートに煩わされるよりも速度が速く、はるかに簡単です（リストアイテムのテンプレートの種類は何ですか？）。 しかし、いつか...
そして今、写真なしのテキストのページを圧倒するための約束された面白い話 。
あるバージョンでは、Web部門の開発者が誰も再現できないバグがありました。 しかし、残りのスタッフ：マネージャー、アナリスト、テスター、1Cプログラマーはいずれにせよ複製されました。 涙が出ました-あるコンピューターでは、常にリストからアイテムを選択する人もいれば、どんなに一生懸命にしようとする人もいます。 このプロパティは、人を雇うときに使用できると思います。 悪いプログラマーはテストに失敗します。 あなた自身とあなたをテストしてください、読者 。