use-react-redux-context で redux 環境下で React Hooks を使う - Qiita
で使えます。が、 peer deps として react react-dom react-redux redux がいるので、今までの redux スタック全部盛りでもあります。 これは何 ReactRedux connect を、Context API と useContext で置き換えようとしたものです。 その過程でパフォーマンスチューニングする余地を大量に入れ込んでいます。 hooks で redux を置き換えるものではなく、react-redux と協調するものです。 簡単な使い方 ReactRedux の Provider の下で、mapState される props を持つ Context を生成し、それを useContext できる、というもの。 import { Provider as ContextProvider, Scope } from "use-react-
fly.io で React アプリケーションの SSR を行う - Qiita
import React, { Dispatch, useContext, useReducer, useState, useCallback } from "react"; import { Route, Switch, Link } from "react-router-dom"; import styled, { createGlobalStyle } from "styled-components"; import { Action, reducer, RootState } from "./reducer"; import * as actions from "./reducer"; // RootState context export const RootContext = React.createContext<RootState>(null as any); export
Rust / yew で 仮想DOMなウェブアプリケーションを作ってみた - Qiita
前提として、自分の Rustの知識は 1年に1回ぐらい思い立った時にちょろっとやるぐらいで、基礎文法をググりながら、複雑なライフタイムとか書こうとすると手が止まる程度の知識。勘で書いてる。 前提 cargo build --target wasm-unknown-unknown ができるようになるまでは省略。 調べた感じ、Rust の wasm ビルドでウェブの何かしらをやろうとすると、次のような選択肢がある。 プレーンな wasm。基本的に数値(float)だけしか扱えない。ポインタの開始位置とサイズを返し、wasm メモリ空間のArrayBufferを自前でデコードする https://github.com/rustwasm/wasm-bindgen : ↑で生成された wasm の読み込みラッパーやTSの型定義、Rust 側からJSのメモリ空間を参照する諸々をやってくれるツール。 j
react-apollo と next.js を使った最速 GraphQLアプリケーション(+モックサーバー)実装 - Qiita
react-apollo を試しながらガチャガチャやっていると、モックサーバーなどを含め、なかなか体験が良かったので、紹介します。 こっちも参照 世のフロントエンドエンジニアにApollo Clientを布教したい - Qiita 今回書くコードの動いてる例は https://github.com/mizchi-sandbox/graphql-playground を参考にしてください。 git clone して yarn install; yarn start で動くはず。 ゴール 最終的にこんな感じのクライアント実装(next.js)が動くようになります。 import React from "react"; import { Query } from "react-apollo"; import gql from "graphql-tag"; const GET_USER = gql
prisma - 最速 GraphQL Server実装
react-apollo の調査で GraphQL サーバーをさっくり実装する必要があり、 今 graphqool どうなってるんだっけ、と見に行ったら prisma が推奨されていました。 日本語情報がまったくなかったので、調査した結果をまとめておきます。 prisma とはなにか GraphQL の形をした ORM MySQL/Postgre への マイグレーションヘルパー付き モデル定義からインデックス自動生成 CRUD自動生成 graphqoolの次期版? PaaS に依存せず、自分でデプロイ可能なマイクロサービス 自分も最初よくわからなかったのですが、 使ってみた感じでは、 GraphQL の形をとった ORM + Migration Helper です。 $ npm i -g prisma $ prisma init my-graphql-server # REPL で実装を選
Flowtype v0.71 で stage1 optional-chaining がサポートされた - Qiita
flow の changelog を週1ぐらいで眺めているのだが、サポートされたときいてマジかとなった Type support for the Stage 1 Optional Chaining proposal. To use this feature, set esproposal.optional_chaining=enable in your .flowconfig. 言われたとおりに、 .flowconfig に esproposal.optional_chaining=enable 追加し、 https://www.npmjs.com/package/babel-plugin-transform-optional-chaining を .babelrc に導入したが、動かない… 調べると optional-chaining は babel7 を使えということになっていたので、
俺が考えた最強の Reactのステートレスコンポーネントの書き方 - Qiita
最近自分はこう書いてるという例。意見が欲しい。 この記事に redux は出てこない。 参考: https://qiita.com/mizchi/items/bcb1aef8d1f14f8d0b4a 構成要素 React flow styled-components recompose 以下 SFC = Stateless Functional Component /* @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 } = p
JSフレームワークの末端がWebComponentsになるのか、なれるのか、検証してみた - Qiita
https://speakerdeck.com/mizchi/real-world-es201x-and-future で、「Reactやその他のフレームワークの末端はWebComponentsになるのではないか？」という話をした。とはいえ、実際に自分でそういうものを実装したわけではなかった。 じゃあ実際に、Reactから web components を呼ぶにはどうなるだろうか？実装してみた。 ゴールの設定 こういうコードが動いてほしいとする。 import React from 'react' export default class Home extends React.Component { constructor() { super() this.state = { value: 0 } } componentDidMount() { let cnt = 0 setInterva
universal-router で react-router を倒す - Qiita
Universal Router とは isomorphicガチ勢の kriasoft 先生作の Router ライブラリ。 内部的には path-to-regexp だから express と同じルール import UniversalRouter from 'universal-router' const routes = [ { path: '', // optional action: () => `<h1>Home</h1>`, }, { path: '/posts', action: () => console.log('checking child routes for /posts'), children: [ { path: '', // optional, matches both "/posts" and "/posts/" action: () => `<h1>Po
render prop と HOC について - Qiita
react-router の mjackson が HOC を批判していたので、自分の考えを書いておきます。 Use a Render Prop! - componentDidBlog https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce mjackson の主張の要約 ES2015 Classes は mixin 的な振る舞いをサポートしていない HOC は 新しい mixin だ 主張1: HOC は自身の振る舞いを自己規定するものである const connector = ReactRedux.connect(...) compose( connector, pure, lifecycle({ componentDidMount() { console.log('mounted') } }) )(Counter) こ
React とGUI 設計論、あるいは新世代のホームページビルダー - Qiita
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる！というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
puppeteerでフロントエンドISUCONのためのパフォーマンス計測ツールを作りたい - Qiita
この記事は、 Recruit Engineers Advent Calendar 2017 の2日目です。 リクルートテクノロジーズで パートナーとして働いてる mizchi です。ここでの仕事は、 yosuke_furukawa が忙しくて調べられないことを、勝手に調べてくることです。 今までリクルートでやったことは Next.js, AMP, PWA, Puppeteer って感じ。今回は Puppeteer を使ったE2Eテストの自動化やパフォーマンス評価の話をします。 puppeteer とは リポジトリ名でわかりますが、GoogleChrome チームが公式に提供する Chrome の Headless Driver です。 スペルがとにかく覚えづらい クロスブラウザテスト以外にはかなり万能なツールです。E2Eテスト、スクレイピング、日々の作業の自動化、なんでもござれ。 他のブラ
Puppeteer で FirstMeaningfulPaint を取得する - Qiita
概要 パフォーマンスメトリクスのAPIを有効化する setTimeout ループで FMP取得まで待つ コード npm install -S puppeteer const puppeteer = require('puppeteer') async function getPerformanceMetrics(page) { const { metrics } = await page._client.send('Performance.getMetrics') return metrics.reduce((acc, i) => ({ ...acc, [i.name]: i.value }), {}) } async function waitForFMP(page) { let doneMet = null while (true) { const data = await getPe
Hypernova/Webpacker/Turbolinks でSSRできてSPA風に動くスケルトンを作った - Qiita
対象 Rails だけどSPAっぽく画面遷移したい SEO担保しないといけない 新規設計の参考 jQuery まみれの状態からこれと同等のことをするのは、不可能じゃないけど難しいです。 単にどう導入するか知りたいだけなら https://github.com/mizchi-sandbox/packnova/commit/447a91ea3a706c0bb0aac8570d1fbbaf6c9710f1 のコミットで 目指したモノ 最小限の設定で Rails エンジニアでもメンテ出来るSSR/SPAアプリの土台。 ただし土台をハックし始めるとその限りではない。。 スタック webpacker でコンパイル 画面遷移は hypernova-react/turbolinks で自動再マウント ルーティングはRails側に寄せてます。なので react-router は入ってないです。 入れる選択肢
真・Flow & Redux で Reducer の実装パターンを考える - Qiita
4ヶ月ほど前、 Flow & Redux で Reducer の実装パターンを考える という記事を書いたが、 reducer を型付けするという目的は達しているものの、明らかに記述量が増えて冗長だという問題があった。 ところでこういう記事を見つけた。 これを flow 向けに書き直した、というかセマンティクスが一緒だったので、そのまま動いたのだが、これを自分向けに書き直したらとてもいい感じになった. flow は v0.54.1 コード // @flow type __ReturnType<B, F: (...any) => B> = B type $ReturnType<F> = __ReturnType<*, F> // Actions const INCREMENT = 'counter/increment' const ADD = 'counter/add' export func
AMP/PWA をどこで/いつ使うか - Qiita
某所で使った資料の公開版 用語整理 PWA: ネイティブアプリのようなUXを提供するための機能群 SPA: JSで遷移するシングルページアプリケーション AMP: 後述 PWAMP: AMPで流入させてPWAを起動する形式 MFI: モバイルファーストインデックス いまさら聞けないPWAとAMP アメブロ2017: Isomorphic Web Appの進化編 AMP とは イニシャルビューのためのHTMLの特殊なサブセット GoogleにホワイトリストされたHTML属性しか使えない GoogleにホワイトリストされたJSプラグインしか使えない CSSはHEADに全部書く AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う HTTPS必須 必ずしも全ページをAMPに対応する必要はない PWA: ServiceWorker の機能 リソースの先読み
Chrome M60 で Native ES Modules + ServiceWorker を試して未来へのマイグレーションを見積もる - Qiita
Chrome M60 で Native ES Modules + ServiceWorker を試して未来へのマイグレーションを見積もるServiceWorkerbabeles2015ESModules 目的 Chrome M60(Canary) でフラグ付きで ES 2015 の ES Modules が動くようになったので、試す。 ServiceWorker と Babel 前提で、エッジな構成で今のバンドル環境を無理矢理シミュレートしてみて、今との比較で現実的なマイグレーションパスを探しておくことにした。 成果物 uupaaさんの WebApp2 をスケルトンとしてお借りしました。 なにができるか まるで browserify/webpack でビルドしてるかのようにこのコードが動く。ブラウザ上だけど babel も動く。 /* @flow */ import { combineRe
Flowtype導入のための指針・実際の運用について - Qiita
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
async await に書き換えて、Promiseと 同期による例外の区別でハマった - Qiita
// async function の中 try { load().then(data => { console.log(data) }).catch(e => { // ... }) } catch (e) { // ... 例外処理 } わかりやすく簡単にしている。実際にはもっと複雑なコードだった。Promise にすれば try と catch を一本化して綺麗にできるやん！と思っていた。最初は。 書き換えた // async function の中 try { const data = await load() console.log(data) } catch (e) { // ... 例外処理 } catch が一個減ってリファクタできたーと思っていた。確かに異なる例外処理のブロックが減ってしまっていたが、どうせ何かしらのデッドコードだろと思って消してしまった。 注: 意味的に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSのコードの自動整形に Prettier が便利だったので、�eslint とAtomから使えるように設定した - Qiita
