Reactive Swift Meetup http://wantedly.connpass.com/event/29039/
Introduction Androidにとってアプリ設計は永遠の課題だと思います。 Activityが独特のライフサイクルを持っているのがさらに課題を複雑化します。 設計についてはMVCやMVP、MVVM、Clean-Architecture、DDDなどが最近の主流でしょうか。 上記にあがった設計手法に関しては素晴らしい記事がいくつもあるのでとても参考になると思います。 AndroidではMVCよりMVPの方がいいかもしれない http://konifar.hatenablog.com/entry/2015/04/17/010606 [ Android ] - これからの「設計」の話をしよう https://tech.recruit-mp.co.jp/mobile/android-architecture/ AndroidオールスターズでClean Architectureについて発表し
Join over 27,880 front-end software engineers for one weekly email. Read handpicked articles with short summaries. Save time on finding worthwhile content. Learn something new every week. What our readers say about the newsletter? A great newsletter as always with well-written useful articles. So much to know and it is constantly evolving. Thank you for keeping us up to date. Really got a lot out
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい(と思っている)Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた!」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
想定しているシチュエーション 非SPA環境で個別にマウントされるコンポーネントがそれぞれで小さくFluxするような環境。 SPAガッツリ組むのでないなら、Fluxフレームワークは不要だと思っていて、とは言えオレオレ構成も行き過ぎると害になる。 その辺のバランスをとって、次のような構成がいいのではないか、と考えてみた。 考え方 コンテナがEventEmitterを1つ保持する コンテナはEventEmitterの各種イベントをListenする コンテナはpropsとstateを区別して扱い、stateを更新する コンテナはコンポーネントを一つだけ描画する コンポーネントはpropsとして渡されたEventEmitterを発火させる コンポーネントはEventEmitterをListenしない コンポーネントはpropsのみ扱う コード // src/components/header.js
autoscale: true How to work as a Team 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 目的 新規でそこそこ複雑なウェブページを作る(アプリに近い) ある程度柔軟に拡張でき、メンテできるような設計にしたい 無難にReact + 何かでちゃんと設計して作っていきたい この設計部分をどう決めていくのかという話 現状 チームにReact/Flux/Reduxを触ったことがない人が多い どれが(主にView以外の設計)ベストかは分からない Flux的な部分の話 ものごとは変わる。 混乱は変わらない 混乱の原因 情報過多 情報不足 適切でない情報 上記の組み合わせ! via P21 今日からはじめる情報設計 情報の共有 情報不足 そもそもReactなどを知らない人には知ってもらう必
The National Football League adopted React in December of 2014. For the past year we have iterated and built on React’s core concepts, various Flux implementations, JSX, Babel, experimental proposals, and functional approaches. You name it and we’ve probably evaluated it and possibly use it in production. Read on for a review of the NFL’s year in React. React Los Angeles Meetup at the NFL Studios
こんなかんじです 自殺を知る、自殺を考える::職業別の自殺者数を年度で並べて表示 自殺を知る、自殺を考える(トップページ) Reactまわり うすくやっていく 前回はRedux+Redux-Routerを使ってうまくコンテキストを分離できてよかったですね、ということになりました。 やりなおしRedux - Redux Routerでコンテキストをわけると楽になる - Qiita しかし、さあまたなにか作りましょうとなったときに、あのActionsやReducersやconnectを思いうかべただけでもういやになるという、どうしようもないめんどくささがあります。 というわけで、今回はReact の Context を使って Flux を実装する - Qiitaをほぼそのまま使うことにより作業を軽くすることができました。 Providerが各コンテキストの親分となり、自分が監視するemitte
概要 React.js Advent Calendar21日目の記事です。 Reduxというフレームワークがじわじわ広まっている。Reduxは、Fluxの概念を拡張したもので、アプリケーションでひとつの状態をもつと、クライアントでの状態管理がいろいろ便利になるよ、というコンセプトを持つ。詳細は以下の記事が詳しい。 人気のFluxフレームワークReduxをさわってみた - マルシテイアは月の上 Motivation | Redux 筆者は現在React+Reduxでアプリケーションをつくっているが、今回は、そのテスト方針を書こうと思う。 テスト環境 karma+jasmine+sinonでつくる。E2Eはいろいろと・・・なので・・・メインはユニットテストで実装している。JavaScript DOMをつかってSimulationすれば、最低限は担保できるかなと考える。 テスト方針 大きな方針と
場所 ギッハブにあります。 github.com 作った動機 Fluxフレームワーク、色々出てきては消えるしReduxとかが提唱されるしでもうわけわかめ。これからアタシ(のプロジェクト)、一体どーなっちゃうの〜〜?! APIリファレンスみて色々と見比べてるだけの中途半端な知識だと、いざ自分が選んだフレームワークが死んだ時に潰しが利かない…… -> じゃあ一度自分で作ってみよう! あと社内にFluxわかるマンがいなかったので、公開して広く世間の意見を求めたいという気持ちも強かった。なんかおかしいところあったら教えてくだされ〜〜〜 というわけで作った。 あとES6で書いたコードをnpmモジュールで公開する方法を知りたかったというのもある。 大変だったところ Fluxを実際に実装に落とし込める感じに理解するのが大変だった。 理解するために、Facebookの概念図をみたり、azu氏の実装(Git
この辺を読みながらfluxの各パーツの役割、reduxの登場人物について 自分のめもとしてまとめてみた http://rackt.github.io/redux/index.html reduxの思想 1つ情報源を正とする アプリケーションの状態は1つのstoreオブジェクトが管理する stateはリードオンリー 状態を変更する唯一の方法はactionを発行すること 状態の遷移はただの関数によって行う 状態を変更するための処理はreducersに定義する fluxの登場人物 actionCreator actionを作るための関数 ajaxリクエストなどの処理を行い、結果を含めたactionを作成する action アプリケーションで何が起きたのかとそれに付随するデータ nTypeと任意のデータを持つ単なるObject acitonCreatorによって作成されてdispacherに渡され
In this comprehensive tutorial, Dan Abramov - the creator of Redux - will teach you how to manage state in your React application with Redux. State management is absolutely critical in providing users with a well-crafted experience with minimal bugs. It's also one of the hardest aspects of a modern front-end application to get right. Redux provides a solid, stable, and mature solution to managing
(追記) 本記事,頭のなかを整理しきれていない状況で書いたためよくわからないことになっていますが,Clean ArchitectureやRedux,DDDの優位な点を解説するような記事ではないことをご了承いただけると幸いです. 全体の構成がどうなっているか・モチベーション・pros・cons等については後日別記事にまとめようと考えています. いま書いているアプリがClean ArchitectureになりそこねたMVPと中途半端なDDDを組み合わせたようなアーキテクチャになっている. このアプリをある程度キチンとClean ArchitectureとDDDに寄せるにあたり,DDDのレイヤ分け(Data/Domain/Presentation)をどこまで厳格にやるかで悩んでいる. 現状 だいたいこんな感じ. Data/Domain/Presentationのすみ分けはしていない 実装上は意識
petehunt/react-howto · GitHub これの、2016/01/07時点での日本語訳です。 更新は追わないと思うので、流し読みにどうぞ。 react-howto もしあなたがReactをはじめたばかりで(もしかしたらフロントエンド自体もはじめてで)、React周辺のエコシステムに困惑してるとしたら、そこにはこういう理由がある。 そもそもReactはアーリーアダプターやエキスパート向けに作られた経緯がある Facebookが唯一実際に使われてる例であり、Facebookより小規模なプロジェクト向けの使い方にフォーカスしてない Reactのガイドを装った間違った情報も多い このドキュメントは、HTML・CSS・JavaScriptでWebページを作ったことがある人を想定読者にしてる。 これを書いたワケ Reactに関する情報が山ほど交錯してるから。 自分はReactを作った
普段の仕事はサーバーサイドばっかりだったので、年末年始でフロントエンドの知識をアップデートしたいなぁ、ReactかVue.jsやろうかなぁと思ってました。それで、こちらの記事を読んでると... uehaj.hatenablog.com サーバサイドJavaをずっとやってきて、モダンなJSの知識や経験があまりないけど、最近Reactってのが話題になっているのがさすがに気になるので挑戦したい人 これは!Javaだけってわけじゃないけど、ずっとサーバーサイドってまさに自分のことじゃないか!ということでコードを読んでみることに。 リポジトリをcloneしてreact-appディレクトリを一旦削除して、react-appを自分でつくり直しながら学ぶことにしました。コード読んでみて分からないことが色々あったので、一歩一歩分からないところを潰しながらやっていきました。その時の備忘録です。サーバーサイドは
この記事は仮想DOM/Flux Advent Calendar 2015の25日目……に入れようと思ってたけどもう埋まってた……。 オマケということで頼む!!!!! 24日目は JavaScript - 実践:MagJS で TodoMVC - Qiita でした。 メリークリスマス!!!!!!!!!! こんにちは id:amagitakayosi です。 みなさん今月も Flux 書いてますか? 僕はオレオレ実装をIsomorphic対応したけど昨日Revertしたところです!!!!!ウオー!!! 今日は↓12/2の記事↓の続きを書いていきます! amagitakayosi.hatenablog.com もくじ 前回のあらすじ flux-utils Container vs View Cycle.js flux-challenge Rx系 thisless-react, Yolk DDO
There has been no shortage of great Flux implementations, such as Flummox, Alt, or Fluxible. Most of them are focused on making Flux easier to use with the server rendering and reducing the boilerplate. They also often provide convenience utilities like higher-order components and asynchronous action helpers. Still, under the hood, many of them are built on top of the original Flux Dispatcher. Red
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く