新規作成画面をなくすと考慮事項が激減して嬉しい

例えば CMS の管理画面を考えます。 /posts に記事一覧画面、/posts/new に新規作成画面、 /posts/:postId に記事更新画面を置くような URL の設計はあるあるかと思います。 今回は /posts/new の画面はないほうが色々嬉しいと思った話をします。 新規作成画面があることで増える考慮事項 まず新規作成画面があると、どんな煩わしさがあるかを考えます。 下書き保存した時、どうする？ 新規作成画面で下書き保存をすると、内部的にはリソースの ID が採番されます。つまり下書き保存した段階で、それは記事更新画面になるはず。 その ID で URL を /posts/:postId に書き換えるかどうかを検討します。 筆者は React 一辺倒人間なので React 寄りの話にはなりますが、Next.js や React Router などでは /posts/ne

[jay-es]

新規作成ボタンで新しいデータを作ってしまいすぐ編集画面に遷移させれば、新規作成画面やフォームでの分岐（新規・既存の処理分け）もなくなる。適用できないケースも多そうだけど試してみたい

[atsushifx]

バックエンド側だからかもしれないが。状態管理の話なので、Viewである画面じゃなくて、ModelかContorllerで考えるべきではという感じだった。

[zentarou]

「新規|更新」時だけ「必要|不要」な項目が出てくるのよね。下書き保存とそれ以外じゃバリデーションの厳密さも違う。

[Sephy]

システム全体の設計次第だよね。例えば新規記事の通知とか作成をキャンセルした場合に空記事削除するかとか削除データの取り扱いとかシステム全体で見た時に何が効率的かっていう判断ができるならいいと思う

[dagama]

ユーザーは記事書こうと思ったらブクマしといた新規作成画面に飛んですぐ書き始められてたところを、一覧画面に飛んで新規作成ボタンを押さなきゃいけないとなるとワンアクション増えるわけで議論が必要になりそう

[hirata_yasuyuki]

draftのフラグ付けて途中の状態を保存出来るようにするとさらに嬉しいやつ。

[umai_bow]

DB側は素直にやるとNOT NULL制約とか付けづらくなって辛そう

[mizchi]

実際複雑化してるのは見たことあるけど、フロントエンド的にはコンポーネントの再利用性の抽象に失敗してるだけで、最初から意識できてたらどっちでもいい

[wwolf]

"/posts/new"みたいなのはHTTPというステートレスなプロトコルを前提としたREST原則のお約束として発生しただけだから、フロントで状態を管理するなら別にいらないよね、は正しい

[yo_waka]

フロントの作りやすさと下書き機能の開発コストとユーザの使いやすさのバランスで決めるやつ

[s17er]

属性の型が全部一致しててもNull制約の差があるなら別エンティティにしたほうが良さげな感じする

[shingo-sasaki-0529]

これは本当にわかる。新規じゃなくて空のデータを編集するって考えるだけでスッキリする。 ただユーザーから見ると画面遷移しただけデータがsubmitされるの気持ち悪いし、運用観点ではゴミデータが溢れやすくなるよね

[nodoca_engine]

ユーザーがうっかりゴミデータ（空の下書き）を作ってしまう可能性と、DBにそのゴミデータが入ることを許せるならって感じだ。

[hachibeechan]

もうちょい戦略的な話なのかと予想して読んでみたらNext.jsの弊害って感じの印象を受けた

[momonga_dash]

Notionはこれだな。なんならシステムレベルの下書きフラグも無い。慣れるまで時間かかった。

[knjname]

クライアントでID（UUID）採番・ドラフトをローカルでキャッシュとかはある　あとは基本的に更新新規の区別がなく更新ベースでしか考えないモノとかそういう対象もある（MERGE文でまくり）

[kagehiens]

「下書きデータ作成した」と「下書きデータから編集保存する」なら使ってもいい！！みたいな。内容にはおおむね同意。なお伝票番号いつ採番するの問題として25年前からあるよね、これ。もっとかな。

[uzuki05]

作成時だけ適用したいバリデーションやnullableな列作りたくないとか気になることはあるけど、そこらへん設計でシンプルに解決できるなら、確かになぁと思いました

[nemoba]

よくあるステート管理を別の場所に追い出して、そこは楽になったて奴。newのステート管理は嫌なのに、draftのステートはシンプル思うのが、局所最適化起こしてる。冪等データフェッチが暴走してそフロントエンド界隈

[door-s-dev]

サーバ側の実装も考えたうえで楽になるかがパッとは分からないな。記事一覧の新規作成ボタン以外から記事作成したいケースがあると逆に面倒になりそうな？

[masatomo-m]

下書きと確定済みのデータでやりたい事が違うなら、それは多分ドメインモデルの見落としがあるんじゃないかなあ

[yarumato]

“/posts/new の画面はないほうが色々嬉しい。いきなり /posts/:postId に遷移するのです。その記事投稿画面が新規作成用なのか既存更新用なのか区別する必要がなくなり、ステート管理が楽になります。”

[forest1040]

なるほど

[prograti]

NOT NULL制約は検査制約（CHECK）で対応は可能ですね。少々複雑になりますが

[clockwork9]

postIdをクライアント側で採番出来る設計ならありだと思う。

[taruhachi]

DBにまで透過させなきゃどっちでもいいかな。セッションまでならサーバーに届いてもいい。

[twotiger]

そうだよね。NOTNULL制約をどうするの？っていうのが一番大きいと思う

[sd-craft]

DraftとPublishedは似て非なるものなので何も考えずにやると低凝集になって火傷するよ

[dec123456789]

ユーザーにとってどっちが使いやすいかという点が一番重要だと思うのは俺だけか

[Fluss_kawa]

設計次第だけどURLはサーバ側のリソースの状態を表してるのであればnewでリロードしたら消えてしまってもいいし、下書き保存したらdocIDを、発行してURLに含めるべきだしと思う。

[koduki26]

話は分かるんだけど作り手側の問題を操作性に関しては慣れてもろたらええやろで片付けるのはどうなんかな…と思っちゃった

[kazuppo01]

これ以前管理画面を作る時に似たようなことを考えてシンプルで良かった記憶。 分かりやすく言語化されてて嬉しい。

[lenore]

昔使ってたplone のファイルアドオンがその挙動でplone 自体と統一感が無かったためゴミデータを産出する元となってた。全体の設計が出来てたらアリ

[yetch]

「新規の時と編集の時の挙動を変えたい」設計があっても後で「なんでこっちでは出来ないの？」とか言い出すから基本を同じにしておくのは良いかも