【天勝金創】Reactコンポーネント開発をどう思いますか

Autoellipsisから見たReactコンポーネント開発
Autoellipsisは、テキストの超長オーバーフローの遮断を解決し、...のReactコンポーネントです.
Reactについて
Reactが熱くなるにつれて、マイナスのニュースも多くなりました.以前からネット上ではReactの鼓吹者が多く、『無脳』と定性的に定められていたが、これは当時jQueryを批判したようなものだ.
Reactは私にとって、フロントエンドのViewライブラリだけでなく、私に与える影響は主に以下のいくつかの面があります.

最先端技術を抱擁-babelは私にプロジェクトの中でES 2015+を事前に使用することができます;Webpack-dev-serverとreact-hot-loaderは私の開発過程をスムーズにしました.Webpackは私のパッケージのオンラインを極めて便利にしました.reduxはアプリケーションの状態をよりよく管理することができます.これらはReactと絶対的な関係はないと言うかもしれませんが、実際にはReactの巨大な生態圏の活力が私にこれらの最先端技術に触れて抱擁することができます.

SPAの開発を楽しんでいます-私は前にAngularを試したことがありますが、Reactこそ私に適しています.私は自分でSPAの開発を実践することができ、関連技術を探求することに興味があります(例えば、universal appsを構築します).

コンポーネント化思想-Reactはコンポーネント化を本当に開発に用いることができ、実践の中でコンポーネント化思想をより深く体得することができる.

フロントエンド開発の思考:Fluxの一方向データストリームの思想,FRPを指導思想とするRedux.これらはすべて私に索の先端開発を考えさせます.

次にauto-ellipsisの開発過程を紹介します.
CSSのellipsis

.truncate { width: 250px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; }

正直に言うと、CSSのellipsisはほとんど満足していません.

単一行のみを対象とします.しかし、実際には、指定された幅の広い領域で自動的に遮断され、加算されることが多い.

titleなどのプロンプト情報を生成できません.ユーザーがレビュー要素から完全なテキスト情報を取得することを期待することはできません.

現在、auto-ellipsisはCSSで優雅に実現することはほとんどできない.しかし、この需要はもともと純粋なスタイルの問題ではないことをよく考えてみましょう.適応的に切断するだけでなくまた、コンポーネントにカプセル化できる機能要件であるtooltip or title(tooltip or title)も望ましい.
実装方法
CSSが実現できない以上、JSに頼るしかない.最も簡単な考えは、後ろから前へ絶えずテキストを裁断し、テキストがオーバーフローしているかどうかを確認し、オーバーフローしないと、私たちはこのプロセスを終了します.を考慮すると、このプロセスは主に2つの部分に分けられます.

テキストの切り取り:divノードのtextノードを直接暴力的に置き換える(

content

->

conten

);

テキストがオーバーフローしているかどうかをチェックします:私が最初に考えたのはdiv要素の外にdivをセットして、外層div overflow:hiddenを設定して、内層divoverflow:visible、外層divは幅を決めて高くして、このように内外層要素の高さあるいはビューポートに対するbottomを比較すればいいです.

明らかに上の方法は有効だが、極めて暴力的だ.まず1つのdivを複数セットすると不快になるので、textノードもdomであることに気づき、divノードとtextノードを比較できますか?残念ながらtextノードはその高さと位置情報を取得できません.
このとき、『JavaScriptプレミアムプログラミング』にRangeという概念が紹介されているのを覚えているかもしれません.正直、私はその時あまり感じませんでした.はい、Rangeが役に立ちました.
Rangeはdomオブジェクトに属し、ノードの境界を考慮することなくドキュメント内の領域を選択できます.私たちはRangeによってテキストの切り取りを実現することができます(テキストノードを暴力的に置き換えるよりも効率的です).Rangeの高さと位置情報が取得でき、getBoundingClientRect()でビューポートに対するdivノードとRangeのbottomを取得し、位置比較を行うことができます.さらに、Rangeの作成はユーザに対して透過的であり、これは、トリミングチェックのプロセスUI全体が変化しないことを意味する.
div要素のpadding-buttomとborder-bottom-widthを考慮する最適化もできます.一致テキストから3文字を減算して保存...;word-breakを考慮し、最終テキストをスペースに切り取る(中国語など他の言語を考慮すると、実現しにくい...).
Reactコンポーネントのパッケージング
まず,コンポーネントの属性propsはコンポーネントの対外インタフェースである.Autoellipsisの場合、外部インタフェースにはtag(コンポーネントのラベル)、content(テキスト情報)、addTitle(切断時にtitleプロパティを追加するかどうか)、styles(カスタムスタイル)が含まれます.
次に、コンポーネントの状態stateは時間とともに変化し、一般的にベースコンポーネント(dumb component)は状態に関係なく、上位ビジネスコンポーネント(smart component)が状態を管理することが望ましい.通常、コンポーネントの状態の変化はユーザインタラクションによって生じるので、コンポーネントは、ユーザインタラクションが終了した後に対応する処理インタフェース(例えばhandleClick)を露出するだけでよい.
Autoellipsisでは、ほとんどユーザーと対話していません(要素幅がパーセンテージなどの定値でない場合、ビューポートのサイズの変化は影響しますが、ここでは考慮しません).実際にはDOMの直接的な操作が多いのですが、コンポーネントを再レンダリングするにはいつ、テキストを再クリップする必要がありますか?
Reactはコンポーネントのライフサイクルの管理に非常に強力で、私たちはどのようにするのが適切かを考えるだけです.まず、コンポーネントの初期化マウントが終了したときに(componentDidMount、DOMを操作可能)テキストを切り取ってみる必要があります.次に、コンポーネントの更新時に、コンポーネントの更新が完了した後(componentDidUpdate、DOMを操作可能)テキストを切り取ってみる必要があります.最後に、shouldComponentUpdateを使用するかどうかを検討する必要があります.これは主にパフォーマンスの考慮に基づいています.基礎コンポーネントについては、この3つの点を考慮すれば十分だと思います.より複雑な設計は、コンポーネントをそんなに汎用的ではなく、潜在的なバグを導入するだけです.実際、ほとんどの場合、仮想DOMはすぐに使用されるため、インフラストラクチャはshouldComponentUpdateでも使用されません.しかしauto-ellipsisは比較的特殊で,その更新のたびにDOMを再操作する必要があるため,最適化を考慮することができる.

shouldComponentUpdate(nextProps, nextState) { return JSON.stringify(this.props) !== JSON.stringify(nextProps)
}

CSS modules
CSSモジュール化はコンポーネントパッケージの難題である.Webpack(style-loader,css-loader)は、JS module loaderを使用してCSSをロードする機能を提供します.しかし、これはリソースの宣言依存とロードだけで、CSSモジュール化ではありません.CSSのモジュール化を解決するには、CSSの局所的な役割ドメインの問題を解決しなければならない.CSSモジュールの入出力.
css-modulesは、唯一のclassNameを生成することによって、CSSローカル役割ドメインの問題をエンジニアリングの観点から解決しました.css-modulesの入出力はすべてJSオブジェクトで、このオブジェクトは一連のlocal-className:global-classNameのマッピングです(注:入出力にはグローバルスタイルは含まれていません.css-loader?modulesでデフォルトのローカルスタイルを開くことができます.globalの先頭はグローバルスタイルです).CSSモジュール間はcomposesで組み合わせる.
React-css-modulesは、high-order componentがプレビューをクリックすることによってcss-modulesをReact componentに自然に適用し、styleNameとclassNameを使用してlocal CSSとglobal CSSを区別する.react-css-modulesにカスタムコンポーネントのスタイルを解決するためのPRを提案しました.スタイルの宣言順序(importコンポーネント、importカスタムCSSモジュール)によって、同じセレクタの下でカスタムスタイルがより優先されることを確認します(css-loader?modules&localIdentName=[local]-[hash:base 64:5]を使用すると、[local]でlocal-classNameを識別でき、スタイルをカスタマイズできます).注意:PRは通過していません.著者らは、一部のhackは、最終的にはコンポーネントにstyles属性を渡すことができると考えていますが、デフォルトのstylesを直接置き換えることにすぎません.では、デフォルトのstylesに基づいていくつかのスタイルを変更したい場合は、css-modulesで処理する必要があります.このセクションでは、ディスカッションを参照してください.

import React from 'react' import ReactDOM from 'react-dom' import CSSModules from 'react-css-modules' import styles from './auto-ellipsis.css' @CSSModules(styles) export default class AutoEllipsis extends React.Component { static propTypes = { tag: React.PropTypes.string, content: React.PropTypes.string.isRequired, addTitle: React.PropTypes.bool, styles: React.PropTypes.object,
    }
    render() { const props = { styleName: 'root',
        } const {tag, content} = this.props return React.createElement(tag, props, content)
    }
}

CSSモジュール化とCSS局在化については、haxのフロントエンド開発における「モジュール」と「コンポーネント」の概念についての考え方を具体的に参考にすることができる.
テスト
フロントエンドコンポーネントのテストは、ホストによって一般的にブラウザ環境とノードに分けられる.js環境.フレームワークをテストするなら、mochaをお勧めします.
ブラウザ環境は実際にDOMを生成し、実際に有効であることをテストすることができます.Webpackを使用してmocha-loaderと連携し、テストと開発を統一することができます.しかし、travis-ciなどの統合ツールの使用は不便です.
Node.js環境ではDOM(jsdom)をシミュレートする必要があり、Reactコンポーネントではreact-addons-test-utilsと組み合わせて使用できます.さらに、domの場所に関連するコンポーネントの中には、シミュレーションテストを使用できないものもあります(例えば、jsdomのgetBoundingClientRectが返すのは0).
Autoellipsisは明らかにdom位置情報に依存するため,ブラウザ環境テストを採用した.
プロジェクトのアドレス:https://github.com/ideal-react/auto-ellipsis .