はてなブックマーク

今回テストを考えたいのはこのように「関数を実行し」「その関数を実行したことによってDBのデータが正しく変わったこと」を確認したいケースです。なので、関数に対してテストコード内から参照できるDBインスタンスを渡してあげる必要があります。 このため、この記事では次の3つの事柄について考えていきます。 DBインスタンスをどう用意するか テストデータをどう用意するか 上記例のようにテストを実行するために前提として特定のテストデータが多々あるでしょう。これをどう用意すると良さそうかを考えます テストデータのクリーンナップをどうやって行うか ユニットテストで前提条件やテスト対象の関数内でINSERTされたデータは他のテストに影響を与えないよう消しておきたいです これをどのように行うかを考えます DBインスタンスをどう用意するか 大方針としては mock を用意するかテスト用にDBを立てるかのどっちかに

git clone https://github.com/kazuyaseki/react-figma-plugin-boilerplate.git <your project name> yarn or npm install yarn webpack:watch or npm run webpack:watch Figmaのプラグイン、テンションが上がるものなのですが、プラグイン自体がUIを必要とする & ある程度 Stateful なものな場合、命令的に作るのは耐えられない！という気持ちになりました。 なのでReactで開発できる boilerplate を作ってみたので、使い方をご紹介していこうと思います。 boilerplate の中身はこちらです。cloneしていい感じに使ってみてください。 https://github.com/kazuyaseki/react-figma-p

FirstViewにはいらんけど、スクロールして登場するまでにはなるべく存在してほしいみたいな画像があったので作ってみました。 正直こんな雑なやり方で合ってるのか分からんのでもっといい方法知ってる人がいたら教えてください頼みます。 import * as React from 'react'; type Props = { imgUrl: string; alt: string; }; export default function LazyAndPreloadImage(props: Props) { const [loaded, setLoaded] = React.useState(false); React.useEffect(() => { // preload しておく const img = new Image(); img.src = props.imgUrl; // 読み

useRef は元々あった createRef の hooks 版です。その名の通り、DOMに対する参照を持つために使われるのが主な目的です。 ですがそれ以外の用途にも利用することができます。 最初に私が知ったのはこちらのReact本体のドキュメントにも記されている「以前のstateの値を参照する方法」です https://reactjs.org/docs/hooks-faq.html#how-to-get-the-previous-props-or-state function usePrevious(value: any) { const ref = useRef(null); useEffect(() => { ref.current = value; }); return ref.current; } なにやら useRef で前回の値を保持しているようですね。それまで ref と

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 色々素敵な記事が既に存在してはいますが、自分自身の理解を深めたく、React FiberのFiberとはなんなのか勉強してみたものをまとめました。 尊敬の念を込めて、大変勉強になった素晴らしい記事たちを先に紹介しときます。 React Fiber現状確認 ReactはなぜFiberで書き直されたのか？Reactの課題と将来像を探る React Fiberアーキテクチャについて ###解説しないこと Fiber以外のReact ver.16以降での変更点 あくまでFiberとはなんなのかにフォーカスします。 (ただ個人的には render

こんにちは、こちらはGraphQL Advent Calendar 16日目です。 タイトルにある「スキーマファーストなForm Validation」とはなんぞやという話ですが、短く説明するとこんな directive を書いたとして input RegisterAddressInput { postalCode: String @constraint(minLength: 7, maxLength: 7) state: String @constraint(maxLength: 4) city: String @constraint(maxLength: 32) line1: String @constraint(maxLength: 32) line2: String @constraint(maxLength: 32) } サーバサイドはこの constraint を満たしていない

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

先日 react-redux の v7.1 の stable release で hooks に対応したAPIが入り界隈で話題になりましたね。(追加されたAPIの詳しい解説はこちら https://react-redux.js.org/api/hooks) 結構コンポーネント内からお手軽に参照できる感動を伝えている情報が多いのですが(実際私も感動の嵐です)、ここで改めて「なんで Container コンポーネントって必要なんだっけ？」と「hooks APIではどうやって Container コンポーネントを書くのか」を考えていきます。 なぜ hooks API になった今でも Container コンポーネントが必要なのか 始めにここで言う "Container コンポーネント" は 「Redux の Store から値を注入するためのもの(あとdispatch 関数)」という狭義の意味で

React hooks にはメモ化のための useCallback と useMemo という関数があります。 hooks を使い始めて、この二つの関数を知った私はこう思いました。 「え？無条件でパフォーマンス上がるんなら全部これで書くべきやん！」 と。 というわけで、しばらくそのスタンスで書いてきたのですが、果たしてこの「無条件でパフォーマンスが上がる」という前提は本当に正しいのか、というかそもそも"パフォーマンス上がる"とは具体的に何をしてくれるのかを理解せずに使っていたので、ここで「全て useCallback/useMemo で書く」という方針が正しいのか、それとも他の方針が存在するかを考えてみました。 大きく次の3つの観点で考えます。 パフォーマンス 可読性 バグの発生しやすさ 1.パフォーマンス 「そもそも useCallback/useMemo はパフォーマンス向上の用途なの

hooks を含んだ安定リリースが出て早1ヶ月ちょっと、私は先月から hooks を使い始めたのですが、よそ様のライブラリや自分のお手製 hooks で「これ便利やな〜」と感じたものを紹介していきます。 リファレンス リファレンスは最後に書くものな気がしますが、この記事は存在自体がリファレンスのリファレンスって感じの立て付けというくらいリファレンスが主役なので、最初に貼っておきます。 react-use GitHub - streamich/react-use: React Hooks — 👍 hooks の便利関数の寄せ集め系では一番スター数が伸びている気がする。お世話になってるし、色々着想も面白いと思います。 the-platform GitHub - palmerhq/the-platform: Web. Components. 😂 かのFormikの作者である Jared Pa

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 明けましておめでとうございます。 アニメーションの実装に抵抗を覚えている方、多いのではないでしょうか？ 特に昨今ではサーバサイド出身で最近フロントエンドを触り始めたという方も多いと思います。私が属している組織でもそんな流れは少なからずあるのですが、そういったバックグラウンドの方の声として聞くことが多い声はやはり「CSSは触りたくない、アニメーション怖い」というものです。 私も少し前まではちょっと複雑なアニメーションを見ると「えぇ…」と思っていたものですが、今ではCoolなアニメーションを見ると「どうやって実現しよう」とワクワクするように

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? メタ この記事はNode学園2018にて話した内容を記事として編纂 +その後の変化を加筆修正したものです。 スライドはこちら。 https://speakerdeck.com/kazuyaseki/seo-for-spa-cfb3706f-ae1d-4c6f-a83f-96dc2452f32b 追記 2019/5/8 遂に Google bot が扱うレンダリングエンジンが Chrome 最新版(現時点では 74)相当となりました！ https://webmasters.googleblog.com/2019/05/the-new-ev

(編集: React以外のライブラリで当てはまるか確認できておらず、主語がデカめなのでタイトルに"Reactの"をつけました) この記事はコンポーネント指向開発における、私が実際に産み出した/遭遇したアンチパターンをまとめたものです。 コンポーネント設計論はちらほら見かけますが、アンチパターン集はあまり見たことないなと思ったことと、実際の開発していくにあたってより具体的なアンチパターン例があった方が学びが捗るのではという思いからこの記事を書き始めました。似たようなコードを書いた時に参考になれば幸いです。また、絶対的な解があるものでもないと思っているので、より良い案などございましたらコメントいただけると嬉しいです。 なお、思いつきベースで書いているので特に網羅性はないです。 忙しい人のためのサマリ 中間のProp変化 あるコンポーネントが他のコンポーネントで何がどう表示されるかを知っているよ

タイトルだけだと何を言っているのか意味が分からないと思うのですが、最近ポケモン図鑑を作っていて、その過程で思いの外ポケモン関連のエコシステムが充実していたので、発見したものを紹介いたします。 ちなみに私はXYまでは全作プレイしてました。スプラトゥーン沼のせいで時間がなくなり卒業しました。(自慢ですがウデマエXです) データ系 まずは要となるポケモンデータを管理してくれているパッケージたちを紹介します。この分野は競合がたくさんいるのですが、私が見つけた中で一番筋が良さそうだったのはこちらです。 GitHub - fanzeyi/Pokemon-DB: A Pokemon database in JSON format. 次のそれぞれの要素に対してのJSONがあります。 ポケモン アイテム ワザ タイプ 例えば私はクチートが好きなのですが、クチートのデータはこんな感じ。 { "base": {

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Code Splitting、サボってきたのですが、必要になりそうだったので真面目に調べてみました。 これからCode Splittingやりたい方の入口的な役割になれれば幸いです。 Code Splittingとはなにか Code Splittingはその名の通り「コードを分割すること」を指します。分割されたコードはユーザのアクションに応じて非同期に読み込まれます。 ちなみにWebpackでentry point分けることとかもCode Splittingと言えばそうなのですが、本記事では触れません。また、別にSPAでなくともCode

コンポーネント指向での開発も割と枯れてきて、昨年から海外ではいわゆるデザインパターンに名前がついて紹介されることが多くなってきました。 この記事ではその内の一つ、Compound Componentsを紹介いたします。 またタイトルに「Reactの」とついてますが、実装例がReactなだけでコンポーネント指向であれば他のUIライブラリでも考え方は流用可能です。 完成した実装はここに置きました。 https://codesandbox.io/s/104lvmynj4 参考 Ryan Florence - Compound Components Advanced React Component Patterns Compound Componentsとは はじめに Compound という言葉ですが直訳だと動詞で 混ぜ合わせる という意味です。実際の実装は混ぜ合わせるというよりは「組み合わせる

こんにちは。いかがコーディングお過ごしでしょうか。 私は今更ながら最近GraphQLで遊び出し、そしてApollo Clientに出会いました。 ワクワクしました。「これは想像以上に既存のフロントエンドの設計・実装を変えるものだぞ！」と感じました。 「Apollo ClientってGraphQLクライアントでしょ？GraphQLエンドポイントない俺には関係ないな。」と思ったそこのあなた、それだけじゃないんですApollo Clientは！！！！！ 本記事では「Apollo Clientとはなんぞや」という話と「なぜ私がApollo Clientを布教したいのか」という点について語ります。実は最初は実装含めたチュートリアルを書いていたのですが長くなり過ぎたため記事を二つに分けました。この記事はどちらかと言うと概念系の話が多めで、片方にApollo Client + Reactのチュートリアル

こんにちは。 この記事ではGraphQLのクライアントであるApollo Clientの入門をReactをお供に書きます。日本ではVueが一番人口多いんじゃないかという気がしているのですが、Vueが人気過ぎてReactも盛り上げねば！という謎の使命感を感じているのでReactで書くことにしました。 ただ、Apollo Clientは他のUIライブラリでも利用可能で、また考え方とかは一緒なのでReact使わないという方もぜひ読んでいってください。 話さないこと 「入門」とついてるのでちゃんとGraphQLとはなんぞや、Apollo Clientとはなんぞやという点に対して言及すべきなのですが、これについては他の記事で書いたのでそちらをご覧ください。 世のフロントエンドエンジニア達にApollo Clientを布教したい バージョン情報 本記事内で使われている主要なパッケージのバージョンを記載

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ReactやVueなどコンポーネントベースで作っていくViewのライブラリが普及したことで、コンポーネント指向での開発が一般化してきた昨今のフロントエンドですが、このコンポーネントの設計に悩まれる方も多いのではないでしょうか。 コンポーネントをどの粒度、どんな状態で分割するのが良いのか、などなど、特にチームで開発する時に認識が揃っていないとカオスになりがちな部分であると思うので、自分なりの設計をする際の指針を言語化しようというのが本記事の目的です。同じように悩まれている方にも何らか示唆を提供することができたら嬉しいです。 想定読者 「コ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに 先日、無料で簡単にNode.jsアプリを公開できるサービス「Glitch」が話題になりましたが、Firebaseを使えば同じようなことが簡単にできます🔥 本記事では何かと便利なFirebase Hosting と Cloud FunctionsでNode.jsアプリ(HTTPリクエスト受け取って静的リソースとかJSONとか返すもの)を動かす方法をご紹介します。 こちらのFirebaseの中の人のチュートリアル動画が勉強になったのでそれをベースに解説してみます。 Firebase Hosting + Cloud Functionsを使うことのメリット 初めにどんなメリットがあるかを軽くご紹介します。 GoogleのCDNの恩恵が自動的に受けられる 後述しますが、動的コンテンツのキャッシュも簡単に作れるのでパフォーマンスの改善に利用できます デプロイが楽々、CLIから楽々できます

結論は「好みによる」となることが読めていますが、それでも比較してみたい。 どちらも「DOMと状態の関係性を表す」という役割は同じですが、それぞれどんなメリット・デメリットがあるかを考えてみます。 ※描画関数使う場合はみんなJSX使うよね？と思い込んでいるためJSX前提で話します。 そもそもの書き方の違い 初めに書き方の違いを軽く見てみましょう。 message という文字列を表示するだけの簡単なコンポーネントを書いてみます。 テンプレートで書く場合は下記のようになります。

こんにちは。転職によりReact畑からVue畑に乗り換えることになったフロントエンドエンジニアです。 Vueでも描画関数使ってればRender Propsも使えるじゃんと思ったところ、Vue.js 作者のEvan You曰く「Render PropパターンはVue.jsにおけるScoped Slotsと同じ」とのこと。 In case you are wondering what’s the equivalent pattern in Vue, it’s called scoped slots (and if using JSX it works the same as React) — Evan You (@youyuxi) 2017年9月25日 本当にそうなのか簡単な実装例を用意してみました。 Render Prop まず、そもそものRender Propを使う目的としては 「コードの

Firebase Advent Calendarトリなのに地味な内容で恐縮なんですが、Cloud Functions for Firebase(以下Functionsと呼びます)のデバッグ方法についてまとめてみました。 ログについて まず最初にFunctionsでのログの見方・出し方をご紹介します。 見方 以下の３通りの方法があります。 Webコンソールで見る functions:logs Stackdriverで見る 丸投げですがこちらのトピックに関しては既にAdvent Calendarに記事があったので貼っておきます。 Cloud Functions for Firebase のログをコマンドラインで確認する 出し方 そもそもFunctionsのログは関数が実行された時にデフォルトで いつ実行したか いつ実行が終了したか。終了するまでに何msかかったか ランタイムエラーが起きた時のス

概要 本日の予定を秘書が教えてくれたらうれしいですよね！ slackボットで作ってしまいましょう。 秘書の「秘書美」が、毎朝予定を教えてくれます。 GASでGoogleカレンダーの予定から今日の予定をピックアップし、Incoming WebHookで、slackへポストします。 GASを使うのでサーバーも特別に用意する必要がなく簡単です。 秘書美の作り方 slackのWebhook URLを取得 Integrations - Incoming WebHooks で取得。 「Post to Channel」は、適当なチャンネルでＯＫ。スクリプトでポストするチャンネルは指定できます。 「Webhook URL」：これをメモっておきます。 カレンダーIDの取得 Googleカレンダーの設定画面の「カレンダーのアドレス:」ってところに、カレンダーIDがひょうじされています。（xxxxxx@xxxx