
CSSの難しさの根源はセレクタにある。CSS設計のための方法論ではどのようにしてセレクタと関わるべきかについて語られる。 その関わり方がCSSのみで実現できなければならないという制約を捨てたのがいわゆるCSS in JSの類(定義的に微妙なやつも全部ひっくるめて)だ。可能性は一気に広がり無数のライブラリが生み出された。 ある程度の期間を経ていくつかの着目すべきアプローチが見えてきた。これから僕はどのようにセレクタと関わっていくべきかという視点で記してみたい。 擬似スコープ 通常CSSのセレクタにはスコープはないが、HTMLやCSSにハッシュ値を付与して特定のコンテキストを擬似的に閉じてしまおうというアイデア。実装としては、Vue.jsの単一ファイルコンポーネント、Angularのコンポーネントスタイル、styled-jsxなど。関連するウェブ標準技術としてShadow DOMがある。 例え
Editor’s note: This post has been updated on 26 August 2022 to update and improve information about data fetching with Redux and Axios, as well as to mention an additional simple option for fetching data using React Hooks. As many developers know, state management is one of the many issues you have to deal with while building robust applications. It can quickly grow into a nightmare, especially on
お付き合いのある株式会社エフコードさんの社内勉強会で発表するお仕事をさせていただいたのでそのまとめ。 お題目としては「なんかフロントについて話して」とふわっとボールをいただいて、さてどうしようかなーと色々考えた末に、フロントエンドの歴史についてという題目にしてみた。 比較的サーバーサイドどっぷりな人が多いのもあったので、なるべくライト気味に、とか色々考えてみて、フロントエンドへの恐怖感取れたら良いよなあと思ったというところ。 地味に外で話すということをやったことがほとんど無い人間なので、わりとがっつり練習した(多分スライドも喋りにあわせて作っているので、スライドだけ見てもあまり良い資料ではないかも) なんとなく大道芸人が興行に行くような気持ちだったと思う(大道芸人やったことないけど) 当日も手応えがある反応をいただけたのでよかった。 作ってみてどうだったか最初「いや、こんな老害みたいな話し
ブラウザはGUIアプリケーションプラットフォームではない Flexboxについて React DOMはGUIアプリケーションフレームワークではない React NativeはGUIアプリケーションプラットフォームの抽象である React Native for Webがブラウザに持ち込んだもの コンポーネントが便利 スタイル周りも良い感じ TouchableOpacityでタップ表現もラクラク 他にもいろいろあるけど プロダクション事例が強すぎる 作者のnecolasも語ってた まとめ 余談:React系のアプリケーションフレームワーク React Native for Webは、React NativeをWebに持ち込む試みです。 しばしば、こういった試みに対して「わけがわからない」「本末転倒である」といった意見を見かけますが、筆者は妥当な試みであるという印象を持っています。ちょっと頭の中
Stay Relevant and Grow Your Career in TechPremium ResultsPublish articles on SitePointDaily curated jobsLearning PathsDiscounts to dev toolsStart Free Trial7 Day Free Trial. Cancel Anytime. There can be no doubt that React has revolutionized the way we build user interfaces. It’s easy to learn and greatly facilitates creating reusable components that offer your site a consistent look and feel. How
はじめに 普段Reactを書いていて、Component化する必要があるのかどうかを迷うことがよくあったのでまとめたいと思います。 色々記事を見たのですがほとんど抽象的な記述で、「結局どうしたらいいの?」みたいに思うことが多かったので、自分のようにたくさんの記事やドキュメメントをきちんと読むのが面倒臭いと思う人でもでもわかるようにまとめていきます。 対象読者 React初心者 Componentに分けるタイミングがわからない人 タイミングをパターン化する Componentってこういう基準で分けるよねっていうのを抽象的にパターン化します。 パターン化することで、幅広いシチュエーションに耐えうる考え方になります。(最近自分はデザインパターンにハマってるのでパターンという言葉を使いたがると思いますがご了承ください。) 実際にComponentに分けるか考える時は以下のパターンが当てはまっていれ
最近ReactとVueをどっちも触る機会があったり、「ReactとVueどう選定するの?」という問いを投げられ、スッと答えられなかったな、と後悔があったりしていたので、Vueを触って得られた感想をまとめてみる。 結論としてなにか新しいことを発見したというものではなく、世間で言われている事を自分なりに再構築しただけの結論になったと思う。 TL; DRVueからは全体的に優しさ(Gentleさ)を感じる事が多く、良い点だと感じた大規模になるときReactの堅牢さは魅力的。Vueが大きくなった時に支えられ設計が出来るかは個人的には懐疑的。「こうだったらVue、こうだったらReact」みたいな分岐点があるというわけではないので、最終的には好みになってくると思う。ぞうさんが好きかきりんさんが好きか。これまでのフレームワーク遍歴今回の話をするにあたって、僕と各フレームワークの付き合いをまとめておくと、
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです!しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く