blocks|key|201633|text|以下是我的建议。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|201634|网站|201635|如果您在网站上使用TypeScript，请使用模块来封装完整且独立的功能块，并将其保存在一个文件中(除非它变得无法管理)。保守地知道“模块a”对“模块b”的内部位有多少访问权。|201636|将所有生成的JavaScript打包并压缩到一个文件中。|201637|使用以下命令声明您的模块：|201638|module+MyModule+{
++++//+...
}|code-block|syntax|javascript|201639|并使用引用使它们可用于其他代码文件：|201640|///<reference+path="MyModule.ts"+/>|201641|Web应用程序|201642|对于web应用程序，您需要决定脚本将变得多么繁重。如果事情是轻量级的，就像对待网站一样对待它。如果你打算有很多脚本，那么AMD是你的朋友。|201643|使用AMD，你可以使用文件夹结构来组织你的代码。您的文件就是您的模块，因此您可以将文件命名为MyModule.ts，而不是使用module+MyModule声明。然后，您可以使用文件夹和文件结构来组织代码，并在需要时导入模块：|offset|length|style|CODE|201644|import+myModule+=+module("./Messaging/Async/MyModule");|201645|因此，可以将import看作您的using语句--除非您需要给它一个名称。|201646|在运行时，您需要一些东西来为您加载模块。为此，RequireJS是一个很受欢迎的选择。|201647|您只需向您的页面添加一个脚本标记，它将加载RequiresJS并告诉它您的顶级模块的名称：|201648|<script+data-main="/Messaging/Async/MyModule"+src="scripts/require.js"></script>|201649|服务器应用|201650|对于服务器应用程序，您几乎肯定会想要使用CommonJS+(例如，nodejs默认支持它)。|201651|它的工作原理很像AMD+(AMD实际上是基于CommonJS的)，除了服务器会为你加载模块，所以你不需要包括模块加载脚本。|201652|黄金子弹|201653|这真的是所有的指导。如果你愿意的话，你可以对非常大的程序使用web-site风格的捆绑--考虑到脚本将被下载一次并缓存，你可能会决定前期的成本是值得的。|201654|因此，使用该指南，直到您认为它不适合您的特定程序，并希望以不同的方式做事情。指导是基于……的原则。|201655|201656|减少对web+site|ordered-list-item|201657|increasing的http请求数量web应用程序/服务器应用程序的可读性和可维护性|201658|仅加载web应用程序/服务器应用程序|201659|所需的内容|201660|entityMap|0|LINK|mutability|MUTABLE|url|http://requirejs.org/^0|0|0|0|0|0|0|0|0|0|0|1A|B|1R|F|0|0|6|6|G|5|0|N|9|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|26|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|27|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|28|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|29|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|2A|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|2B|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|2C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|2D|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|2E|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|2F|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|2G|8|@$Y|2H|Z|2I|10|11]|$Y|2J|Z|2K|10|11]]|9|@]|A|$]]|$1|12|3|13|5|L|7|2L|8|@]|9|@]|A|$M|N]]|$1|14|3|15|5|6|7|2M|8|@$Y|2N|Z|2O|10|11]|$Y|2P|Z|2Q|10|11]]|9|@]|A|$]]|$1|16|3|17|5|6|7|2R|8|@]|9|@$Y|2S|Z|2T|1|2U]]|A|$]]|$1|18|3|19|5|6|7|2V|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|L|7|2W|8|@]|9|@]|A|$M|N]]|$1|1C|3|1D|5|6|7|2X|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|30|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|31|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|32|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|33|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|1R|7|34|8|@]|9|@]|A|$]]|$1|1S|3|1T|5|1R|7|35|8|@]|9|@]|A|$]]|$1|1U|3|1V|5|1R|7|36|8|@]|9|@]|A|$]]|$1|1W|3|1X|5|6|7|37|8|@]|9|@]|A|$]]|$1|1Y|3|-4|5|6|7|38|8|@]|9|@]|A|$]]]|1Z|$20|$5|21|22|23|A|$24|25]]]]

<p>Here are my recommendations.</p>

<h2>Web Site</h2>

<p>If you are using TypeScript on a web site, use modules to enclose a complete and stand-alone chunk of functionality and keep it in one file (unless it becomes unmanageable). Be conservative about how much access "module a" has to the inside bits of "module b".</p>

<p>Bundle and minify all of the generated JavaScript into a single file.</p>

<p>Declare your modules with:</p>

<pre><code>module MyModule {
    // ...
}
</code></pre>

<p>And make them available to other code files using a reference:</p>

<pre><code>///&lt;reference path="MyModule.ts" /&gt;
</code></pre>

<h2>Web App</h2>

<p>For a web app, you need to decide how script-heavy things are going to be. If things are going to be lightweight, treat it like a web site. If you are going to have a lot of scripts then AMD is your friend.</p>

<p>With AMD, you can use a folder structure to organise your code. Your files are your modules, so instead of using the <code>module MyModule</code> declaration, you name your file <code>MyModule.ts</code>. You can then organise your code using the folder and file structure and import the modules as you need them:</p>

<pre><code>import myModule = module("./Messaging/Async/MyModule");
</code></pre>

<p>So think of the <code>import</code> as your <code>using</code> statement - except you need to give it a name.</p>

<p>At runtime, you'll need something to take care of loading the modules for you. <a href="http://requirejs.org/">RequireJS</a> is a popular choice for this.</p>

<p>You just add one script tag to your page, which loads RequiresJS and tells it the name of your top-level module:</p>

<pre><code>&lt;script data-main="/Messaging/Async/MyModule" src="scripts/require.js"&gt;&lt;/script&gt;
</code></pre>

<h2>Server App</h2>

<p>For a server app, you are almost certainly going to want to use CommonJS (which is supported by default by nodejs, for example).</p>

<p>It works largely like AMD (AMD is actually based on CommonJS) except the server will load the modules for you, so you don't need to include a module-loading script.</p>

<h2>Golden Bullet</h2>

<p>This is all guidance really. You could use web-site style bundling for really quite large programs if you wanted to - given that the script will be downloaded once and cached you may decide that the up-front cost is worth the simplicity.</p>

<p>So use the guidance until you think it doesn't fit your specific program and want to do things differently. The guidance is based on the principle of...</p>

<ol>
<li>reducing the number of http requests for a web site</li>
<li>increasing the readability and maintainability for web app / server app</li>
<li>loading only what is required for a web app / server app</li>
</ol>


blocks|key|2837974|text|这是非常主观的，但值得一提的是，我们或多或少使用模块作为名称空间，因此将相关类分组到一个文件中，除了在视图模型中，我们或多或少坚持一个文件=一个类，就像我们对C#所做的那样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2837975|其中一个原因是，在客户端开发中，我们发现自己创建了更多非常小的类和接口(每个类和接口通常只有两到三个参数)，通常针对特定组件或视图的工作方式进行分组，并且将它们整理在一个文件中似乎更有意义。|2837976|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

<p>This is quite subjective, but for what it's worth we are using modules more or less as namespaces and therefore grouping together related classes in a single file, except in our viewmodel where we more or less stick to one file = one class, as we would for C#. </p>

<p>One reason for this is that in client-side development, we find ourselves creating many more very small classes and interfaces (often with only two or three parameters each), usually grouped about the workings of a particular component or view, and collating these in a single file just seems to make more sense.</p>


<p>I have been working with C# for years and am mostly used to the single-file-per-type way of doing things. I am also fond of putting files into subfolders (corresponding to namespaces in C#).</p>

<p>But now I'm building a mobile web application using TypeScript, and find myself structuring my code in much the same way. However, this doesn't work too well:</p>

<ul>
<li>Every file produces a module wrapper, so if you have many files with the same module the output (when bundled) contains a lot of unnecessary code lines.</li>
<li>Referencing types in other modules is.. not as nice as in C#, as you have to prefix type names with module name.</li>
</ul>

<p>The first point should be fixable by writing a small tool to strip out unnecessary module wrappers from the bundled output. And I'm thinking that I need to avoid using sub-modules and just stick everything into a single module, regardless of file system location.</p>

<p>Is there a better way to go about structuring TypeScript code than what I am currently doing/planning or would something like the above be recommend practice? What alternatives exist that are worth considering for someone who likes the single-responsibility principle?</p>

<p>PS: I hope this falls within the guidelines of SO, despite possibly being a bit subjective and open-ended.</p>


What recommendations exist for structuring TypeScript code bases?

文件系统

TypeScript

服务器

我使用C#已经有很多年了，主要习惯于每种类型一个文件的工作方式。我也喜欢将文件放入子文件夹(对应于C#中的名称空间)。但现在我正在使用TypeScript构建一个移动web应用程序，并且发现我自己的代码结构也是如此。然而，这并不能很好地工作：每个文件都会生成一个模块包装器，所以如果您有许多具有相同模块的文件，则输出(捆...

问对于构建TypeScript代码库有哪些建议？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于构建TypeScript代码库有哪些建议？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于构建TypeScript代码库有哪些建议？
EN