アメブロ: Isomprhicアプリケーションのパフォーマンス・チューニングFrontrend Vol.10 - 夏の終わりに納涼パフォーマンス話 https://frontrend.connpass.com/event/63971/ https://freshlive.tv/tech-conference/151511 アメブロ: Isomprhicアプリケーション…
React + RxJSで始める状態管理 - CARTA TECH BLOG
こんにちは、fluctの@nekoyaです。 今日は現在開発に携わっている、俗に言う「管理画面」のWebアプリケーションのアーキテクチャをご紹介します。 このアプリケーションはReactとRxJSを軸として作られており、コードはTypeScriptを使って書いています。 アプリケーションを流れるデータと状態の管理について、Write StackとRead Stackという考え方を取り入れたところ、いろいろなメリットが得られたので、そのあたりを軸に掘り下げてみます。 全体の大まかな構成 各Stackの前に、まずはアプリケーション全体の構成をざっくりと見ておきます。 流れとしては、DispatcherからWrite Stack, Read Stackを通ってStateが生成され、それをViewが受け取るという構成になっています。 全体の流れとしてはFluxっぽい何かのひとつのあり方なのですが、
コンポーネント時代のi18n
サービスを海外展開したい場合、国際化対応を行う必要性がある。これをi18n対応と呼ぶ。Reactでフロントエンドを構築する場合、i18nのための多くのライブラリがあるが、yahoo製の react-intl が実質デファクトスタンダードだ。react-intlを実際に使っている例として、スター14000超えのReactボイラープレートであるreact-boilerplate やSNSの マストドン がある。 しかし、実際にreact-intlを使うとidの管理が非常に面倒であることがわかる(他すべてのi18nライブラリも同様だが)。react-boilerplateを参考にidの管理を見てみる。 まず、react-boilerplateでは、ディレクトリベースでコンポーネントを管理している。その中で、messages.jsにdefineMessagesを使いidとデフォルトメッセージを定義
もうReactのフォームで消耗したくないので、HoCベースのフォームライブラリを作った - wadackel.me
2017 年。React のフォームに消耗しました。 いくつか良さそうなフォームライブラリはありますが、個人的に満足のいくものが無かったので、とあるプロジェクトで実装したものをベースにしてライブラリにまとめました。 作ったもの react-drip-form という、HoC ベースで React のフォームコンポーネントを構築するライブラリを作りました。元となるコードを書いている時、「さくっとフォームの実装を済ませてゆっくりコーヒーでも飲みてぇ…」という気持ちがかなり高まってたので、コーヒーを連想させる名前にしてみました。 wadackel/react-drip-form https://github.com/wadackel/react-drip-form ドキュメントのページでは、Create React App を使った Quick Start もあるので、さくっと試すことが出来ると
さいきんReact, Reduxでやっている設計 - しゅみは人間の分析です
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
JetBrainsのWeb UIコンポーネントをオープンソース化 | Post Blog
Ring UIを発表します。Ring UIはオープンソースのWeb UIコンポーネントです！ JetBrainsは何年にも渡ってRing UI ライブラリを開発してきており、複雑なUIコントロールを提供します。Ring UIは50を超えるReactコントロールからなり、シンプルなリンクやボタンに始まり、デートピッカーやデータリストといった洗練されたコントロールまで揃っています。 このライブラリはYouTrak、Hub、Upsourceをはじめとする製品でフル活用されています。そしてJetBrainsはこのライブラリを今後も引き続きメンテナンスしていくことにコミットします。 Ring UIライブラリを使う場面として一つあげられるのがHubのダッシュボードに組み込みカスタムウィジェットの開発です。Ring UIを使うことでお馴染みのJetBrainsのインターフェースに馴染みます。是非クイック
JavaScriptフレームワーク選定の議論 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか？ ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか？ 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在の
You Need to know SSR - Speaker Deck
ng-japan で発表した Server Side Rendering の資料です。
やっぱりサーバーサイドレンダリングなんかしなくていいやという気持ち - console.lealog();
個人の意見 aka ポエムです。 界隈的には今さら感がすごいけど。 そんな今さらポエった事情としては、 とある案件でSPAをReactで作りつつサーバーサイドレンダリング（以下SSR）をすることになるかも SPAじゃないページもまとめてReactでSSRすることになるかも ただ個人的にはSPA+SSR不要論者 サーバーサイドのテンプレートとしてのReactも冗長なだけやろ派 でも仕事なのでしゃーない（お客様がそう申されるなら・・ なのでやるからには再考察してみて、前向きにやれる要素を見つけたい！ けどどんだけ考えてもやっぱり意義が見つけられなーい( ´Д｀)=3 という感じで、SSR自体の是非はまあどうでもよくて、ただ個人的に「しなくていい」と思ってる気持ちをまとめたものです。 技術に是も非もないです。大事なのはどう使うかなのです。 ちなみにやってみた結果・・とかいう話ではなく、やってない
FluxとDDDの統合方法 - かとじゅんの技術日誌
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何？ まず基礎ということで、Flux i
フロントエンドの未来の話 - Qiita
const fsbx = require('fuse-box'); const fuseBox = fsbx.FuseBox.init({ homeDir: 'src/', sourcemaps : true, outFile: './dist/app.js', plugins: [ [ fsbx.SassPlugin({ outputStyle: 'compressed' }), fsbx.CSSPlugin({}) ], fsbx.TypeScriptHelpers(), fsbx.JSONPlugin(), fsbx.HTMLPlugin({ useDefault: false }) ] }); fuseBox.devServer('>main.ts **/*.html', { port: 4445 }); シンプル！！ fuse-boxの特徴として ・TypeScriptはデフォル
Webサイト開発にCSS in JavaScriptを使うのはやめよう | POSTD
9つのおとぎ話 CSSは迷走しています。JavaScriptでドキュメントをスタイリングしているプロジェクトでは、多くの場合誤った理由からその方式を選択しています。本稿では、よくある誤解（神話）を列挙し、そうした問題に対するCSSソリューションを紹介します。 本稿は、特定のプロジェクトや人物への攻撃を意図するものではありません。ここでは、“CSS in JavaScript”(CSS in JS)を styled-components を使用することと定義します。これは、Reactのコンポーネントをスタイリングする最近のトレンドとなっています。 styled-components の作者である Max Stoiber と Glen Maddern 、また彼らに協力した人々は皆、卓越したアイデアと善意にあふれる優秀な人々です。 完全な透明性のために断っておくと、私は react-css-mo
JavaScript(ES2015&React)で画像を扱う：リサイズとプレビュー表示 - dackdive's blog
はじめに web サイト／アプリケーションで画像のアップロード機能などを実装する場合、 最近のスマホのカメラで撮影した画像はサイズが数 MB にも及ぶので、あらかじめクライアント側で送信可能なサイズまで縮小する必要があります。 今回はそのような画像のリサイズの実装方法を整理しつつ、サンプルコードを React で書いてみます。 冒頭に画像のリサイズについて色々書いてますが、結論としては便利なライブラリでよしなにやってくれるので実装方法だけ知りたい場合は読み飛ばしてください。 JavaScript で画像を扱う際の基本 まず、JavaScript で画像ファイルを扱うにあたっての非常に基本的な話。 <input type="file"> 要素で選択した画像ファイルのデータを取得し、プレビュー表示するには以下のようにします。 class ImagePreviewer extends React
アメブロ2016 ~ Isomorphic JavaScriptの詳しい話 | CyberAgent Developers Blog
問題点はIsomorphic実装難易度です。では、アメブロのIsomorphicの実装方法と実装する際にあった問題及びその解決策をお伝えします。 ちなみに、Michael Jackson氏はIsomorphic JavaScript ではなく、 Universal JavaScript と呼ぶべきだと主張しています。私たちはIsomorphic JavaScriptという名前で使うのに慣れたので、ここでは*Isomorphic JavaScriptと記述します。 AmebloのIsomorphic 技術選定 先に結論をあげます：React + Redux 技術選定の基準は下記となります。 安定さ。基本的にプロダクト環境で使える正式版があること。 アクティブな開発。 よいコミュニティ。技術の周りに大きいコミュニティが育っていること。 実績がある。 まずView層のライブラリの選定です。このプ
redux-thunkなのかredux-promiseなのかredux-sagaなのか、それともredux#bindActionCreatorsをやめるのか - Qiita
前提 ここで書くのはあくまで個人的な意見です。 react, reduxはどちらも使い方次第でフレームワークっぽくも使えるし、ただのツールとしても使える。だからreact, reduxを使ったフロントアーキテクチャはいくらでもあっていいと思う。 これはそのうちの一つを提案するものです。 とはいえ特別な実装方式を編み出したわけでは全然なくて、むしろ１周して出戻りしたかんじ。 結論 非同期処理をコンテナ(またはそこで使うモジュール)に書くだけ。 今は、非同期処理をするためのredux middlewareを使ってないです。 過去記事(react, redux周りのパッケージ選定とKPT[2016-05-27現在])にて、この辺についてもなんやかんやと言っているけど、今はthunkもpromiseもsagaも使っていない。その実装が凄くシンプルで気に入ってるので紹介します。 どうやるのか red
あのスタートアップ企業がReactをフロントエンド開発に選んだ理由
乱立するフレームワーク／ライブラリーをどう選ぶか？ あるスタートアップ企業がフロントエンド開発フレームワークを選択するプロセスをケーススタディとして紹介。 シンガポールを拠点とした福利厚生サービスを提供するスタートアップ「CXAグループ」（日本版編注：CNETの記事を参照）のコアWebプラットホームを評価するにあたって、時代遅れとなった既存のアーキテクチャをお払い箱にすることにし、イチからフロントエンドを再構築することにしました。課題は、CXAグループが進出しているアジアにある12の対象国のどこでも機能するWebアプリケーションの開発です。 プロジェクトの納期がタイトであることを考慮しつつ、さまざまなフロントエンドJavaScriptフレームワークを評価しました。企業の大型プロジェクトでこれほどの改変をする機会はめったにないため、評価プロセスは可能な限り詳細に詰めました。 フレームワークを
SPAにおけるCSSについて、ひとつの解（追記あり） - エンジニアをリングする
SPAにおけるCSSのありかたについてずっと悩んでたけど昨日今日で一筋の光明が見えた— よしこ (@yoshiko_pg) 2017年4月7日 この話を簡単にまとめておこうと思います。 結論を先に書くと「今のところtemplate literal内にCSSを記述する形式のCSS in JSがいい感じ。Reactならstyled-componetnsが良かった」という感じです。 悩んでいたこと コンポーネント指向でSPAを作っていく上で、CSS（というかスタイリング）はどう書いていったらいいんだろう？ということに結構悩んでいました。 HTMLとJSがコンポーネントとしてまとまっていく中でCSSだけは今まで通り別物として扱い、BEMなどでグローバルスコープと戦うのか？はたまたCSSの枠をはみ出てJSコンポーネントの粒度に合わせたコンポーネント化をするのか？ 加えて、見た目も挙動も複雑なアプリケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
component test
MobX
React Desktop | React UI Components for OS X El Capitan and Windows 10
