I have twelve web pages and each has a set of 7-10 buttons. The code behind and around the buttons is 6-7 lines of HTML.
我有12个网页，每个网页都有一组7-10个按钮。按钮后面和周围的代码是6-7行HTML。
To simplify coding I made these into directives with a simple inline template in each directive.
为了简化编码，我在每个指令中使用简单的内联模板将这些指令作为指令。
Is there much overhead when a page opens and it has to convert all my elements to directives?
当页面打开并且必须将我的所有元素转换为指令时，是否有很多开销？
Also what is the process flow for doing this? Will it slow down the rendering of the page?
这样做的流程是什么？它会降低页面的渲染速度吗？
How about what I am doing, is it a good practice for directives or is there a better way I could do it?
我正在做什么，对于指令来说这是一个很好的做法，还是有更好的方法可以做到？
4 个解决方案
#1
7
1) Yes, there is overhead: Directives are rendered into Markup during Angular's Digest Cycle. The first cycle will run once the framework has loaded. The overhead on loading can be big. The first digest cycle will run quickly.
1）是的，有开销：在Angular的摘要周期期间，指令被渲染到Markup中。一旦框架加载，第一个循环将运行。加载的开销可能很大。第一个摘要周期将很快运行。
The answer as to how much overhead depends on whether you intend to use AngularJS on any page already. If the libararies and framework will be loaded anyway, the overhead is minimal. Loading the libs and starting the framework will usually give a slightly noticeably pause before the page fully renders.
关于开销多少取决于您是否打算在任何页面上使用AngularJS的答案。如果无论如何都要加载libararies和框架，那么开销很小。加载lib并启动框架通常会在页面完全呈现之前略微停顿。
If, on the other hand, your page already uses the AngularJS framework, the overhead for an HTML Directive with no model properties is tiny. Heavy overhead happens when you have many bound model properties. Then the framework has to watch your model properties and run through the digest cycle every-time one changes
另一方面，如果您的页面已经使用了AngularJS框架，那么没有模型属性的HTML指令的开销很小。当您有许多绑定模型属性时会发生大量开销。然后，框架必须观察您的模型属性，并在每次更改时运行摘要周期
2) Is it a good idea? YES. NO. Kind of. It depends. Are you already using AngularJS for the page (recurring theme)? If yes, then this is very good practice. You can have many levels of encapsulation with low level cost and are encouraged to do so liberally.
2）这是个好主意吗？是。没有。有点。这取决于。您是否已经在页面中使用AngularJS（定期主题）？如果是，那么这是非常好的做法。您可以通过低级别的成本进行多级封装，并鼓励您*地进行封装。
If you are already using Angular and "enduring" the digest cycle, then encapsulating some re-useable HTML, comes with low cost. On the first round of the Digest Cycle, the framework replaces directives with rendered markup. There is a slight cost (minimal), but all code re-use has cost. In this case, it will be minimal.
如果您已经在使用Angular并且“持久”了摘要周期，那么封装一些可重复使用的HTML，成本很低。在摘要周期的第一轮中，框架用渲染标记替换指令。有一点成本（最小），但所有代码重用都有成本。在这种情况下，它将是最小的。
3) If you want to re-use this code on 1 or several pages that do NOT use AngularJS: In this case, the costs are probably not worth it. Here again, it depends. Maybe if 10 pages use Angular and 2 more do not, you may still prefer to use an AngularJS Directive.
3）如果要在不使用AngularJS的1个或多个页面上重复使用此代码：在这种情况下，成本可能不值得。这又取决于它。也许如果10页使用Angular而2则不使用Angular，您可能仍然喜欢使用AngularJS指令。
But if none of your pages need the framework, or most (10 out of 12) don't, you are probably better off using an HTML5 template
但是，如果你的网页都不需要框架，或者大多数（12个中的10个）不需要框架，那么最好使用HTML5模板
#2
5
IMHO, rendering several widgets with 6-7 lines of generic html should not harm your performance too much. If the html has nested directive etc, that would be another story
恕我直言，使用6-7行通用HTML渲染几个小部件不应该太多损害你的性能。如果html有嵌套指令等，那将是另一个故事
#3
4
As @I_Debug_Everything answer shows, for basic html templates there is a slight penalty. Will 5-10ms make a noticeable difference in performance, I think not.
正如@I_Debug_Everything答案所示，对于基本的html模板，会有轻微的惩罚。 5-10ms会在性能上产生明显的差异，我想不会。
However, there are other factors you need to take into consideration as well, which might or might not play a role in your setup.
但是，您还需要考虑其他因素，这些因素可能会或可能不会在您的设置中发挥作用。
- With directives you are sharing the directive template, so the amount of data received from the server is less than standard HTML where the HTML will be duplicated on every page and section on the page you want to display the set of common elements.
- 使用指令共享指令模板，因此从服务器接收的数据量小于标准HTML，其中HTML将在每个页面上复制，而页面上的部分则要显示公共元素集。
- With directives you have a single template to make any changes to your template, so you win in productivity.
- 使用指令，您可以使用单个模板对模板进行任何更改，从而提高工作效率。
- You can unit test you directives.
- 您可以对指令进行单元测试。
- Arguably directives makes your HTML more readable.
- 可辩论的指令使您的HTML更具可读性。
- Web Components is where the standards are moving to. Angular 2.X supposedly will support this natively.
- Web Components是标准的发展方向。据说Angular 2.X本来会支持这个。
These are all factors that you also need to take into consideration.
这些都是您需要考虑的因素。
#4
4
I tried a sample demo and yeah it does take a little bit more time when rendering elements using directives (which is obvious because angular process will consume some time to render custom markups into valid html)
我尝试了一个示例演示，是的，在使用指令渲染元素时需要花费更多时间（这很明显，因为角度处理会花费一些时间将自定义标记渲染为有效的html）
Here is a demo using angular to render elements using directives:
这是一个使用angular来使用指令渲染元素的演示：
Rendering elements using angular
使用角度渲染元素
and here is another one that uses pure html
这是另一个使用纯HTML的
Rendering elements without angular
渲染元素没有角度
I've rendered equal number of elements for both the examples to make sure we have an equal comparison. You can see the time consumed on the console. On an average, considering both the examples rendering elements is 5-10 ms faster while rendering without angular.
我为这两个例子提供了相同数量的元素，以确保我们有相同的比较。您可以在控制台上看到所消耗的时间。平均而言，考虑到两个示例渲染元素在渲染时没有角度的情况下快5-10毫秒。
Notice that I've defined the app module in both of the examples to maintain the time required to load the angular modules. I usually use directives only when the html is too long or as in your case it's being repeated often. If the time performance is too critical for you and you really want the elements to load faster, I would suggest using pure html.
请注意，我已在两个示例中定义了app模块，以保持加载角度模块所需的时间。我通常只在html太长时使用指令，或者在你的情况下经常使用指令。如果时间性能对你来说太关键而且你真的希望元素加载更快，我会建议使用纯HTML。
Update 1
The above example only have simple markups and nothing fancy going on. In real word scenario where we might be passing custom attributes and compiling the elements (using $compile) the time difference may go up even higher.
更新1上面的例子只有简单的标记，没有任何花哨的东西。在真正的单词场景中，我们可能会传递自定义属性并编译元素（使用$ compile），时差可能会更高。
Update 2
更新2
I came across this awesome description of directives, which shows how a directive is injected, compiled and execute on a web page. I think this covers and probably the best resource on how the directive works in Angular.
我遇到了这个令人敬畏的指令描述，它描述了如何在网页上注入，编译和执行指令。我认为这涵盖了可能是该指令如何在Angular中工作的最佳资源。
#1
7
1) Yes, there is overhead: Directives are rendered into Markup during Angular's Digest Cycle. The first cycle will run once the framework has loaded. The overhead on loading can be big. The first digest cycle will run quickly.
1）是的，有开销：在Angular的摘要周期期间，指令被渲染到Markup中。一旦框架加载，第一个循环将运行。加载的开销可能很大。第一个摘要周期将很快运行。
The answer as to how much overhead depends on whether you intend to use AngularJS on any page already. If the libararies and framework will be loaded anyway, the overhead is minimal. Loading the libs and starting the framework will usually give a slightly noticeably pause before the page fully renders.
关于开销多少取决于您是否打算在任何页面上使用AngularJS的答案。如果无论如何都要加载libararies和框架，那么开销很小。加载lib并启动框架通常会在页面完全呈现之前略微停顿。
If, on the other hand, your page already uses the AngularJS framework, the overhead for an HTML Directive with no model properties is tiny. Heavy overhead happens when you have many bound model properties. Then the framework has to watch your model properties and run through the digest cycle every-time one changes
另一方面，如果您的页面已经使用了AngularJS框架，那么没有模型属性的HTML指令的开销很小。当您有许多绑定模型属性时会发生大量开销。然后，框架必须观察您的模型属性，并在每次更改时运行摘要周期
2) Is it a good idea? YES. NO. Kind of. It depends. Are you already using AngularJS for the page (recurring theme)? If yes, then this is very good practice. You can have many levels of encapsulation with low level cost and are encouraged to do so liberally.
2）这是个好主意吗？是。没有。有点。这取决于。您是否已经在页面中使用AngularJS（定期主题）？如果是，那么这是非常好的做法。您可以通过低级别的成本进行多级封装，并鼓励您*地进行封装。
If you are already using Angular and "enduring" the digest cycle, then encapsulating some re-useable HTML, comes with low cost. On the first round of the Digest Cycle, the framework replaces directives with rendered markup. There is a slight cost (minimal), but all code re-use has cost. In this case, it will be minimal.
如果您已经在使用Angular并且“持久”了摘要周期，那么封装一些可重复使用的HTML，成本很低。在摘要周期的第一轮中，框架用渲染标记替换指令。有一点成本（最小），但所有代码重用都有成本。在这种情况下，它将是最小的。
3) If you want to re-use this code on 1 or several pages that do NOT use AngularJS: In this case, the costs are probably not worth it. Here again, it depends. Maybe if 10 pages use Angular and 2 more do not, you may still prefer to use an AngularJS Directive.
3）如果要在不使用AngularJS的1个或多个页面上重复使用此代码：在这种情况下，成本可能不值得。这又取决于它。也许如果10页使用Angular而2则不使用Angular，您可能仍然喜欢使用AngularJS指令。
But if none of your pages need the framework, or most (10 out of 12) don't, you are probably better off using an HTML5 template
但是，如果你的网页都不需要框架，或者大多数（12个中的10个）不需要框架，那么最好使用HTML5模板
#2
5
IMHO, rendering several widgets with 6-7 lines of generic html should not harm your performance too much. If the html has nested directive etc, that would be another story
恕我直言，使用6-7行通用HTML渲染几个小部件不应该太多损害你的性能。如果html有嵌套指令等，那将是另一个故事
#3
4
As @I_Debug_Everything answer shows, for basic html templates there is a slight penalty. Will 5-10ms make a noticeable difference in performance, I think not.
正如@I_Debug_Everything答案所示，对于基本的html模板，会有轻微的惩罚。 5-10ms会在性能上产生明显的差异，我想不会。
However, there are other factors you need to take into consideration as well, which might or might not play a role in your setup.
但是，您还需要考虑其他因素，这些因素可能会或可能不会在您的设置中发挥作用。
- With directives you are sharing the directive template, so the amount of data received from the server is less than standard HTML where the HTML will be duplicated on every page and section on the page you want to display the set of common elements.
- 使用指令共享指令模板，因此从服务器接收的数据量小于标准HTML，其中HTML将在每个页面上复制，而页面上的部分则要显示公共元素集。
- With directives you have a single template to make any changes to your template, so you win in productivity.
- 使用指令，您可以使用单个模板对模板进行任何更改，从而提高工作效率。
- You can unit test you directives.
- 您可以对指令进行单元测试。
- Arguably directives makes your HTML more readable.
- 可辩论的指令使您的HTML更具可读性。
- Web Components is where the standards are moving to. Angular 2.X supposedly will support this natively.
- Web Components是标准的发展方向。据说Angular 2.X本来会支持这个。
These are all factors that you also need to take into consideration.
这些都是您需要考虑的因素。
#4
4
I tried a sample demo and yeah it does take a little bit more time when rendering elements using directives (which is obvious because angular process will consume some time to render custom markups into valid html)
我尝试了一个示例演示，是的，在使用指令渲染元素时需要花费更多时间（这很明显，因为角度处理会花费一些时间将自定义标记渲染为有效的html）
Here is a demo using angular to render elements using directives:
这是一个使用angular来使用指令渲染元素的演示：
Rendering elements using angular
使用角度渲染元素
and here is another one that uses pure html
这是另一个使用纯HTML的
Rendering elements without angular
渲染元素没有角度
I've rendered equal number of elements for both the examples to make sure we have an equal comparison. You can see the time consumed on the console. On an average, considering both the examples rendering elements is 5-10 ms faster while rendering without angular.
我为这两个例子提供了相同数量的元素，以确保我们有相同的比较。您可以在控制台上看到所消耗的时间。平均而言，考虑到两个示例渲染元素在渲染时没有角度的情况下快5-10毫秒。
Notice that I've defined the app module in both of the examples to maintain the time required to load the angular modules. I usually use directives only when the html is too long or as in your case it's being repeated often. If the time performance is too critical for you and you really want the elements to load faster, I would suggest using pure html.
请注意，我已在两个示例中定义了app模块，以保持加载角度模块所需的时间。我通常只在html太长时使用指令，或者在你的情况下经常使用指令。如果时间性能对你来说太关键而且你真的希望元素加载更快，我会建议使用纯HTML。
Update 1
The above example only have simple markups and nothing fancy going on. In real word scenario where we might be passing custom attributes and compiling the elements (using $compile) the time difference may go up even higher.
更新1上面的例子只有简单的标记，没有任何花哨的东西。在真正的单词场景中，我们可能会传递自定义属性并编译元素（使用$ compile），时差可能会更高。
Update 2
更新2
I came across this awesome description of directives, which shows how a directive is injected, compiled and execute on a web page. I think this covers and probably the best resource on how the directive works in Angular.
我遇到了这个令人敬畏的指令描述，它描述了如何在网页上注入，编译和执行指令。我认为这涵盖了可能是该指令如何在Angular中工作的最佳资源。