議事録

config.js 内の localConfig の local は Express の locals 由来

• 過去の遺産である growi-context-hydrate は廃止したい→config.js内の local_configには新configは追加しない

• /attachment/list での res.query.limit は max を設定してバリデーション

  • api を curl で叩いたりする人はこの値で取得件数を指定している
  • pagination コンポーネントで今開いてるのと違うページをクリックした際(クリック前に表示してるリストのlimitの値(state管理されてるやつ)のも使っている(yusuketk)

• req.query.limit がなければ DB から limit 値を取得して利用する

• DBにも値がなかったらそのpaginationに適切なデフォルト値を指定する

swig は必要か

• htmlしか吐き出さない
• jsxとの併用をやめたい(テンプレートエンジンの重複)特にNext化した未来では
• Next化した未来ではそもそも swig は使えない

一部 Next 化するのは可能だが、それは微妙なので一気に変える予定(dev/5.0.x)(passport周り以外)

なぜ jQuery を使いたくないのか

• React, viewなどはシャドウDOMという設計図を基に実際にclientに表示するDOMを生成する
  • stateをウォッチし、変更があったらDOMを生成し直す
• jquery は出来上がった dom に手を加える
• bootstrap の内部では jQuery を使っている
• なので reactでできることはなるべくreactでやる、jQuery を使うべきかは都度考える

api

swagger 3.0 openAPI

• トップダウン

  • 設計書、仕様書からソースコードを生み出す
  • テストして通らなかったら設計書かソースコードを修正する
  • dredd, commity?(Jpnup)
  • jpnupはそもそも仕様書を書いてレビューが通ったらソースコードを書き始めるようにしている

• ボトムアップ

  • ソースコードを基に仕様書を書く
  • 開発中にソースコードと仕様書に乖離が起きるのが欠点
  • GROWIはこっち、ただ質の悪いやつ
    • 現状仕様書の信用性が低い
    • ciでテストはしてるけど構文エラーしかチェックしてない
  • 質の良いのはアノテーションを基に設計書を書くやり方
    • 自動生成
    • それでも乖離が起きる

• Ts.ED を使いたい！

  • expressのラッパーMVCフレームワーク
  • ただメインメンテナーが一人なのとスター数が少ないのが不安要素
  • apply-tsedは進めいてるがリファクタ量が多い...
  • とりあえずNext化を進めよう

IBM が採用してる roopback はあんまよくなさそう

• growi の middlewareに関して
  • Express は node の connect を使っていて middleware はそれ由来