yn2011's blog

技術メモ

Can't perform a React state update on an unmounted component... エラーにConetextが原因でハマった話

環境

  • react 16.8.6

事象

React.useEffectを使用しているコンポーネントContext.Provider配下に配置したところ以下のエラーが発生した。

Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function

コード例は省略するが、上記のエラー発生時にReact.useEffect内でAPIコール、その結果をsetState等すると何故かuseEffectの処理が無限ループする。

原因

本来はfunctional componentの外側でContextを定義するべきだが、以下のようにfunctional componentの内側で定義していた。

export const HogeContextProvider = (props: HogeProps) => {
  const HogeContext = React.createContext(null);
  return (...

以下が正しい。

export const HogeContext = React.createContext(null);

export const HogeContextProvider = (props: HogeProps) => {
  return (
      <HogeContext.Provider value={hoge}>
        {props.children}
      </HogeContext.Provider>
  );

functional componentの内側は、stateの更新等で何度もコールされるのでその度にContextを再作成していたことが原因の模様。

最初はContextをProvider配下でReact.useContextしていないことが原因かなと思って調べたら、そもそもContextをexportしていないことに気づいて、定義位置の間違いに思い当たった。

反省

DOMがstateに対応して更新されることは当然だが、functional componentの内部の処理が何度もコールされるイメージがなかった。どういうときにコールされるのか整理したい。

React、こういう単純なミスの原因特定が難しくてハマると解決に1,2時間ぐらいは必要になってしまうこともあり辛さがある。

Go modules利用時にvscode-goのinferGopathが無効化される理由

環境

事象

The "inferGopath" setting is disabled for this workspace because Go modules are being used.

原因

  • Go modulesを使用している場合は$GOPATHの設定が不要だから
  • Go modulesを使用する利点の1つは$GOPATHを通さず、$GOPATH配下外に作成されたディレクトリ上で外部の依存パッケージを扱えること
    • しかし、Goのimport$GOPATH/src$GOROOTからパッケージを探す仕様だったはず...
      • ちなみにgo.modが直下になるように$GOPATHを設定すると$GOPATH/go.mod exists but should notとエラーが表示される
    • 自分で定義したパッケージをimportするときはどうすればいいのか?

Go modules使用時に自分で定義したパッケージをimportしたい

その他

  • VSCodeでこの手の問題が発生すると、実際にGoが認識している$GOPATHVSCodeが認識しているものが違う場合もあり調査に手間がかかりがち(ちなみにVSCodeのコマンドパレットからgopathで検索するとVSCodeが認識ている$GOPATHが確認できることを今日初めて知った)
  • でもこれからはGo Modulesを使えば$GOPATHのことはあまり考えなくてもよくなるはず。めでたい。

使用しているAlfred Workflows一覧

環境

  • Alfred 4.0.3

Alfred Powepackを利用している場合は2台のMacでAlfredの設定を同期することも可能(ドキュメント)だが、1台からの片方向同期かつWorkflowsだけを同期するのは難しそうなので、業務で使用するMacとは手作業で同期を行うことにしようと思った。(JIRAチケットへのジャンプ等、業務でしか使わない設定も少なくないので...)

今後も良さそうなWorkflowsがあったら、このドキュメントに追加していく。

Workflows

github.com

github.com

github.com

github.com

(自作)フォルダを検索してターミナルで開く

  • filefilter(public.folder) → Browse in Terminal

Docker Compose上で起動したwebpack-dev-serverに設定されたプロキシが動作しなくてハマった話

環境

  • macOS 10.14.4
  • docker-compose version 1.23.2
  • webpack-dev-server 3.7.2
  • webpack 4.37.0

フロントエンド(webpack-dev-server)、バックエンドをそれぞれDocker Compose上にコンテナとして起動して開発していた際にハマったお話。

事象

  • webpack-dev-serverはホストするjs内で発行されるHTTPリクエストをプロキシすることができる

    • 今回なぜプロキシが必要だったかというと、Chromelocalhost上ではfetch('http://localhost')...のようにlocalhostに対してリクエストを行うとCORSエラーが発生するため
    • jsのソースコード上ではfetch('/api/hoge')..のようにしておいて、webpack-dev-serverにlocalhostへプロキシさせることによって回避できる。(他にもブラウザの設定を変更する等の回避策があるが、webpack-dev-serverに設定されている方が他の人に親切)
  • webpack.config.jsを以下のように設定(抜粋)

    • APIサーバーは5000番ポートを開いているとする
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    compress: true,
    port: 8080,
    historyApiFallback: true,
    proxy: {
      '/api': 'http://localhost:5000',
    }
  • 上記設定を反映したwebpack-dev-serverを起動し(docker-compose up)、実際にlocalhost:8080にアクセスしてfetch('/api')...をブラウザから実行すると、webpack-dev-serverが以下のエラーを出力した
[HPM] Error occurred while trying to proxy request /api from localhost:8080 to http://localhost:5000 (ECONNREFUSED) (https://nodejs.org/api/errors.html#errors_common_system_errors)
  • httpレスポンスは以下(抜粋)
504 Gateway Timeout

Error occured while trying to proxy to: localhost:8080/api

原因

  • Docker Compose上のコンテナが参加するネットワークでは、docker-compose.yml上のサービス名で名前解決が行われるため。

  • 従って、webpack.config.jsを下記のように書き換えると上手くいく

...
 proxy: {
      '/api': 'http://api:5000',
    }
  • なお、docker-compose.ymlでは以下のようにサービス名をapiとしている
version: "3.4"
services:

  api:
    build:
      context: ./api

...

敗因

  • 書いてみるとこれだけのことだが、多分2,3時間ぐらいハマっていた
  • サービス名で名前解決ができること自体はDocker Composeのドキュメントに書いてあることだし、以前から知っていた。なぜ気づけなかったのか...
    • 多分だが、ブラウザからDocker Compose上のwebpack-dev-serverにアクセスする際は、
      • localhost:8080をDocker Composeのポート8080と接続していて
      • かつ実際にクライアントサイドのjsが動作しているのがローカルだし
      • バックエンドのapiサーバーもlocalhost:5000とDocker Compose上の5000を接続していた
    • のでwebpack-dev-serverが動作しているのがDocker Compose上であることを忘れていたというか、しっかり認識できていなかったような気がする。
    • また、Docker Compose上のネットワーク内のコンテナ間もlocalhostで通信できるようなイメージだったのも原因かもしれない。
  • あと、ステータスコード504 Gateway Timeoutの理解が不足している感もある。webpack-dev-serverがlocalhost:5000が存在しないためにレスポンスを得られない→ポート5000で動作しているはずのHTTPサーバーのログを確認する→ログがない→接続先がおかしい?というような手順をスムーズに踏めたら良かった。
    • Goで書いているHTTPサーバは外部ファイルへのログ出力を未実装で、結局調査のために書いたんだけど、ここを面倒くさがらずに早く実行するべきだったかな...

github.com

bashコマンドは読取権限のあるファイルなら処理できる

環境

Permission denied

  • $ touch hoge.sh && ./hoge.shするとbash: ./hoge.sh: Permission deniedになる
    • 実行権限がない
  • しかし$ touch hoge.sh && bash hoge.shは正常終了するのはなぜか?

読取権限

  • $ chmod u-r hoge.shして所有者の読取権限を剥奪するとbash hoge.shbash: ./hoge.sh: Permission deniedとなる
  • bashコマンドはファイルから読み取った内容をbashコマンドが実行しているのに対して、.コマンドはファイルから読み取った内容を実行する際にOSの実行権限が必要になっている模様(推論、あまり詳しくないので違っていたら教えてください)

httptest.Serverとhttptest.ResponseRecorderの使い分け

環境

go1.12.4 darwin/amd64

httptest.Serverとhttptest.ResponseRecorder

httptest.Server

  • httptest.Serverは外部のHTTPサーバと通信を行うコードをテストするために利用する(外部APIの挙動のエミュレート)
    • クライアント-サーバモデルで言うと、テストしたい対象がクライアントの場合に相当する模様

httptestパッケージより引用

package main

import (
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
    "net/http/httptest"
)

func main() {
    ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello, client")
    }))
    defer ts.Close()

    res, err := http.Get(ts.URL)
    if err != nil {
        log.Fatal(err)
    }
    greeting, err := ioutil.ReadAll(res.Body)
    res.Body.Close()
    if err != nil {
        log.Fatal(err)
    }

    fmt.Printf("%s", greeting)
}

httptest.NewRecorder

  • httptest.NewRecorderは純粋にHTTPリクエストに対するハンドラーの動作をテストするために利用する
    • 例えばHello worldを返すだけのWebサーバのコードを書いた場合のテストコードはhttptest.NewRecorderで十分

httptestパッケージより引用

package main

import (
    "fmt"
    "io"
    "io/ioutil"
    "net/http"
    "net/http/httptest"
)

func main() {
    handler := func(w http.ResponseWriter, r *http.Request) {
        io.WriteString(w, "<html><body>Hello World!</body></html>")
    }

    req := httptest.NewRequest("GET", "http://example.com/foo", nil)
    w := httptest.NewRecorder()
    handler(w, req)

    resp := w.Result()
    body, _ := ioutil.ReadAll(resp.Body)

    fmt.Println(resp.StatusCode)
    fmt.Println(resp.Header.Get("Content-Type"))
    fmt.Println(string(body))

}

関連:NewRecorderを利用する場合にserveHTTPを使用する必要があるのか

  • http.HandlerFunc(articlesHandler).ServeHTTP(rr, req)してレスポンスを検証している例もある
  • マルチプレクサ経由でhandlerを呼び出している(HandleFuncはマルチプレクサ(ServeMux)を返し、ServeHTTPはマルチプレクサに登録されているパターンにマッチするハンドラを呼び出す)
    • 結局テストコード中でハンドラを登録しているなら初めからServerを使うか、ハンドラの処理だけにフォーカスするかした方が良いのではないか?(Goのhttpパッケージをテストしたいわけではない)

参考

draw.ioで両端が矢印の線を引く方法

www.draw.io

AWSの構成図をdraw.ioで描いていて、両端が矢印の線を引く方法が分からなかった。もう諦めてCacooを使おうかと思っていたところ解決策が見つかった。

How to create a bidirectional arrow? : draw.io Helpdesk

ちなみに上記で操作しているサイドバーはcmd+shift+pで表示できる(Macの場合)