読者です 読者をやめる 読者になる 読者になる

natsumican's blog

Tech & Music

Inside Frontend # 1 に参加してきました。

先日行われたInside Frontend #1にブログ絶対書く人枠として参加してまいりました。 (年度末的なごにょごにょで遅くなってしまったことを心よりお詫び申し上げます…🙇)

このブログではいくつかのセッションについての内容や、個人的な感想について述べていきたいと思います。

会場の雰囲気等 、他のブログ書くマンさんの記事もとても参考になるので是非そちらの方も御覧ください…!

資料 & Blog等

また、セミナーA、Bのセッションに関しては下記にて視聴できる模様です。

Inside Frontend #1 Seminar A

Inside Frontend #1 Seminar B

多様化する利用環境とどう向き合うか

福本 翔さんによる利用環境の多様化についてのおはなし。

利用環境とは

利用者、利用機器、コンテキストの組み合わせ。それぞれ、障害者やお年寄り、デバイスやブラウザ、運転中や音の出せない状況などを指す。

マルチデバイス対応について

利用環境に応じて「使いやすい」プロダクトの状態は変わってくる。しかし多様な環境全てに対応するのは難しいので、全体最適化の後個別最適化を図る。

アクセシビリティオブジェクト

取得されたコンテンツはアクセシビリティオブジェクトへ変換され、アクセシビリティAPIを通じて支援技術(読み上げ機能等)に渡される。どのような情報を渡すのかというと、

  • DOMツリーとレンダーツリーの組み合わせ
  • 名前や役割や状態など(HTMLやWAI-ARIA)
  • 位置や大きさなど見た目の情報

因みにWAI-ARIAとは、role属性による役割付与や、aria-*による状態特性付与など、HTMLで不足している情報を補うことができる属性のこと。このような情報をもとにアクセシビリティオブジェクトは作られる。

まとめ

まずは全体最適化を優先し、後に個別に環境対応を行う。APIが適切な処理を行えるようにマシンリーダビリティを向上させよう。

所感

以前から気になっていたWebフロントにおけるアクセシビリティについて。

フロントエンドはユーザーと直接触れ合うインターフェイス部分であり、突然のデバイス普及による利用者・利用環境の多様化など、制御することのできないパラダイムシフトと常に向き合っていかなければならないと分野であると考えています。

そのなかで、実際にどのようにアクセシビリティオブジェクトがつくられ、支援技術に渡されているのか。その仕組について理解することにより、今後構造や属性の意味合いをより意識しながら開発したいきたいです。

直後に行われたAMAの内容も非常に興味深かったので、ぜひこちらの方も御覧ください。 AMA:C1 アクセシビリティ

Web フロントエンドにおけるコンポーネント化のアプローチ

@1000chさんによるWebフロントエンドにおけるコンポーネントのおはなし

コンポーネント化とは?

ソフトウェア的な再利用性・汎用性を持たせつつ、UIにおいても見た目や挙動等レイアウトに統一性を持たせること

例えばボタンで例えると、 文言の差し替えが容易に出来るようになっていたり(ソフトウェア的な再利用性・汎用性) hoverした時のインタラクションを統一する(UIの統一性) といった感じでしょうか。

コンポーネントの管理にいて

デザイナーとエンジニアどちらが管理するのか?という問題。どちらか一方が管理することが多い。しかしそれだと上手くまわらない。どちらも責任を持つ必要がある。

HTML + CSSによるコンポーネント

Cascading Style Sheetという名の通り全てがグローバル定義でありスコープの無いCSS。設計手法としては主に命名規則でなんとかするしかない。 しかし、そもそもCSS設計を工夫してもデザイン次第で破綻するので、エンジニアはデザインを、デザイナーは実装を理解する。

CSS ModulesとCSS in JS

とはいえやはりスコープは欲しい。JavaScriptのオブジェクトリテラル形式でCSSを記述したファイル(CSS in JS)をスタイルを適用したいコンポーネントにimportすることにより、コンポーネント毎に一意なハッシュが自動生成されクラス名に付与されるので、結果ローカルスコープを手に入れることができる。(CSS Modules)

まとめ

デザイナーとエンジニアどちらがやるのか?ではなく、職能同士が歩み寄ることが重要。説得する際は自分の都合だけでなくきちんと相手におけるメリットを提示すること。デザインシステム(Atomic Design等)の導入。

所感

昨今のWebフロントエンド開発において役割分担の曖昧さは悩みどころだったので、非常に勉強になりました。

また個人的には、スタイルはコンポーネントごとに閉じ込め、状態管理をFluxライブラリで奪い取る。そのようなキレイな世界で生きていきたいでスッ・・・😇

Refactoring CSS: 管理されたカオスへの道のり

@cssradarさんと@hilokiさんによるCSSリファクタリングのおはなし。

CSSにおけるリファクタリングとは

リファクタリングとは、ソフトウェアの外部的振る舞いを変えることなく、より保守性・拡張性の高いコードへ書き換える作業のこと。しかし、CSSだとなかなか実施しづらい。それには以下の問題があげられる

  • UIの変遷が速い
  • 影響範囲が広い
  • テストを書くことが難しい

リファクタリング手法

プログラミングにおけるリファクタリングと、表現言語であるCSSでは異なる部分もでてくる。が、基本的に手法は同じ。

タイミングとしては機能実装前・バグ修正時等。もしくは常にやるくらいの気持ち。 CSSにおける、マジックナンバー(謎の27pxとか)や!importantなどはやはり良くない。 命名規則の導入は新しくデザインが刷新されるタイミングで。スタイルガイドはあくまで見た目の振る舞いを確認するもので、コードについては触れられていない。そこについてはドキュメントを残そう。

また、元のコードは消さず、セレクタに対してRF_*でリファクタリングは残しておく。具体的には

リファクタリングをしている時は消さない、リファクタリングが終わったら消す。rf_ のネーミングごと消す。

2つの帽子をかぶり分ける、開発とリファクタのモードを変えていかないといけない。機能追加とリファクタを同時にすると事故る。

リファクタリングで「コードを消さない」と負債にならないか? / CSS Evolution #56より

まとめ

表現言語であるCSSにおけるリファクタリングは可能だがなかなか大変。 リファクタリングのしやすい環境・習慣をつくろう。

所感

リファクタリングを試みるも、あまりの影響範囲の予測しづらさに悪戦苦闘することが多いCSS…今回のセッションを拝聴して、是非取り入れてみようと思いました!また、AMAの以下の質問について、

CSS Modulesについてどう思ってますか? / CSS Evolution #56

SPAプロダクトではにおいては是非使いたい…スコープ欲しい…と思ったりもするのですが、そもそもきちんと設計できていれば必要のないモノというのは、確かにそうだよなぁ…と思います。

個人的には、スコープある方がより直観的に書けて良い気がしなくもないのですが、しかしそれはもう本質的にCSSのような何かであってCSSではないと思うので、このあたりでstyle sheet言語として乖離が始まる気もします…CSSの今後が気になるところです。

AMAブースについて

今回のイベントでは、セッションの合間に登壇者の方が事前にGithubue上で募集した質問や、その場で出た質問に答えていくAMAブースが設けられました。 ここから質問&回答が見れます。鮮度の高い情報を得られるのはとても有難かったです🙏

参加してみて

あまりの楽しさに適宜休憩をアナウンスされているにも関わらず、どのセッションも聞き漏らすまいと必死になった結果、無事死亡しました…次回は頑張って任意休憩します…😇

運営スタッフ様、登壇者様、お疲れ様でした…! 次回も楽しみにしております!