So let's go!

我們走吧

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 中，單個文件組件是編寫組件的主要方式，除非你需要在一個文件中編寫多個組件，這時我們可以使用 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.

但可以肯定的是，如果你有一個腳本標籤，而且只用於漸進增強，那麼使用單個文件組件可能就不那麼容易了，尤其是如果你沒有構建步驟，那麼它就不會起作用，但通常情況下，尤其是如果你用 Vue 或 Nuxt 構建整個前端，那麼 SFC 就是你的不二之選。

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 文件有一種特殊的美感，因為我們可以將樣式、腳本邏輯和模板放在三個不同的部分中，但它們仍屬於同一個組件。

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.

是以，如今很多人都有強烈的偏好，我想說的是，有兩種常見的選擇。

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 和一個輸入，我們有一些指令，比如 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.

下一部分是腳本部分，當然，通常使用的是 Vue 2 中的選項 API，當然，我們也可以將這一部分重寫為組成 API，是以只需使用腳本設置，然後說 const message is ref 並從 Vue 中導入 ref 即可，這樣也能以同樣的方式運行。

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

但更大的問題是，劇本的第二部分會給我們帶來什麼？

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.

我們想看看組件中發生了什麼，特定部分之間如何交互，是否調用了生命週期鉤子等等。

So we see all of that in there.

是以，我們在這裡看到了這一切。

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.

但正如你們大多數人所知，這種編寫單個文件組件的傳統方式發生了變化，實際上，唯一真正發生變化的是將腳本部分移到了最上面，而將模板移到了第二位。

Now you might wonder, why did it happen?

現在你可能會問，為什麼會發生這種情況？

And when did it happen?

什麼時候發生的？

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?

喬納森-雷寧克（Jonathan Rennink）是《慣性》（Inertia）一書的作者，同時也在從事《尾風》（Tailwind）的工作。

What's the motivation?

動機是什麼？

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.

我總是喜歡舉一個可愛的例子，基本上就是我剛才在比較選項應用程序接口和組成應用程序接口時所說的。

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.

正如你們中的一些人可能從我的其他視頻中瞭解到的那樣，是的，在埃文當時製作的 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.

當然，我們這裡還有 Elk 的另一個組件，它是基於 Vue、Vite、Nuxt、UnicSS 等技術的開源母帶客戶端。

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.

下鍵時，好的，下鍵時會發生一些事情。

It's fine.

沒關係。

Oh, where is it happening?

哦，在哪裡發生的？

Sure.

當然。

Let's see.

讓我們看看

Okay.

好的

Here, something's rendered.

這裡，有些東西被渲染了。

No problem.

沒問題。

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 一樣的標籤順序更好嗎？

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

正如我在開頭所說，很多開發人員都有自己的看法。

So let's reveal the best option.

那麼，讓我們來揭示最佳方案吧。

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

無論你選擇什麼，都是最好的選擇，但請保持一致。

So try both out.

所以，兩種方法都要試試。

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

但是，如果你有一個項目，請不要在那裡說，嘿，先寫劇本部分，再寫風格部分。

That would be really crazy though.

不過這也太瘋狂了。

Template part first.

首先是模板部分。

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

請堅持使用其中一種方法，尤其是如果你的整個團隊都很容易就決定了這種方法。

And that's it.

就是這樣。

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.

不過我還是建議保持一致性，因為有時看看你自己的代碼會更容易讓人接受，我不知道，幾天後，或者像看看你在聖誕節前寫的東西，因為你肯定不會再記得任何東西了。

At least that's how I feel sometimes.

至少我有時是這麼覺得的。

So yeah, please just stay consistent.

所以，是的，請保持一致。

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

如果你使用的是普通的集成開發環境，你甚至還可以做另一件好事。

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.

當然，另一部分是坍塌。

So you have a nice overview.

這樣，你就有了一個很好的概覽。

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?

另外，Vue 並沒有真正執行命令，對嗎？

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 並沒有遇到這些問題？

Let me know in the comments, of course.

當然，請在評論中告訴我。

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.

儘管如此，請看最新一期的 Azure Vue 節目，在這期節目中，邁克爾與 Vue Mastery 的亞當-賈爾（Adam Jar）討論了創建內容的問題，因為這是各位開發人員的一項關鍵技能。

So learn a thing or two there.

所以，要從中學到一些東西。

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.

是的，我希望能像往常一樣，在每週五的下一期視頻中見到你。

So until then, and maybe in the next video.

所以，在那之前，也許在下一個視頻中。