Vue Fes Japan 2018 の 1年間単体テストを書き続けた現場から送る Vue Component のテスト https://vuefes.jp/
説明用の図 例として、amakan anime のトップページ https://anime.amakan.net/ の構造を挙げながら説明する。(ところで amakan anime は今月中に完成予定のサービスで実験的に公開している状態なので、まだまだ至らないところが多々あります…) 登場するコンポーネント一覧 React.Component クラスを継承したクラスをコンポーネントと呼ぶ。主に登場するコンポーネントは以下の通り。 Header Layout Router VideoPrograms Router コンポーネント 最上位のコンポーネントとして、Router コンポーネントが存在する。このコンポーネントを利用して、ページごとにどのコンポーネントを表示すべきかを分岐させる。amakan anime のトップページでは VideoPrograms コンポーネントを描画し、amaka
Angularでコンポーネントとアプリを分離して開発していて、そのコンポーネントの開発で依存関係逆転の原則(Dependency Inversion Principle)を使うといい具合にコンポーネントを定義できるのではないかと気づきました。いいかもしれないし悪いかもしれないのでいろいろご意見いただけたらうれしいです 前提 どんなAngular開発の現場でもメリットがあるわけではなく、以下の前提を想定します。 規模が割りと大きい 全体を整えるために記述がある程度冗長になっても許される コンポーネントとアプリケーションを分離している フォルダ単位とか、コンポーネントを別ライブラリにしているなど ビジネスロジックとコンポーネントが混ざるのを防ぐためとか、コンポーネントを複数のプロダクトで共有するとか 単純な実装 Todoを扱うようなコンポーネントをAngularで作るときに、一番単純に作るとこ
エンジニアの id:t930 です。 freee Developers Advent Calendar 2017 19日目いきます。 React はその名前を聞くようになってから3年以上が経過し、Webアプリケーション開発の文脈においてはもはや枯れた技術と言えるでしょう。会計freeeでも2015年ごろに Backbone.js から React へのリプレースを行い、現在では Reactコンポーネントだけでも900近いファイルが存在しています。当然このような規模でやっているとリファクタリングも必要になってくるわけで、本記事ではそんな中で得られたReactコンポーネントにおけるリファクタリングの指針について紹介していきます。1 適切な単位に分割する React に限った話ではないですが、巨大で見通しの悪いコンポーネントはメンテナビリティや再利用性の低下を招きます。表示領域、責務、意味付けに
チームでコンポーネントを構築する : 開発者間でコンポーネントの一貫性を保つための、シンプルな練習問題 コンポーネントは 素晴らしい ものです。 HTML と JavaScript と CSS を、再利用もテストも可能なコードのパッケージとしてカプセル化できます。 コンポーネントにまつわる一つの問題として、 独断的 になりうる、ということが挙げられます。私が「これはコンポーネントだ」と分類するものが他の人にとっては違うこともありますし、逆もまた然りです。 チームで仕事をするときは、 意見 と 知識 を共有することが大事です。それでは、チームでコンポーネントを構築する場合、意見が一致しているかを確認するためにはどうすればよいでしょうか? この投稿では、私たちがアプリケーションをコンポーネントに分解するときの思考プロセスを辿り、自分たちの考えと周囲の開発者たちの考えのギャップをどのように埋めて
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
この記事はドワンゴ AdventCalendar 2017の17日目の記事です。 dwangoアドベントカレンダー17日目を担当させていただきます @ln-north です。デザイナーとして2016年度新卒として入社し、もうすぐ2年になります。 エンジニアさんで埋められるカレンダーの中、ひっそりとデザイナーも参加させていただきます、どうぞお手柔らかに…。 はじめに ここ何年かのWebフロントエンド界隈の動きは非常に大きくそして速く、デザイナーから見ても様々なパラダイムシフトが起こっています。scssやwebpackからHTML5やCSS3まで…本当に大変ですよね。 特に最近はReactやVueなど、 コンポーネント指向 のWebシステム開発が発展を遂げています。Web Componentsなども含め、流れを見てるとおそらくWebはこのコンポーネント指向に向かい、しばらく進んでいくのだろうと
Update 2018: I cowrote LearnStorybook.com, a free 9 chapter tutorial on getting started with Storybook. Read the announcement » Storybook is a Component Explorer — a tool for working on a single component in isolation — built for React and React Native. As of this article, it’s likely the most popular and fullest featured component explorer out there. The team here at Chroma, along with others at
はじめに こんにちは。はてなブログとエモい話が何よりもすきな17新卒のエンジニアPotato4dです。 ひょんなことからこのpixiv insideに技術的な記事を書く機会に恵まれたので、JavaScript周りの話を書きたいと思います。 概要 モダンなJavaScript環境に慣れ親しんだ方には、「コンポーネント」という単位をベースとしたUIやロジックの開発を行う事は珍しくないかと思います。 しかしながら、その「コンポーネント」という単位の大きさと分割指標については、中々まとまった資料が存在せず、それぞれの開発者や、フレームワークによりけりとなっている印象を受けます。 昨今のフロントエンド開発、特に全てJavaScriptで完結するSPA開発で頭の悩ませる部分としては、状態の管理に次ぐ、大きな課題となっているのではないでしょうか。 今回の記事では、そんなJavaScriptにおける「コン
Rebass React primitive UI components built with Styled SystemStart your design system without boiling the oceanBuild consistent UI with design constraints and user-defined scalesBest-in-class developer ergonomics with Styled System propsFirst-class support for theming & fully compatible with Theme UIQuick, mobile-first responsive styles with array-based syntaxFlexbox layout with the Box and Flex c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く