nazo/Nuxt.js 1.x.md

## Nuxt.js 1.x.md

      
    Raw
  

              Nuxt.js 1.x.md
            
          
nuxt.jsめっちゃいいじゃんって思ったところで、これに合わせるサーバーサイドAPIを書くのに何使うといいんだろうなーってなっている。好きなのでいいといえばそうなんだけど…
vuexのmutationsの呼び出しが文字列だから定数にしろというのはわかるんだけど、現代的なJavaScriptなら変数は大体constだから、それだけをUPPER_SNAKE_CASEで書く必要はないんじゃないかと思う
ssr.vuejs.org/guide/universal.html#component-lifecycle-hooks … これを読む限り、SSRでのAPIリクエストはサーバーサイドとクライアントサイド両方からを想定すべきって感じじゃないのかなぁ

axios-moduleもbaseURLとbrowserBaseURLの両方が同時に指定できるわけで、そうなるとやはりクライアントからAPIを呼ぶことも想定される https://axios.nuxtjs.org/options.html


nuxtのaxios-module使うとクライアントのリクエストヘッダがサーバー側でそのままコピーされるからcookieとかAuthorizationヘッダとかそのまま使えるのねなるほど
nuxtのtypescript化、vueとかnuxtがきついというよりも、loaderとかそもそもtsの挙動ちゃんと把握してないと無理だよねってなる。vue-cliで組み立てたほうがやりやすいんじゃないかな
Vueわかってる前提でNuxt触る場合にまず頭に入れないといけないところってこんなところかなぁって感じ。axios-module使うとSSR動作が自然すぎてよくわからなくなる
nuxt-class-component使った時にlayoutとかmiddlewareってどこに書くのが正解なんだろう？@ Component内に書いても動くっぽいけど定義的には間違ってるっぽい…

this.$routerとかも無いって言われるけど、コンポーネントクラスの基底のclass Vueって素のvuejsだから無いの当然だし、そう考えるとビルド方法の問題なのかな…
import 'vue-router/types/vue' だった。TSよくわかってないだけだった


noImplicitAny=trueにしたら@nuxtjs/axiosがany入ってるからダメだよって言われるんだけど、みんなそこまで設定しないもんかな？
strict=trueにnoImplicitAnyも含まれるのか。個別に設定したほうがよさそう。noImplicitAnyは無理そうだからそれ以外だけtrueにする感じかな
TypeScriptのstrict=trueに含まれる内容はバージョン上がる毎に増えてるっぽいので、struct=trueで不要なものだけfalseにする運用だと設定が増えても勝手に対応してくれる一方で、バージョン上げた時に勝手に新たな設定が増えることがある、って感じかな？
Nuxtでclass componentでTypeScriptで揃えると、これもしやAngularでいいのでは？とも思える