Name: ビューSFCの正しいタグの順序 (The CORRECT Tag Order in your Vue SFCs)
Uploaded: 2025-01-27T09:36:16.000Z
Duration: 9 min 45 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

Hey everybody, welcome back to the new videos channel and today we look into the best order of the tags in your Vue single file components.

皆さん、こんにちは！新しい動画チャンネルへようこそ！今日は、Vueの単一ファイルコンポーネントにおけるタグの最適な順序について見ていきましょう。

As we all know, single file components are the main way to write components in Vue.js, except when you need multiple components in one file, then we can talk about libraries like Vue Wine, where I've talked about in a video last year, so take a look if you're interested in that.

ご存知のように、Vue.jsでコンポーネントを書くには単一ファイルのコンポーネントが主な方法です。ただし、複数のコンポーネントを1つのファイルに記述する必要がある場合は、Vue Wineのようなライブラリを使うことができます。Vue Wineについては昨年のビデオで紹介しましたので、興味のある方はご覧ください。

But sure, if you have a script tag and only use it for progressive enhancement, it might not be that easy to use a single file component, especially if you don't have a build step, then it won't work, but commonly, especially if you build your whole frontend in Vue or Nuxt, then SFCs are the way to go.

しかし、確かに、スクリプトタグを持っていて、それをプログレッシブ・エンハンスメントのためだけに使うのであれば、単一ファイルのコンポーネントを使うのはそれほど簡単ではないかもしれません。

And these .vue files have a specific beauty because, well, we can put our styles, our script logic and our templates in three different parts, they still belong to the same component and there are lots of discussions about separation of concerns, but we'll skip that here.

この.vueファイルには独特の美しさがあります。スタイル、スクリプト・ロジック、テンプレートを3つの異なる部分に配置しても、同じコンポーネントに属するからです。

We really talk about the order of which these tags appear in the single file components because that changed over the while.

私たちは、これらのタグが単一ファイルの構成要素に現れる順番について本当に話している。

So commonly nowadays, a lot of people have strong preferences and, well, there are two of the common choices, I would say.

だから今、多くの人が強い嗜好を持っていて、一般的な選択肢は2つあると思う。

So let's start with the more traditional one.

では、より伝統的なものから始めよう。

Traditionally, Vue, especially Vue 2, had always the template tag on top and that kind of makes a lot of sense.

伝統的に、Vue、特にVue 2は、常にテンプレート・タグが一番上にあり、それは非常に理にかなっている。

We see the component structure here, we see, okay, we have an h1 and an input here, we have some directives like vmodel and it's quite nice to have a look at the structure of the component itself, how it's rendered then.

ここではコンポーネントの構造を見ることができます。h1とinputがあり、vmodelのようなディレクティブがあります。

The next part then was the script part, of course, typically with the options API in Vue 2, but of course, we could just rewrite that part to the composition API, so just use the script setup and say const message is ref and import ref from Vue here and we'll be good to go as well, so that would work the same way.

スクリプトのセットアップを使用して、const message is refと言って、Vueからrefをインポートすれば、同じように動作します。

But the bigger question is, what does the script part here, the second one, brings us?

しかし、より大きな疑問は、ここでの脚本部分、2つ目の脚本が私たちに何をもたらすのか、ということだ。

Well, of course, we want to see our logic, right?

もちろん、自分たちのロジックを見たいよね？

We want to see what is happening in our component, how specific parts interact with each other, if there's some lifecycle hooks called and so on, so on.

コンポーネントの中で何が起きているのか、特定のパーツがどのように相互作用しているのか、ライフサイクル・フックが呼び出されているのか、などなど。

だから、私たちはそこにすべてを見ることができる。

And then last but not least, the styles, because, well, styles last, they're not as important as structured logic, and we're good to go.

そして最後がスタイルで、まあスタイルは最後だが、構造化ロジックほど重要ではない。

But as most of you know, this traditional way of writing single file components changed, and actually, the only thing that really changed is moving the script part all the way to the top and the template second.

しかし、ほとんどの人が知っているように、この伝統的な単一ファイル・コンポーネントの書き方は変わった。

なぜこんなことになったのか？

そして、それはいつ起こったのか？

Well, the answer is, it happened roughly around the same time as the composition API came out, and thus also Vue 3.

答えは、コンポジションAPIが登場したのとほぼ同時期に、Vue 3も登場した。

And Avenue himself also switched to that, the documentation switched to that, and he basically said the following about it.

そして、アヴェニュー自身もそれに切り替え、文書もそれに切り替え、それについて彼は基本的に次のように述べた。

I've been moving to script first, and as I've seized myself, especially with script setup.

私はスクリプト・ファーストに移行してきたし、特にスクリプトのセットアップに関しては、自分自身を掌握してきた。

And then Evan talks about a tool that helps you automating that.

そしてエヴァンは、それを自動化するツールについて語る。

Jonathan Rennink, who is the author of Inertia, also working on Tailwind, asked back then in 2021, okay, hey, but why?

イナーシャ』の著者で、『テイルウィンド』にも携わっているジョナサン・レニンクは、2021年当時、こう尋ねている。

And the point that Evan makes here is that it aligns better with the plain JavaScript mental model.

そして、エヴァンがここで指摘しているのは、その方がプレーンなJavaScriptのメンタルモデルに合致しているということだ。

So imports and declarations first, and then usage.

だから、まずインポートと宣言、それから使用法だ。

And of course, he also points out that this is because script setup itself, so the composition API itself aligns way more with the plain JavaScript mental model.

そしてもちろん、これはスクリプトのセットアップそのものが原因であり、コンポジションAPIそのものが、プレーンなJavaScriptのメンタルモデルにはるかに合致していることも指摘している。

Well, we already know that the composition API is way more JavaScript or just JavaScript than the options API was, so that kind of makes sense.

まあ、コンポジションAPIがオプションAPIよりもずっとJavaScript、あるいはJavaScriptだけであることはすでに分かっている。

But what's the benefit in a bigger component there?

しかし、そこに大きなコンポーネントを搭載するメリットはあるのだろうか？

Well, for me personally, I think if I see at first what the component is doing, maybe even some inline composables of the certain concerns the component has, I at least know, okay, what do I expect of that?

私個人としては、コンポーネントが何をしているのか、コンポーネントが持っている特定の懸念事項をインラインでコンポーザブルにすることもできるかもしれない。

Plus, when I read a big component, and there would be a template first, then I might jump, oh yeah, here's a click handler, I jump into the script further down, I read what is this click handler doing, maybe another function, take a look at that, and then have to go all the way up again to continue.

それに、大きなコンポーネントを読むと、まずテンプレートがあって、それから、そうだ、ここにクリック・ハンドラがある、とジャンプして、さらに下のスクリプトにジャンプして、このクリック・ハンドラは何をやっているのか、たぶん別の関数も読んで、それを見て、それから続けるためにまたずっと上に行かなければならないかもしれない。

Well, that's not ideal, because in the template, you can't really group everything by concern, right?

というのも、テンプレートでは、懸念事項ごとにすべてをグループ化することはできないからだ。

It's based on the markup and how you react to things.

それは、マークアップと物事に対する反応に基づいている。

While in your code, you can have nice groups, for example, with inline composables, also video on that in the description or up there, that groups everything nicely by concerns, you know, okay, this functionality, here's all the code I need for that.

例えば、インラインでコンポーザブルを使うことで、いいグループを作ることができる。

And if I now want to see how this is implemented in the actual template part to see which click handlers are triggered, where do I loop over things, where's two-way data binding, then I can easily do that after that I know all of the things about these concerns.

そして、実際のテンプレート・パートでどのように実装されているのか、どのクリック・ハンドラがトリガーされるのか、どこでループをかけるのか、どこで双方向のデータ・バインディングが行われているのかを確認したい場合、これらの懸念事項がすべてわかっていれば、簡単にそれができる。

A lovely example for this that I always like to bring up is basically what I just said in the comparison between options API and composition API.

私がいつも持ち出したいと思っている素敵な例は、基本的に、オプションAPIとコンポジションAPIの比較で私が今言ったことだ。

And keep in mind, this is only the script part that you see here colored by concerns.

覚えておいてほしいのは、ここにあるのはスクリプトの部分だけだということだ。

And as some of you might know from other videos of mine, yes, there is also the non-blurry version of the right part here of the composition API in a gist that Evan made back then where you have everything nicely grouped by concern and top level called what the component is actually doing, and then having all the reusable functions aka inline composables further down.

Evanが当時作成したgistには、コンポジションAPIの右側の部分のボケていないバージョンもあります。

And after we scroll through these 200 lines, we at least know what the component is doing.

この200行をスクロールした後、私たちは少なくともそのコンポーネントが何をしているのかを知ることができる。

And then we have the template part here, which, well, is fully omitted.

そして、テンプレートの部分だが、これは完全に省略されている。

So that would also be a couple of hundred lines, I suppose, but doesn't have to be.

だから、それも数百行になると思うが、そうする必要はない。

And even if we just say, okay, we read this top part, we at least roughly know what's going on here.

そして、この一番上の部分を読むだけでも、少なくともここで何が起こっているかはおおよそわかる。

So we have a good overview of the component, contrary to when we read all the template and like, okay, at least we know how it's rendered.

テンプレートをすべて読んで、少なくともどのようにレンダリングされるかはわかった。

So in my opinion, that's a quite good option.

だから、私の意見としては、これはかなりいいオプションだと思う。

And of course, we also have another component here from Elk, the open source mastering client based on Vue, Vite, Nuxt, UnicSS, and so on.

もちろん、Vue、Vite、Nuxt、UnicSSなどをベースにしたオープンソースのマスタリングクライアントであるElkのコンポーネントもあります。

So definitely have a look, link in the description as well.

説明文にもリンクがあるので、ぜひ見てほしい。

And here we see, okay, this is a command panel that Vue component.

これはVueコンポーネントのコマンドパネルだ。

And here we also have everything related to the component logic in the script part.

また、ここではコンポーネント・ロジックに関連するすべてをスクリプト部分にまとめている。

First, script setup, we don't have any inline composables.

まずスクリプトのセットアップだが、インラインのコンポーザブルはない。

The logic is, I would say, still manageable though.

ロジックは、まだなんとかなると思うが。

Here and there we have some functionalities that we could align better together, but still, we could see, even if we just simply collapse these in a proper editor and not in GitHub here, then we could just say, okay, yeah, no problem.

でも、GitHubではなく、ちゃんとしたエディターで、単純にこれを折りたたむだけでも、「よし、問題ない。

On key down, okay, there's something that will happen on key down.

キーダウンで、オーケー、キーダウンで起こることがある。

ここで、何かが描かれている。

And we have that on key down easily up here in key down.

キーダウンキーダウンで簡単にできるんだ。

And now the big question is, is the script part on top order really better than the traditional or like OG order of tags in a single file component?

そして今、大きな疑問がある。スクリプト部分を上に並べる順番は、従来の、あるいはOGのように1つのファイル・コンポーネントのタグを並べる順番よりも本当に良いのだろうか？

Well, as I said in the beginning, a lot of developers have a lot of opinions.

まあ、最初に言ったように、多くの開発者が多くの意見を持っている。

そこで、最良の選択肢を明らかにしよう。

The best option is whatever you pick, but please stay consistent.

ベストな選択肢は何を選んでもいいが、一貫性を保ってほしい。

だから両方試してみてほしい。

But if you have a project, please don't go there and say, hey, script part first, style part first.

でも、もしプロジェクトがあるなら、脚本が先だ、スタイルが先だ、とは言わないでほしい。

それは本当にクレイジーだけどね。

Please just stick with one of the ways, especially if your whole team settled on that easily.

チーム全体がそれですんなり決まったのならなおさらだ。

And in the end, well, if you work alone in your projects, you can do whatever you want, right?

そして結局のところ、まあ、一人でプロジェクトに取り組めば、やりたいことは何でもできるだろう？

Though I still would suggest consistency because it's easier to onboard people sometimes to take a look at your own code in, I don't know, a couple of days or like see what you wrote before Christmas, because you certainly won't remember any of that anymore.

とはいえ、自分のコードを2、3日後に見てみたり、クリスマス前に書いたものを見てみたりする方が、時に人を乗せやすくなるので、一貫性を保つことをお勧めしたい。

少なくとも、私は時々そう感じる。

だから、一貫性を保ってほしい。

And if you use a normal IDE, you can even do another nice thing.

さらに、普通のIDEを使えば、もうひとついいことができる。

So let's take a look at what the Vue extension is doing for us.

それでは、Vueエクステンションが何をしてくれるのか見てみよう。

So if you're in VS Code, you should also work in other editors.

だから、VS Codeで作業しているなら、他のエディターでも作業すべきだ。

The Vue extension allows you to split the script, template and style editors into separate windows.

Vue拡張機能を使えば、スクリプト、テンプレート、スタイルの各エディタを別々のウィンドウに分割できます。

So here when we have script and template, you see the template part and you see the script part.

スクリプトとテンプレートがある場合、テンプレートの部分とスクリプトの部分が見える。

And of course the other part is collapsed.

そしてもちろん、他の部分は崩壊している。

だから、あなたは素晴らしい概要を知っている。

You can even have that under each other if you want to.

その気になれば、お互いの下に敷くこともできる。

You can lay it out on different screens if you work in one big component, that's all up to you.

ひとつの大きなコンポーネントで作業するのであれば、別のスクリーンにレイアウトすることもできる。

But luckily, all of that is fully possible.

しかし幸運なことに、そのすべてが十分に可能なのだ。

So no matter the order, you can still arrange it as you want in your IDE.

だから、順番に関係なく、あなたのIDEで好きなように並べることができる。

And also Vue is not really enforcing an order, right?

それに、ヴューは実際にオーダーを執行しているわけではないでしょう？

There are some suggestions, but once again, in your projects, you can do it as you like.

いくつかの提案はあるが、繰り返しになるが、あなたのプロジェクトでは、好きなようにやればいい。

If you have a bunch of OJ developers say, hey, this is the way I want my structure first and not my logic, that's totally fine.

もし、OJの開発者たちが、自分のロジックではなく、自分の構造を優先させたいと言ったとしても、それはまったく構わない。

If you're maybe still using options API, that's probably also something where I would prefer a template first, but everything with composition API and beyond, I personally think the script part on top is the best.

もしまだオプションAPIを使っているのであれば、それも最初にテンプレートがあった方がいいと思いますが、コンポジションAPIやそれ以降のものは、個人的には上にスクリプトを置くのがベストだと思います。

Now I want to wonder, what's your take on that?

それについて、あなたはどう思う？

Are you a big enthusiast of script first or template first, or maybe something total curious, maybe using, as I said before, Vue.Vine and don't have all these issues at all?

あなたは、スクリプト・ファーストやテンプレート・ファーストの大ファンですか？それとも、前にも言ったように、Vue.Vineを使っていて、このような問題はまったくないのでしょうか？

もちろん、コメントで教えてね。

And well, I'm interested to have you any experience with switching back and forth.

そして、まあ、私はあなたが前後に切り替えの経験を持っていることに興味がある。

So yeah, what's your take on the whole point there?

では、その点についてどうお考えですか？

As I said before, we have a lot of people with a lot of opinion there, and that's totally fine, because that is also how we shape the future of our framework with some more input here and there.

前にも言ったように、私たちは多くの意見を持つ多くの人々を抱えている。

And nevertheless, take a look at the latest Azure Vue episode where Michael talked with Adam Jar of Vue Mastery about creating content, because this is a key skill for all of you developers out there.

それにもかかわらず、マイケルがVue Masteryのアダム・ジャーとコンテンツ作成について話した最新のAzure Vueのエピソードをご覧ください。

そこで1つか2つ、学ぶことがある。

And obviously take a look at all the other videos, because I guess they're pretty nice, still relevant.

もちろん、他のビデオも全部見てほしい。

And yeah, I hope to see you next video as usual every Friday.

また、次のビデオでお会いしましょう。