- 投稿日:
ReactでSPAを組んでいてブラウザバックしたときのフォームの入力内容が消し飛んで気になったので、ブラウザバックした時にどうなるのかというのを軽く調査した結果
確認したパターンとしては次の2つ
- フォームの入力値をDOMに保持させるステートレスな方式
- フォームの入力値をJSに保持させるステートフルな方式
LocalStorageに画面情報を保存して復元するとか、条件分岐を使ってDOMを隠して保持させるとか、そういう系は考慮しない
結果
DOM 保持 | JS 保持 | |
---|---|---|
SPA 内ブラウザバック | 消える | 保持される |
SPA 外ブラウザバック | 保持される | 消える |
コード記述量 | 少ない | 多い |
1. フォームの入力値をDOMに保持させるステートレスな方式
この方式だとhistory.push()
でDOMが消し飛ぶのでSPA内でのブラウザバックで入力したデータが保持されません
その代わりSPAの外、別のサイトに遷移してからブラウザバックしたときは、DOMが残っているので入力したデータが保持されます
2. フォームの入力値をJSに保持させるステートフルな方式
この方式だとJSでステート管理をしているため、history.push()
で遷移してDOMが消し飛んでも、 defaultValue
に持ってる値を突っ込んであげれば、取り敢えず入力したデータを保持することが出来ます
反対にSPAの外、別のサイトに遷移してからブラウザバックしたときは、メモリの中身が飛んでるので入力したデータが保持されません
各手法の実装方式
ちゃちゃっと書いたのでコードは超雑です
確認環境
Env | Ver |
---|---|
react | 17.0.2 |
react-dom | 17.0.2 |
react-router-dom | 5.2.0 |
1. フォームの入力値をDOMに保持させるステートレスな方式
大正義ステートレスです
Function Componentはステートレスなので、こうあってほしいですよね~
コードもシンプルで管理しやすいのが素敵なところです
export const StatelessPage = () => {
const history = useHistory();
return (
<div>
<form>
<input type="text" />
<button onClick={() => history.push(AppRoute.dom2.path)}>submit</button>
</form>
</div>
);
};
2. フォームの入力値をJSに保持させるステートフルな方式
ギルティなステートフル方式です
Class Componentを捨てたはずなのにどうしてこうなった…
コードが煩雑で管理が大変です
export const StatefullPage = () => {
const ctx = useContext(ExampleContext);
const history = useHistory();
const onChange = (ev: React.ChangeEvent<HTMLInputElement>) => {
ctx.text = ev.target.value;
};
return (
<div>
<form>
<input
type="text"
defaultValue={ctx.text}
onChange={(ev) => onChange(ev)}
/>
<button onClick={() => history.push(AppRoute.ctx2.path)}>submit</button>
</form>
</div>
);
};
- 投稿日:
スプレッド演算子で引き渡した内容の内、一部だけを利用するケースを想定
サンプルコード
検査対象
type FooBar = {
foo: string;
bar: number;
};
/**
* `foo` と `bar` しか使われない関数
* @param arg
*/
export const spreadExample = (arg: FooBar) => {
return new Promise((resolve) => {
resolve([arg.foo, arg.bar]);
});
};
テストコード
import * as spex from '../spreadExample';
const spiedSpreadExample = jest.spyOn(spex, 'spreadExample');
describe('spreadExample', () => {
it('example', async () => {
const test = {
foo: 'hoge',
bar: 123,
baz: true, // 今回の課題となる項目
};
// 余計な `baz` が流し込まれているため、
// 普通に検査しようとすると `baz` が邪魔で上手く行かないケース
await spex.spreadExample({ ...test });
expect(spiedSpreadExample).toBeCalled();
// コールバックで `expect.objectContaining()` を呼ぶことにより
// 見たい項目だけを検査することが可能(`baz` を見なくて済む
expect(spiedSpreadExample).toHaveBeenCalledWith(
expect.objectContaining({
foo: 'hoge',
bar: 123,
})
);
});
});
- 投稿日:
単体テストの観点でいうとprocess.argv
そのものはモックしないほうが良いと思っているので、本記事ではprocess.argv
自体をモックする方法と、それを回避する方法を紹介する
サンプルコード
正攻法
describe('example', () => {
afterEach(() => {
// 元に戻しておく
process.argv.length = 2;
});
it('got first param', () => {
process.argv.push('param1');
expect(process.argv.length).toBe(3);
expect(process.argv[2]).toBe('param1');
});
});
そもそもモックせずに済むように設計する
process.argv
を利用している関数でprocess.argv
を引数に取ればモック不要となる
const getArgv = (argv: string[]) => {
// some procedure
}
describe('getArgv', () => {
it('got first param', () => {
const argv = [,, 'param1'];
expect(argv.length).toBe(3);
expect(argv[2]).toBe('param1');
});
});
- 投稿日:
フックを単体でテストするケースを想定。
このパターンはコンポーネントからフックを切り離しているケースで有用。手法としては@testing-library/react-hooks
のrenderHook()
を使う。
例
カスタムフック
export const useUserForm = () => {
const [username, setUsername] = useState('');
const [password, setPassword] = useState('');
const onChangeUserName = (ev: string) => {
setUsername(ev);
};
const onChangePassword = (ev: string) => {
setPassword(ev);
};
return {
username,
password,
onChangeUserName,
onChangePassword,
};
};
テストコード
it('onChangeUserName で username が設定されること', () => {
// `renderHook` で Hook をレンダリング
const { result } = renderHook(() => useUserForm());
// `act()` で Hook のイベントを叩く
act(() => result.current.onChangeUserName('foo'));
// 結果を見る
expect(result.current.username).toBe('foo');
});