Conversation
|
以下pizzacat83の構想です。 1.
2.
3.私がやってもいいですが, @Szkieletor37 さんがやりたいとかだったらお譲りします。 |
|
1,2 pizzacat氏の案に賛成します 3, 体調がアなため @pizzacat83 氏がやってくれるならありがたい 4, ミュートタグを個々の判断で勝手に入れてもいいのか、ガイドラインを決めて運用するのかを決める必要があると思います |
|
4,論点に追加しました(ついでに4のindexがどんどんずれていくことに気がついたので-1にしました) 4はTSGerの良心に任せればまあええんちゃう〜と思っています。pizzacat83の2. なら更新自体の通知は来るため知らないうちにミュートということは起きないので,ミュートすべきかで人々の判断基準がずれていたらその時議論してくれればいいんじゃないかな〜(未来に丸投げ) |
|
え〜実装方針案ふくめ構想もとてもよさそう〜楽しそう〜〜 1, む、 4, TSGerはみんな良心の塊だからね!大丈夫なんちゃう!まぁでも「ガイドラインは今はありません、勝手にやってください、議論の対象になることはありますが咎められることはありません。」というガイドラインを書くべき説がある? |
This comment has been minimized.
This comment has been minimized.
|
だいたい実装し終わったので,テストを書きます |
Codecov Report
@@ Coverage Diff @@
## master #229 +/- ##
==========================================
+ Coverage 27.58% 28.26% +0.68%
==========================================
Files 84 87 +3
Lines 6957 7029 +72
Branches 1343 1359 +16
==========================================
+ Hits 1919 1987 +68
- Misses 4393 4395 +2
- Partials 645 647 +2
Continue to review full report at Codecov.
|
This comment has been minimized.
This comment has been minimized.
|
うおお 結構時間かかってしまった:ojigineko-superfast: 2.本文を上書きするのに加えて,画像とサムネを消すようにしました。 既存のコードの変更点元からあったunfurlのコードと共通化できそうな部分は共通化しました。あと手元で動かすのが辛かったのでScrapboxのProject名は直書きせず環境変数を使うようにしました。 Merge時に必要な処理
|
|
今更読んだんですけどめちゃくちゃ良さそう!!!! 今出てる案に全面的に同意です! 一つ提案なんですが、Slack 通知の時、アイコンを更新者のアイコンにしませんか? |
scrapbox/index.test.ts
Outdated
| expect(attachments_res.length).toBe( | ||
| sum(separatedAttachments.map((a, i) => isMuted[i] ? 1 : a.length)), |
There was a problem hiding this comment.
attachments_res のテストが配列長だけで雑だなあとは思っている
|
またしても時間がかかってしまった:ojigineko-superfast: 前回レビューからの変更点
前回レビュー時点での既存のコードの変更点
Merge時に必要な処理
ほぼ0からの再レビューって感じだと思いますがよろしくお願いします:ojigineko: |
hakatashi
left a comment
There was a problem hiding this comment.
鬼のように実装しててやべーーーーー開発力の塊???????????
いろいろコメントしたけど、大きな問題は無いと思います!
| * 単体テストでexpectの失敗などによる例外をJestが検知することができない | ||
| * 発生した例外は全て再送出するように設定 | ||
| */ | ||
| fastify.setErrorHandler((err) => { throw err; }); |
There was a problem hiding this comment.
[question] うーむ⋯⋯⋯⋯ fastify, ルートハンドラがthrowした場合はちゃんとinjectの結果をrejectしてくれると思ってたけど、どうだろう⋯⋯? (実際にこの行をコメントアウトしてもfastify.test.tsのテストが通る)
There was a problem hiding this comment.
びっくりしているんですが,上にある throw Error をコメントアウトしても通っていて,少なくともテストコードはバグっています:ojigineko-superfast:
There was a problem hiding this comment.
え〜この行無くても動くな どうして昔握りつぶされてInternal Server Errorしてたんだ??????
| }); | ||
|
|
||
| describe('methods', () => { | ||
| let page: Page | null = null; |
There was a problem hiding this comment.
[question] strictNullChecksが入ってないので現状意味のない指定だと思いますが、大丈夫ですか
There was a problem hiding this comment.
将来誰かがstrictNullChecksをしたくなった時用に lib/scrapbox.* はstrictNullChecksでも通るコードになってるんですが,どこかにその旨書いた方がいいですかね
There was a problem hiding this comment.
なるほど、まあ意図があるなら大丈夫だけど、現状のプロジェクトの設定では検証できない制約をソースコードに課すのはあまり良くない気もする
|
む 前回テスト時からScrapbox通知の形式が変わった気がする 調査します |
|
これどうしたらいいですか、approveすればいいですか、すればいいならします |
|
ぐえ 私がレビューに対して修正をしていないという認識です… |
|
無言で放置しておくのはよくないという気持ちになったので書いておきます たぶん私はこのPRに手をつけません (100%とはいえないが) タスクの残り:
|
|
そこそこのモチベーションあるので気が向いたら引き継ぎます。動き始める時はここで宣言しますね。(それまでに誰か開発したい人が現れたら譲ります) |
|


writeupなどネタバレを含むページの更新通知が #_scrapbox に流れてくるのがつらいので,指定したページは更新されても通知が来ないようにする
実装
記事が更新されるとScrapboxから指定したURLにWebhook向け形式のJSONが送られてくるので,送信先をSlackではなくTSGサーバーに設定してScrapboxから更新通知を受け取る。
TSGサーバーは更新されたページそれぞれが「ミュートしてほしいページ」かどうか判定し,そうでないもののみ更新通知を #_scrapbox に投稿する。
論点
Scrapbox通知をいじるのは割とTSGersに影響があると思うので,Slackbot民に限らず広く意見を募集します。
1. ミュートしたいページをどう指定するか
2. ミュートされたページの更新はどのように通知されるべきか
更新の内容は見たくなくても,更新されたという情報は欲しい場合がある
3. 誰が実装するか
4. ミュートタグのガイドライン
誰でもつけ外ししていいものなのか,それとも。
-1: 他に論点はないか