ホームページ >ウェブフロントエンド >htmlチュートリアル >ネイティブHTML_html/css_WEB-ITnoseをベースとしたUIコンポーネント開発
この記事は冷静かつ率直なバージョンです。情熱的で思慮深いバージョンを見たい場合は、ISUX 公式ブログ「トレンドに従い、HTML 開発と UI コンポーネント設計の進化」にアクセスし、メッセージを残してください。
上記のデモでは、通常の静的ページに入ると、内部の UI がシステムのデフォルトであり、HTML 関数もネイティブです。
例:
例:
その結果、上記の元のラフなインターフェイスは、瞬時に次のように変わりました:
みにくいアヒルの子は、次のように変わりました。以前のネイティブ HTML 関数を含むホワイト スワン。
例:
最も素晴らしいことは : CSS と UI コンポーネント JS をいくつか導入しました。はい、そうです。以前のビジネス JS には触れずに、導入と少しの初期化だけを行いました。ただし、以前のさまざまなインタラクティブ機能はまったく影響を受けず、エクスペリエンスが 2 つのレベルに向上しました。
以下の gif スクリーンショットのデモをご覧ください:
ここでの UI コンポーネントがビジネス関連の JavaScript から完全に分離でき、同時にシームレスに接続できる理由。それは、デザインコンセプトがネイティブ HTML に基づいており、UI コンポーネントが本来の役割である UI に戻ることができるからです。
2. ネイティブ HTML に基づいた UI コンポーネントの開発
1. UI コンポーネント開発はなぜネイティブ HTML に基づいて行うことができるのですか?
HTML に付属するネイティブ UI パフォーマンスの多くは、基本的に UI コンポーネントの UI パフォーマンスと似ています。唯一の違いは、外観の粗さと洗練さです。
たとえば、タイトル プロンプトを考えてみましょう。ブラウザはデフォルトで次のような title 属性を使用します:
デザイナーによって設計されたヒントコンポーネントは、次のような Xiaohei スタイルです:
この 2 つは実際には同じものであり、機能も同じです。唯一の違いは - UI です。したがって、ネイティブのタイトル属性に基づいてヒント効果を完全に実装できます。同じ本質を活かして、変わるのは見た目だけ。
別のもっと興味深い例、フォーム検証を見てみましょう。 HTML5 では、フォームには、タイプ、必須、パターン、最大、最小などの HTML ネイティブ属性に基づく検証がデフォルトで組み込まれており、独自の UI が付属しています (下の図は、Win 環境での Chrome の効果です) 、他のシステム上の他のブラウザは異なって見えます):
下の図は、チームが採用することを決定した UI フォームです:
同様に、検証の本質は似ており、対話の形式も似ています。違いは UI です。したがって、フォーム検証効果を実装するネイティブ HTML ルールに基づいて完全に検証できます。同じ本質を活かして、変わるのは見た目だけ。
他の多くの UI コンポーネントも同様です。
変えたいのが見た目だけの場合、前の魂を再利用するのが最も合理的な戦略ではないでしょうか?
2. ネイティブ HTML に基づいて UI コンポーネントを開発するにはどうすればよいですか?
主要なポイントは 2 つあります: ① API パラメーターは HTML から直接取得されます。 ② コールバックはネイティブ イベントを直接トリガーします。
日付ピッカー、主流の実装は基本的に次のようになります:
<input id="date" type="text">
new DatePicker($("#date"), { type: "date", initDate: .., beginDate: .., endDate: .., onSelected: $.noop});
API パラメーター、イベント コールバックはすべて JS パラメーターから派生します。
HTML 指向の設計コンセプトに基づく実装は次のとおりです:
<input type="date" min="2015-11-11" max="2015-12-31">
new DateTime($("[type=date]");API パラメーターはすべて HTML から取得され、JS コードは単なるグローバル初期化 (すべての時間コントロールを一度にカバー) です。 HTML の type 属性は JS の type API に対応し、value 属性の値は initDate 値に対応し、min / max は beginDate / endDate にそれぞれ対応します。onSelected コールバックについては、ネイティブの変更時間を通じて実装されます。トリガー入力ボックス。
そのため、他のフロントエンド パートナーが開発するときに、ネイティブ HTML 属性とイベントに従って開発できるため、ビジネス JS と UI コンポーネント間のシームレスな接続をコストゼロで実現できます。
1. 语义化,可访问性
毕竟是基于原生HTML来开发的,这一块必定杠杠的。
2. 更低的学习成本
不需要记住千差万别的JS API名称,记住标准的HTML5属性即可,反过来对一些前端开发同学的HTML学习还起到了帮助作用。
而学习成本低对于跨团队合作非常有帮助。其他团队同学乐于使用你的东西,介入快,实现效果好,大家都开心。反之,API千差万别,每次使用都要去翻文档,肯定影响合作。
不过,实践下来,有一点学习成本我没考虑到,就是转换思维方式的学习成本。实际上只要面向元素的HTML元素开发就可以了,但是有遇到小伙伴,还是按照老的思维方式,在生成的UI组件元素上做文章。
3. 专注HTML控件本身,而不是组件
举个例子,日期选择器,当日期修改了,我们要干嘛干嘛,直接:
$("input").change(function() {});
想要修改日期范围,直接:
$("input").attr({ "min": "2015-12-27", "max": "2016-12-27"});
UI组件会自动同步。没有任何组件相关的JS代码,也没有什么故弄玄虚,没有所谓的高屋建瓴,全是很简单基础的HTML操作。是不是这样的开发反而很省心,连小白用户也能上手?
于是乎,在多团队联合协作开发的时候,前端开发的进度并不会受UI组件开发影响,面向HTML,专心自身业务开发就可以了。
于是乎,实现了一个听上去很了不得的东西: 前端分离 。
不仅如此,厂子里有很多开发,负责内部项目,会写JS擅长业务功能实现,但是,UI这块是个软肋。OK,此时,我们这里面向HTML开发的UI组件体系就是其救星,对吧,直接引入CSS和JS,简单全局初始化一下(可能还有一些简单的微调),结果,页面立马高大上了,是不是很有用!
4. 可以一次性全局处理
传统实现,每个具体业务的脚本里面要参与UI组件的具体API参数设置。而面向HTML的实现,API落地与具体的业务页面,于是乎,只要在项目的common.js中全局初始化一下,如下拉 Select.init() , 具体的业务JS文件(绝大多数情况下)中就无需再出现UI组件相关的JS代码。
UI层的JS代码和业务层JS代码分离,实现进一步的「前端分离」,去耦合。对于日后的维护、升级等必定大有裨益。
本文主讲设计思想,至于具体的技术细节,以后有机会会慢慢分享。越是简单的成品越是需要足够的积累。
然而,现在的我再重新评估UI组件的实现,还是有一些遗憾的,主要遗憾在于,HTML层→数据层→展现层这三层概念实现的时候并没有理得很清楚。目前,HTML层和展现层没有任何问题,但是,数据层,并没有完整贯穿整个UI组件体系,导致,本UI组件体系不能很好地吸引对JSON数据有着偏执爱好的开发,以及应付潜在的极端需求。
不过,不要担心,明年,也就是16年,我会对组件设计进一步增强,首先,不考虑IE7浏览器,于是可以做的事情就更多了;其次,清晰的数据层作为中间层的代码重构等。
以上,希望本文的内容能够对大家有一点启示。
相关文章