2021-07-15Movidea開発日記

今日の一枚

https://gyazo.com/f9a4189bcd971734620945f7183cf949

---

ダイアログは一度に一つしか出ないので個別にbooleanで管理するのではなく名前で管理するのが良いと思っている

type TDialog = "" | "AddFusen";

code:ts

const AddFusenDialog = () => {

const open = dialog === "AddFusen";

const onClose = () => {

setDialog("");

};

return (

<Dialog open={open} fullWidth={true} fullScreen={true} onClose={onClose}>

...

code:ts

describe("dialog", () => {

beforeEach(() => {

cy.visit("/");

});

it("main", () => {

cy.contains("Add Fusens").should("not.exist");

cy.updateGlobal((g) => {

g.dialog = "AddFusen";

});

cy.contains("Add Fusens").should("exist");

cy.contains("Close").click();

cy.contains("Add Fusens").should("not.exist");

});

});

https://gyazo.com/6fa5fa28fab0b1e9e78a9b30fca053d6

ところでユーザに見せる名前をFusenにするかどうか

前の実装ではPieceだった

Postitは他社の商標なので嫌

StickyNoteは長い、Stickyにするとネバネバしてそう

Stickerだと絵が描いてありそう

などもあって、日本語で押し通そうかと思ってる

白い背景「ホワイトボード」というとペンで書きそう、「キャンバス」はカラフルな絵を描きそう、という話

これもいっそ「場」でいいのでは

Kozane / Ba

いっそアプリの名前自体Kozanebaでいいのでは

メニューバーに貴重な画面スペースを独占させない強い意志…

https://gyazo.com/0a5cfb1157c2875f6c50634f86d5fc0f

もっと透明度を上げたい、背景色をもっと濃くすればいいのか？

メニュー

Document

コンポーネントのローカルの状態に依存してるのだが、各メニューボタンのハンドラとかを別のモジュールに括り出した時に厄介

前回は「処理が終わったら閉じる」ラッパーを作ったが…

そもそもメニューもダイアログ同様に一度に一つか？

子メニューがあり得る

その場合に親の選択肢を出し続ける意味はないのだからやはり一度に一つで良いのでは？

付箋にもメニューがでる

しかし出る場所が微妙に気に入らない

https://gyazo.com/c79a4a3216318e9d909e8e0205252f73

気に入らないので直した

これがデフォルト挙動であるべきなのでは感

メニューを表示する位置を指定することができないので見えないdivをマウスの位置に動かしている

https://gyazo.com/a909ecdb82f6a283d68e3aceafb239c4

ＫＪ法...複数の人たちの「衆知をあつめる」法として、おおいに評価されて、各種の企業でも実用化されているようだ。わたしがここに紹介したこざね法というのは、単数個人用の、いわば密室むき知的生産技術であって、川喜田君の体系でいえば、比較的素朴で、初歩的な技法に属する。かれの体系のなかでは、「ＫＪ法Ｂ型による文章化」とよばれているものと、ほぼおなじである。

drag/drop

https://gyazo.com/b3f4995d67a2b56470437e07168cb5de

ドラッグドロップができた

ただしドラッグ開始時に掴んだところがどこであるかと無関係にドロップ位置に中心を移動させてしまうので、開始時にズレを記録しておいて補正してやる必要がある

スクリーン座標系とワールド座標系との変換を一旦真面目にテストして作った方がいいかもなー

きっとこれに限らず色々なところで使うはずだし

座標系変換を実装したがテストが難しい。下記ではダメ

code:test.ts

cy.testid("2").should(

"hasPosition",

);

なぜなら時刻T1で座標変換が先に処理されてしまうから。後から非同期でリトライをしても「目標とすべき値」は先に計算して固定されてるので意味がない。

code:test.ts

cy.testid("2").should(

"hasPosition",

T1

);

座標計算自体をリトライさせるには…と、考えてthenの中に入れた

code:test.ts

cy.testid("2").then((el) => {

return cy

.wrap(el)

これでも直前の状態更新が非同期だとうまくいかない、デフォルト非同期にしてたが、デフォルト同期にして非同期が必要な時だけオプションで指定することにした、なぜか同期でもテストは全部通った。

翌日の追記

これ、良く考えると画面の描画も座標変換も両方とも「現在の状態」に依存するものなのが原因なので、座標変換に必要な値を全部明示的に渡すピュアな関数があればよかったのでは

中央以外をつかんでドラッグするテスト、2回目のドラッグだけ不可解なズレが発生したり、元に戻るはずの中央ドラッグで全然元に戻らなかったりする

Cypressでドラッグのテストしてたら不可解な位置ずれズレが発生してどういうことかと気になってたんだけど、これおそらく「画面外に一部はみ出す位置」にドラッグで移動した後、次にドラッグする時にCypressのUIが対象を表示しようとしてスクロールしてしまうせいで座標がズレてるんだな…

つまりoverflow: hiddenでwheelイベントがpreventDefaultされてるアプリにおいてもCypressはドラッグ対象を表示しようとしてスクロールしてしまうのでclientXではなくpageXを使うべきだったということか

あれ、違うな…。その修正をしても「不可解な挙動」は再現する。

とりあえずはみ出さないテストケースでは期待通りに動くことがわかったので、はみ出した時の挙動は現状の挙動を記述したものとして分離しておこう。

この件、手ではみ出すパターンの操作をしたけど問題なく期待通りに動作したので僕の書いたアプリを人間が使う上では問題はなくCypressが使うと変な挙動になるってだけなのでスルーすることにした。

中央以外を掴んでドラッグができるようになった

https://gyazo.com/f9a4189bcd971734620945f7183cf949

最初一回空振りするのはウィンドウにフォーカスが当たってなかったせい