WeAreJavaScripters@15th https://wajs.connpass.com/event/76238/

WeAreJavaScripters@15th https://wajs.connpass.com/event/76238/
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 以前 React Redux を用いた SPA 新規サービスを運用して得た知見と実装例 と言うテーマで発表した内容に、加筆修正して記事にしてみました。2年半くらい取り組んで見ての結果や感想をシェアできればと思います。 対象読者 SPA の開発に興味がある方 最近の WEB フロントエンド開発に興味がある方 ある程度 React や Redux を触ったことがある方、触りたい方 目的 具体的な実装例をもとに知見を共有し、Web 開発の役に立ててほしい おかしな実装や、もっと良い方法があれば、教えてほしい 内容 コードベースでの実装例の紹介
Transcript தେن։ൃΛ 3FBDUͰߦ͏ݱ͔Β͍͑ͨ͜ͱ 3FBDU�KT�NFFUVQ���� None ٕज़తͳ͋·Γͳ͍Ͱ͢ தେنͳ։ൃΛߦ͏্Ͱ ۤ࿑ͨ͜͠ͱվળͨ͜͠ͱΛ͠·͢ ݱͷటष͍Ͱ͢ Έͳ͞Μ͕ࠓޙ։ൃΛߦ͏ࡍʹ ࢀߟʹͳΕͱࢥ͍·͢ ݱࡏߦͳ͍ͬͯΔ։ൃʹ͍ͭͯ ݱࡏߦͳ͍ͬͯΔ։ൃʹ͍ͭͯ � w� ϑϩϯτΤϯυͷ։ൃऀɿ։ൃॳ�ਓ ���������ݱࡏ�ʙ�ਓ΄ͲͱϕτφϜ։ൃڌʹਓ� � w� ։ൃ͍ͯ͠Δͷɿཧը໘� � w� ։ൃɿ�� � w� ༻ٕज़ɿ3FBDU� �3FEVY FO[ZNF FUDʜ� ςετॻ͔ͳ͍ͱޙʑࣗΛۤ͠ΊΔ ςετ͕ͳͥඞཁͳͷ͔ � w� Կϲ݄લʹ։ൃͨ͠ͷΛमਖ਼ͨ͠ͱ͖ɺ ��������खಈͰࢼݧ͢Δͷਏ͍ɻ � w� ։
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい(と思っている)Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた!」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ReduxはSingle Store、immutableなState、副作用のないReducerという3つの原則を掲げたFluxフレームワークです。しかし他のフレームワークと違って提供しているものは最小限で、とてもフルスタックとは言えない薄さです。そのためすべてにおいて定番と言える書き方が定まっているわけでもなく、どうしようか迷ってしまうことも少なくありません。その筆頭とも言えるのが 非同期処理 の扱いです。コミュニティでは今でもさまざまな方向に模索が続いていますが、よく使われているものだとredux-thunk、redux-
Flowのバージョンは0.61.0で確認している。 propsを渡さない場合、Flowはどのように指定すればよいのか ReactのコンポーネントのpropsにFlowで型をつける場合、以下のように書く。 type Props = { foo: string, }; class ChildComponent extends React.Component<Props> { render() { return <div>{this.props.foo}</div>; } } class ParentComponent extends React.Component { render() { return <ChildComponent foo="hoge" />; } } https://flow.org/en/docs/react/components/ では、このコンポーネントにはprop
エンジニアの id:t930 です。 freee Developers Advent Calendar 2017 19日目いきます。 React はその名前を聞くようになってから3年以上が経過し、Webアプリケーション開発の文脈においてはもはや枯れた技術と言えるでしょう。会計freeeでも2015年ごろに Backbone.js から React へのリプレースを行い、現在では Reactコンポーネントだけでも900近いファイルが存在しています。当然このような規模でやっているとリファクタリングも必要になってくるわけで、本記事ではそんな中で得られたReactコンポーネントにおけるリファクタリングの指針について紹介していきます。1 適切な単位に分割する React に限った話ではないですが、巨大で見通しの悪いコンポーネントはメンテナビリティや再利用性の低下を招きます。表示領域、責務、意味付けに
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
こんにちは。maxmellon です。 今回は,Reactの再レンダリング回数をなるべく減らす方法について紹介したいと思います. 前回記事と関連があります.もしよろしければ合わせてお読みください. 本記事は,Reactのライフサイクルなどの基本的な仕様の理解のある前提で話を進めていきます。 Reactの基本的なことにつきましては,下記などを参照してください. https://facebook.github.io/react/docs/why-react.html http://mizchi.hatenablog.com/entry/2014/09/02/201728 はじめに Reactが再レンダリングされるケース Reactのコンポーネントが再レンダリングされるには,次の2ケースがあります. state の変化によって DOM が 追加,削除された時. state の変化によって DOM
AWS Amplifyとは? 本記事はServerless Advent Calendar 2017の13日目の記事です。よろしくお願いします。 AWS Amplifyは、2017年11月に公開されたAWSを利用するWebアプリケーション向けのJavaScriptライブラリです。サインアップやサインイン、MFA、追跡またはメトリクスの分析、コンテンツ管理、またはサーバーレスAPI統合などの実装が容易にできるように設計されています。 AWS Amplify は、クラウドサービスをスケーラブルかつ保護された方法で使用して一般的なアクションを実行するクライアント開発者に、宣言型インターフェイスを提供するように設計されています。これらの新機能を使用して、開発者は JavaScript アプリケーションを作成して一般的な抽象化を使用したベストプラクティスをプログラムによって適用し、最終的に開発サイク
設定不要のビルドツール parcelというビルドツールが空前の勢いでGitHubスターを集めており、リリース数日で5000スターを超えています。今日だけでも1000スター以上増えており、Googleなどの有名企業リポジトリ以外でこのスピードで人気がでるのは異例です。 https://github.com/parcel-bundler/parcel https://parceljs.org/ 実際に試してみたところ、これはwebpack一強時代を終わらせるレベルの使いやすさだと確信しました。 作者はAdobeのエンジニアで、その他著名エンジニアも続々と参加している様子です。 webpack疲れ webpackが出た当初、webエンジニアはgulp/grunt疲れの状態だったことを覚えている方もいるかと思います。 webpackの統合された設定ファイルは、タスクランナーで逐次処理していたものを
React is Slow, React is Fast: Optimizing React Apps in Practice React is slow. I mean, any medium-size React application is slow. But before you start looking for alternatives, you should know that any medium-size Angular of Ember application is slow, too. And the good news is: If you care about performance, it's fairly easy to make any React application super fast. Here is how. Mesuring React Per
About 1.5 years ago we released DraftJS Plugins 1.0. It provides an architecture to combine various rich text editing features based on your needs with only a handful lines of code. Today we are happy to announce the 2.0 release adding toolbar plugins and supporting a delightful experience to manage and enhance Atomic Blocks like Images. 🎊 🎈🎉 DraftJS Plugins 2.0 Example on the Website (Source C
まだアクションクリエイターを自分で書いているの? reduxとflowtypeを使ってフロントエンドアプリケーションを構築していると、ボイラープレートが多く、面倒だと感じることがありませんか? しかし、もはや、このAST時代の前には過去の悩みでしかありません。 型を書く。それが全てです。 型を書いて、定数を書いて、アクションクリエイターを書いて、一つ変更したら全て変更して、もしくはなんらかのハックを行って型付けして、なんてものは過去のことです。 これからは、アクションクリエイターの作成に5秒以上時間をかけたら怠惰でありましょう。そして、これはs2sの1プラグインでしかありません。 プラグインを組み合わせると以下のようなこともできます。 s2s (Source to Source) これを実現している仕組みをSource to Source(s2s)といいます。 ソースコードからソースコード
こんにちは、Speeeエンジニアの二社谷(nishaya)です。 先日開催されたSpeeeKaigi(詳細は以下の記事を参照)にて、Reactで使ったパターンシーケンサの発表を行いました。 tech.speee.jp 今回作ったもの DEMO ソースコード ブラウザで動くマルチトラックのステップシーケンサです 音楽の知識がなくても、なんとなく触っているだけでそれっぽい音が出ます サンプラーもついてます 使ったもの React/Redux FlowType Web Audio API/MediaDevices 発表資料 speakerdeck.com モチベーションと課題 前回のSpeeeKaigiではReactでシンセサイザーを作ったのですが、自分は楽器を弾けるわけではないので、ブラウザを使って音楽を楽しむところまでは到達できませんでした。 そこで、下記の3点を押さえたモノを作れば、楽器を
Next week, we are going to relicense our open source projects React, Jest, Flow, and Immutable.js under the MIT license. We’re relicensing these projects because React is the foundation of a broad ecosystem of open source software for the web, and we don’t want to hold back forward progress for nontechnical reasons. This decision comes after several weeks of disappointment and uncertainty for our
ElectronベースのTwitterクライアント: Nocturn ElectronでYoruFukurou風のTwitterクライアントを作った - k0kubun's blog の時にCoffeeScriptとjQueryで作っていたNocturnというTwitterクライアントがあり、これをES6, React, Reduxを使って書き直した。この記事ではその時に得た知見、感じた事を書いておく。 移行したスタックと移行時に感じたこと あらかじめお断りしておくと、僕は普段はRubyでサーバサイドの実装や運用をやっている人であり、JavaScriptに関してはほぼ素人の意見なので、以下はReactとかRedux興味あるけどまだ触ったことないですみたいな人向けの内容になると思う。 CoffeeScript → ES6 移行 参考: 春からはじめるモダンJavaScript / ES201
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く