サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
qiita.com/mizchi
最近自分はこう書いてるという例。意見が欲しい。 この記事に 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
やりたかったこと: Reactから子に関数参照を渡すのを綺麗に実装したい 前回からの変化 lit-extended を使えば、テンプレートにコールバックを渡せることを知った 子に対して関数参照を渡すのではなく、 CustomEvent を生成するようにして dispatchEvent するようにした 一旦変換用のイベント定義辞書を渡すようにした WebComponent定義 /* @flow */ import { html, render } from 'lit-html/lib/lit-extended' type Props = { onClick?: Function, text: string } const template = (props: Props) => { return html` <button on-click=${props.onClick}>${props.
なぜやるか 普通にやってても満点は難しい。まずは無で100点を目指す。 Google が Mobile First Index やりだしたら多分 lighthouse のスコアも使うだろうという予想 next.js というある程度現実的なフレームワークを使うことで適度に YakShaving もこなせるだろうという予想 使ったもの next.js: export mode workbox 結果 コード https://github.com/mizchi/next-pwa-boilerplate デプロイ先(netlify) https://eloquent-spence-e8f2bb.netlify.com/ PWA 91点は、 netlify 使っている制限で、HTTP to HTTPS のリダイレクトを設定するにはカスタムドメインを設定する必要があり、金を払いたくないので諦めた。設定す
var e = Object.defineProperty(document.createElement("DevToolDetector"), "id", { get: () => { // detect devtool } }) console.dir(e) 仕組み console.dir が DOM 要素を展開しようとする時、DevTools が開いていれば、 element.id 要素を取得しに行く。その結果 getter が走ことで検知できる。 使えるのか Chrome Canary (67) では対策済みなので、次のバージョンぐらいでは使えなくなると思います。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficient
同期 ちょっとした状態を作るのに extends React.Component したくない。状態を隠蔽したHOCも書きたくない。 かつそれでいてある程度宣言的にしたい。 render-props で実装すれば良いのでは? 実装 /* @flow */ import React, { type Node } from 'react' // Generic State Manager export default class WithState<State> extends React.Component< { initialState: State, render: (State, ((State) => State) => void) => Node }, State > { constructor(props) { super() this.state = props.initialS
ややお気持ち多め。 前置き 最近の個人的な考えとして、React 書く人は ReactNative 側にスキルを寄せたほうが良いのではないか、と思っている。 ReactNative の需要の高まりは凄い。最初はプロトタイピング採用だったのが、徐々にプロダクションに出始めている。今年末には新規プロジェクトの10~20%は ReactNative になるんじゃないか?という感すらある。 僕はデスクトップのブラウザは好きだけども、残念ながら、世の中の趨勢はモバイル側にある。その上でフロントエンドにロックインすることをリスクに感じている。PWAのアプリケーションも来そうではあるが、直近の需要を賄うためにやはりReactNativeに習熟しておきたい。 大事なのは、「考え方として」 ReactNative に軸足を移したほうが色々といいということだ。 Web は基本的に動きが少ない。見栄えをよくした
作ったけど全然未完成です。いろんな都合で黒魔術です。 まだ全然。どっちかというとASTで遊んでみた系ですが、これを想定してない趣味プロジェクトのcomponentsを対象に突っ込んだら、意外と半分ぐらいは動きました。 なにこれ flow が入ってることは前提
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
状況 A のロードが終わったら B をロードする B のロードが終わったら C をロードする C のロードが終わったら end を表示する こういうものをSSRしたい。 問題 ReactDOMServer.renderToString() は同期しかとらないので、普通にやるだけだと A のロード待ちで止まってしまう。 この目的で使っていた https://github.com/recruit-tech/redux-async-loader が react-router v3 に依存していて、更新できていない。 解決策 componentWillMount まで実行されるので、その action を収集する C のロード完了の action が実行されまで、store を更新しながら何度も render する 対象とするコード /* @flow */ import React from 'r
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
https://qiita.com/mizchi/items/0e2db7c56541c46a7785 を考え直す。 このパターン、明らかにまだ冗長で、しかもFlowもTSもこれでは推論器がよく落ちるという問題があった。 なのでそもそも型が自明なラッパーを定義するのがいいのでは、という発想からスタートしている。 追記: hard-reducer という名前で実装した 既存の reducer 定義の何が面倒臭いか 自明なことを何度も書く 定数値を何度も書いているようで結局 case 文で 一意に紐付いている Action の Union Type の推論が失敗こけやすい (flow も ts もすぐ型をロストする) 巨大 switch case 守るべき reducer の spec とは reducer の (State, Action) => State というインターフェース 最終的に
最初に知るべきこととして、Flow も TS も型システムのセマンティクスがよく似ている。 Redux & Typescript typed Actions with less keystrokes の 記事のかなり魔術的なコード、実は flow でも ts でもそのまま動いたりする。 自分は両方頻繁に使うので(flow寄りだが)、どういうコードを書くと手戻りが少ないか、考えながらコードを書いてるか書き出してみる。 お断り flowtype と typescript の、特に typescript 的なベストプラクティスに反する可能性がある。 完全にコンパチにするのは不可能だが、極力似たイディオムを使う。 どれも「極力頑張る」という感じで原則禁止というわけではない。大事なのは相互にコードを持ち出す時のポータビリティ。最悪なのは型がないという状態。 あと自分は TypeScript の非標準
Animation周りが苦手だったので、Flash のタイムラインアニメーションエディタみたいなものを練習がてら作ってみたい、ということで勉強した。 本記事は勉強ログ気味。 Web Animations API とは CSS Animation の keyframe 制御を JS から可能にしたようなもの。 CSS Animation は 自分で止まったり再開したりできないし、フレーム制御も出来ない。 JS から制御できないのでコントロールしづらかったが、その問題を解決する。 Web Animations 実装具合と Polyfill Can I Use 見る限りは Firefox で 実装済み、 Chrome で実装中 https://caniuse.com/#feat=web-animation polyfill なしで試した結果、chrome で elem.animate(...)
日本語訳があるので面倒臭がらずに読んだほうがいいです。 要約 AMPは無意識にユーザーがGoogleエコシステムに留まるようになっており、また検索結果に対してプレミアムな演出や優先順位を与えており、Webの中立性を破壊している、という指摘。 Googleが言うように、Webの速さが懸念ならば、AMPという技術の有無に関わらず特定の速度を満たせば今のAMPと同じような特典を与える、また明示的にGoogleのエコシステム内にいるという演出(おそらくヘッダーを付与するなど)を行う、といった提案。 私見 GoogleのWebの速さに対する懸念も、AMPの実装の邪悪さも、自分は両方よく分かる。 AMPは自分の仕事のドメインとしてチェックしているが、プラグインがGoogleのホワイトリストとして管理されていて、実際には政治力を使って、プラグインを登録させるといったアクションが必要になり、日本のような狭
気持ち reducer や rx の世界観からすると、JSのオブジェクトへの副作用は悪です。予測可能性を破壊する者ですし、時系列な状態を復元できなくなります。 Reactの一部の操作では、同一参照のオブジェクトのまま値を書き換えると、更新系が壊れるものすらあります。shallow equal だと参照が一致するからですね。 なので基本的にイミュータブルなデータの取り回しをしましょう。 どんなコードをやめたいか この「メンバーへの代入」が基本的にやめた方がいい操作です。 宣言 基本的に const で宣言します。 明示的に副作用が起こる箇所だけ let で宣言します。 とはいえ、Array と Object は中身を変更できてしまうので、その辺のイディオムが必要です。 Object before
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) こ
最近作ってたものの紹介です。だいたいできたんで公開します。 これは何 ワークフローによりますが、CSS書く際に最初に決めるのは大まかなレイアウト構成だと思います。 で、最近はコンポーネント志向でReactComponentとか書いていくと、各領域が何を占めるかみたいな設計に便利なのが、CSS Grid Layout ですね。たぶんそう。 これからのグリッドレイアウト 第1回 Grid Layout Moduleの概要 CSS Grid だと何がいいかというと、やたらプラガブルなんで、機械的に吐き出しても汚くならない点です。というわけで作りました。 レイアウト設計、毎度結構だるくて、僕みたいなあんまCSS書きたがらないエンジニアだと、GUIでポチポチやって、それっぽいCSSを吐き出してくれるといいな、なんて思ったりしていました。 ただ、自分はこれを作る過程で Grid Layout に対して
意味 PWAでアプリを作ろうとすると、offline cache である程度ロード時間を無視できるとしても、 JSのCPU上の評価時間が支配的になっていく。 preact-compat(30kb) と react(91kb) でどれだけの差がでるのか調べることにした。 対象 このリポジトリ。 https://github.com/mizchi-sandbox/pwa-base ルーター、 redux を含んでいる。 react, preact 以外の deps はこう。 "dependencies": { "axios": "^0.17.1", "babel-polyfill": "^6.26.0", "react-redux": "^5.0.6", "recompose": "^0.26.0", "redux": "^3.7.2", "redux-logger": "^3.0.6", "
flow@60.1 これらの型定義の導入を前提とする https://github.com/acdlite/recompose/blob/master/types/flow-typed/recompose_v0.24.x/flow_v0.55.x-/recompose_v0.24.x.js https://github.com/flowtype/flow-typed/blob/master/definitions/npm/redux_v3.x.x/flow_v0.55.x-/redux_v3.x.x.js ユーティリティタイプや段階的な推論を組み合わせるテクニカルなコードになったが、一度理解してしまえば型付けされた props が手に入る。 /* @flow */ import React from 'react' import { bindActionCreators, combineR
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる!というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
module App { let make = (_children) => { ...ReasonReact.statelessComponent("App"), render: (self) => <div> { ReasonReact.stringToElement("Hello") } </div> }; } /* mount */ ReactDOMRe.renderToElementWithId(<App />, "root"); このコードを見る限り、ReasonReact は make という関数を見つけて React.createElement 相当の展開をする。 文字列は ReasonReact.stringToElement("Hello") という感じで埋める。多少面倒くさい。 名前空間の話 ここで、初歩っぽい話をするが(自分はocaml詳しくないので、こういうタイミ
これは Reason ML Advent Calendar の1日目です。時を遡って1日目です。思い立ったんでカレンダーごと作りました。 注意点として、基本的に、多少コンパイラとかメタプロが好きな程度のJSプログラマとしての視点で書いています。 ocaml ユーザーではありませんので、間違いがあったら編集リクエストやコメント欄などでご指摘ください。 Facebook の chenglou 氏が作ってる ocaml の言語拡張で、1方言という位置づけです。chenglou氏は react-motion の人というと React界隈では通りがいいと思います。 Reason の一番の特色は ocaml に js っぽいフレーバーの構文にしつつ、React.js の JSX 構文に対応していて、 BuckleScript をバックエンドしながら JS を生成して、 React アプリを簡単に作れる
この記事は、 Recruit Engineers Advent Calendar 2017 の2日目です。 リクルートテクノロジーズで パートナーとして働いてる mizchi です。ここでの仕事は、 yosuke_furukawa が忙しくて調べられないことを、勝手に調べてくることです。 今までリクルートでやったことは Next.js, AMP, PWA, Puppeteer って感じ。今回は Puppeteer を使ったE2Eテストの自動化やパフォーマンス評価の話をします。 puppeteer とは リポジトリ名でわかりますが、GoogleChrome チームが公式に提供する Chrome の Headless Driver です。 スペルがとにかく覚えづらい クロスブラウザテスト以外にはかなり万能なツールです。E2Eテスト、スクレイピング、日々の作業の自動化、なんでもござれ。 他のブラ
この記事は1ヶ月後の自分のネタ切れにつきアドベントカレンダーの記事ということになりました Why SPA や モバイルアプリ だととりあえず Firebase Functions に graphql エンドポイントを一個マウントして金で殴ってスケールさせるところからスタートするのがいいと思います。金の弾丸というやつです。 この環境は、query と mutation は実装できるけど、 Cloud Functions のライフサイクルの都合上、 wsバックエンドのsubscription は実装できません。そこは Firestore とか使ってなんとかできるんでいいかって感じ。 自分の用途としては、Firestore の write系は一律禁止、 read 系は firebase.rules で制御しつつ subscribe して、リアルタイムではない複雑な問い合わせやロジック検証付きの副
ふとログインすると beta 版UIってのが使えた。完全に dev.to 意識してて笑った。 実際には自分が残してきたロードマップや、Component が使われているのであろうのがわかって、そうそうこれがやりたかったんだよって感じで、とはいえまだ改善点がたくさんって、今の中の人達もわかってると思うけど、元中の人として dev.to ぐらいやるにはどうすればいいってのを残しておきます。 わかる変更点 CSSの脱bootstrap色が強くなった トップ画面が、ユーザーごとのカスタムフィードから beta版 の人気の投稿が主になった 元々そういう目的で企画を起こした記憶がある… フレンドフィードもうあんまり使われてないよね クエリが重いフレンドフィードより、静的にキャッシュできるランキングがトップにあるのはチューニングしやすい やや無理難題だったり、中の都合も察してるけど、できるだけ目視とDe
概要 パフォーマンスメトリクスの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
いわゆるサーバーレス。 TL;DR すべてのリクエストを Firebase Functions に流して next.js に食わせた結果を返すとSSRになる。最高。 概要 Firebase Hosting は index.html を上げたら動いてくれる静的サイトホスティングだと思っていたが、 全てのルーティングを Firebase functions に全て受けさせる。こともできた GCP知らない人向けに 一応解説しておくと Firebase Function = Google Cloud Function ≒ AWS Lambda そんでもって、React で SSR したいとき、スクラッチでもいいけど、一番簡単なのは next.js。next.js 公式にも exmaples があり、読んでみたら勉強になったので解説してみる。 Firebase Hosting の設定 { "func
対象 Rails だけどSPAっぽく画面遷移したい SEO担保しないといけない 新規設計の参考 jQuery まみれの状態からこれと同等のことをするのは、不可能じゃないけど難しいです。 単にどう導入するか知りたいだけなら https://github.com/mizchi-sandbox/packnova/commit/447a91ea3a706c0bb0aac8570d1fbbaf6c9710f1 のコミットで 目指したモノ 最小限の設定で Rails エンジニアでもメンテ出来るSSR/SPAアプリの土台。 ただし土台をハックし始めるとその限りではない。。 スタック webpacker でコンパイル 画面遷移は hypernova-react/turbolinks で自動再マウント ルーティングはRails側に寄せてます。なので react-router は入ってないです。 入れる選択肢
次のページ
このページを最初にブックマークしてみませんか?
『@mizchiのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く