Help us understand the problem. What is going on with this article?
/* @flow */ import React from "react" import styled from "styled-components" import pure from "recompose/pure" type Props = {| value: string |} export default pure(function Example(props: Props) { const { value } = props return ( <Container> <Value>{value}</Value> </Container> ) }) const Container = styled.div` width: 100%; height: 100%; display: flex; justify-content: center; align-items: center;
pwa_study - connpassに参加してきたのでメモ。 用語 SW = Service Worker XSS = cross site scripting Fetch = Fetch API ウェルカムLT クライアントサイドDDDが行われるようになってきた クライアントサイドにロジックが寄ってきてる 難しい Service Workerもクライアントサイドにそういうロジックや仕組みがよってきたという現象の一つなのでは Service Worker Lifecycle - laco スライド: Service Worker Lifecycle by Suguru Inatomi SWのライフサイクル Service Worker のライフサイクル | Web | Google Developers これよめば大体分かる スライド -> 記事読むと良い register -
redux-saga は React/Redux アプリケーションにおける副作用(データ通信などの非同期処理、ブラウザキャッシュへのアクセスのようなピュアではない処理)をより簡単で優れたものにするためのライブラリです。 Saga はアプリケーションの中で副作用を個別に実行する独立したスレッドのような動作イメージです。 redux-saga は Redux ミドルウェアとして実装されているため、スレッドはメインアプリケーションからのアクションに応じて起動、一時停止、中断が可能で、Redux アプリケーションのステート全体にアクセスでき、Redux アクションをディスパッチすることもできます。 ES6 の Generator 関数を使うことで読み書きしやすく、テストも容易な非同期フローを実現しています(もし馴染みがないようであればリンク集を参考にしてみてください)。それにより非同期フローが普通
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-
※2017/4/21にオンロード時のデバッグ方法8を追記しました! こんにちは!エイチーム引越し侍の加藤です! みなさんJavaScript書いてますか? console.logめっちゃ使うよねーって人は目からうろこのデバッグ方法を、 ケース毎に紹介していこうと思います。(僕はconsole.log使いません) サーバーにデバッグ用のコードをアップロードすること無いので、 消さずに意図に反してリリースしてしまう危険性がないのもお勧めです。 前提知識 F12で出てくるデベロッパーツール(Elements, Console, Source, Network)の知識 Ctrl+Shift+Fで外部ソース(js,css)に対して一括検索ができる HTML、CSSはElementsから直接修正⇒確認ができる jsはSourceから直接修正できる(Ctrl+Sで保存したらその状態で実行できる) jsは
はじめに Vue.jsは軽量ですが、数万件のリストを並べるとそりゃ普通につらい。 だから目に見えるとこ以外はdom描いてもらうのやめるってコードです。 デモ デモ(jsfiddle) コード <div id="app"> <div style="overflow:auto;height:170px;" @scroll="getScrollParam"> <ul :style="listStyle"> <li style="height:17px" v-for="num in displayList">{{num}}</li> </ul> </div> </div> new Vue({ el: '#app', data: function(){ return { list:list, scroll:0,//スクロール量 scrollMax: (list.length - displayRow
react-router-redux を 4.0.0 にしたらメソッド名とか中の処理とかけっこう変わってました。 前に書いたURLのフック処理がいろいろ駄目になっていたので、4.0.0でどんな処理になっているのか、ざっと追って、新しくコードを書き直してみました。 react-router-redux が何をやっているのか 最新の 4.0.0 では react-router-redux がラッピングした history オブジェクトを React Router に渡すようになっています。 このラッピングされた history は listen イベント登録が書き換えられており、store に格納されているURLが変更されると、その情報をパラメータに listener がトリガーされるようになっています。 流れを3ステップで説明すると以下のようになります。 オリジナルの history のUR
react-router また仕様変更 react-router v1.xからv2.xへのバージョンアップ v0.xからv1.xにあがった時点で色々ありましたが、v2.xでもまた色々あるみたいです。 本家サイトに、v2.0.0 Upgrade Guideがありました。 それによると、大きな変更点は、 historyをrouter定義時に必ず指定することになった コンポーネント定義時にmixinsでHistoryを指定しなくなった contextでrouterを使い回すことになった なのでpushStateなんかはcontext.router.push()とかすることになった 今までの実装のままだとコンソールに警告出る、で、次のVerから使えなくなる というところです。 context 以前はReactの公式ページでは確かcontextについて記述がなかったのですが、いつの頃からか記述が追加
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに jQuery 3.0が正式リリースとなったので、最新のアップグレードガイドをまとめようと思います。 原文から一部わかりやすいように言い換えたり、補足したり、省略したりしています。 注意: 長いです。主要な変更点は前回の記事【翻訳まとめ】jQuery 3.0 alpha リリースノートを参照してください。 jQuery Core 3.0 Upgrade Guide 全体像 APIを綺麗にしてバグを修正しました。 一部破壊的な変更があり 既に非推奨と公表していたAPIを削除 ドキュメントにない隠しAPIの削除 特定の入力値に対する
最低限のコストで最近よく聞くいい感じのjsを書きたい時の構成をずらーっと書いてみる 準備するもの node/npm (最近はrbenvクローンのnodenvがいい感じ、操作は同じ) webpack babel .babelrc .babelrcを設置しとくとbabelのデフォルト設定がこいつの中身で書き換わる Reactを使わないなら、presetのreactはいらない export defaultされたパッケージをimportした時に.defaultで引くのを許せるなら、add-module-exportsはいらない(後述) Reactいる { "presets": [ "es2015", "stage-0", "react" ], "plugins": [ "add-module-exports" ] } いらない { "presets": [ "es2015", "stage-0"
Intro Service Worker の初心者向けのチュートリアルや、使ってみた系のエントリも増えてきました。 しかし、 Service Worker は通常のブラウザ用 JS の開発と少し経路が違い、慣れるまで開発やデバッグもなかなか難しいと思います。 そこで特に難しい部分、そして分かっていないと実際にデプロイした際に難しいと思う部分について、実際に動きを確認しながら解説したいと思います。 なお、 Service Worker の基本的な概念などについては、他のチュートリアルなどを見て理解している前提で進めます。 思いつきで撮ったので色々ミスも有ります、また Chrome Dev Tools の UI はどうせ変わるのでそのつもりで見てください。 TODO になっている動画は、そのうち撮って追加します。 List claim controllerchange updatefound
Service Worker の claim() について Apr 18, 2015 Programming Service Worker のスコープとページコントロールについて解説する記事のその 2 です。既に Service Worker の基本について理解していて、かつ、前回の記事を読んでいることを前提にしています。今回は「まだコントロールされていないページをコントロール状態にする claim()」について紹介します。claim() は Chrome ではバージョン 42 から使用することができます (リリースノート)。 ページコントロールが始まるタイミング (前回の復習) 前回の記事で「Service Worker がページをコントロールするかどうかは、そのページを開いた時に判断される」と説明しました。次のコードは前回の記事からのコピーで、ページを開いた後に登録された Servic
Step forward Understanding Service Worker Registration & Lifecycle at Frontend Meetup Tokyo vol.2 2016/5/18 Jxck
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く