我应该将我的JavaScript分成多个文件吗? [英] Should I split my javascript into multiple files?

查看:86
本文介绍了我应该将我的JavaScript分成多个文件吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我习惯于用Java处理每个对象都在其自己的文件中定义(一般来说)。我喜欢这个。我认为它使代码更易于使用和管理。

我开始使用javascript,我发现自己想要为单个页面上使用的不同脚本使用单独的文件。目前我只限制一对.js文件,因为我害怕如果我使用的不仅仅是这些,我将来会因为我目前无法预见的事情而感到不便。也许是循环引用?



简而言之,将我的脚本分成多个文件是不好的做法吗?

解决方案

这里有很多正确的答案,这取决于您的应用程序的大小以及您将它传递给谁(我的意思是指预期的设备,等等),以及多少你可以在服务器端进行工作,以确保你的目标是正确的设备(对于大多数非企业凡人而言,这对于100%的可行性来说还有很长的路要走)。

在构建应用程序时,classes可以很好地驻留在它们自己的文件中。

当跨文件分割应用程序时,或者在处理带有过多构造函数的类时(如实例化其他类)循环引用或死胡同引用 ARE 是一个大问题。

有多种模式可以解决这个问题,但最好的模式是使用DI创建应用程序/ IoC,因此循环引用不会发生。

您还可以查看require.js或其他依赖加载器。您需要获得的复杂程度取决于您的应用程序的规模,以及您希望所有内容的私密程度。



在提供应用程序时,服务的基准JS将连接你需要的所有脚本(按照正确的顺序,如果你要实例化其他东西存在的东西),并将它们作为一个文件放在页面的底部。



但是这是基线。

其他方法可能包括懒/延迟加载。

加载所有的东西您需要预先处理页面。

与此同时,如果您拥有在页面加载时不需要100%功能的小程序或小部件,并且实际上它们需要用户交互,或者在做任何事情之前需要时间延迟,然后使这些小部件的脚本加载延期事件。在用户在选项卡上点击鼠标的位置加载选项卡式小部件的脚本。现在你只加载了你需要的脚本,只有在需要的时候,没有人会真正注意到下载的小小滞后。

将这个与试图在一个文件中填充40,000行应用程序的人相比较。

只有一个HTTP请求,并且只有一个下载,但解析/编译时间现在变成明显的一小部分。



当然,延迟加载并不是将每个类都放在自己文件中的借口。

在这一点上,你应该将它们一起打包成模块,并提供将运行整个窗口小部件/ applet /文件的文件(除非有其他逻辑位置,直到后来才需要功能,并且它隐藏在后面进一步的交互)。

你也可以把这些模块加载到一个定时器上。

预先加载基线应用程序的东西页面底部,在一个文件中),然后设置一个半秒左右的超时时间,并加载其他JS文件。

您现在不妨碍页面操作,或者用户移动的能力。这当然是最重要的部分。

I'm used to working with Java in which (as we know) each object is defined in its own file (generally speaking). I like this. I think it makes code easier to work with and manage.

I'm beginning to work with javascript and I'm finding myself wanting to use separate files for different scripts I'm using on a single page. I'm currently limiting myself to only a couple .js files because I'm afraid that if I use more than this I will be inconvenienced in the future by something I'm currently failing to foresee. Perhaps circular references?

In short, is it bad practice to break my scripts up into multiple files?

解决方案

There are lots of correct answers, here, depending on the size of your application and whom you're delivering it to (by whom, I mean intended devices, et cetera), and how much work you can do server-side to ensure that you're targeting the correct devices (this is still a long way from 100% viable for most non-enterprise mortals).

When building your application, "classes" can reside in their own files, happily.
When splitting an application across files, or when dealing with classes with constructors that assume too much (like instantiating other classes), circular-references or dead-end references ARE a large concern.
There are multiple patterns to deal with this, but the best one, of course is to make your app with DI/IoC in mind, so that circular-references don't happen.
You can also look into require.js or other dependency-loaders. How intricate you need to get is a function of how large your application is, and how private you would like everything to be.

When serving your application, the baseline for serving JS is to concatenate all of the scripts you need (in the correct order, if you're going to instantiate stuff which assumes other stuff exists), and serve them as one file at the bottom of the page.

But that's baseline.
Other methods might include "lazy/deferred" loading.
Load all of the stuff that you need to get the page working up-front.
Meanwhile, if you have applets or widgets which don't need 100% of their functionality on page-load, and in fact, they require user-interaction, or require a time-delay before doing anything, then make loading the scripts for those widgets a deferred event. Load a script for a tabbed widget at the point where the user hits mousedown on the tab. Now you've only loaded the scripts that you need, and only when needed, and nobody will really notice the tiny lag in downloading.

Compare this to people trying to stuff 40,000 line applications in one file.
Only one HTTP request, and only one download, but the parsing/compiling time now becomes a noticeable fraction of a second.

Of course, lazy-loading is not an excuse for leaving every class in its own file.
At that point, you should be packing them together into modules, and serving the file which will run that whole widget/applet/whatever (unless there are other logical places, where functionality isn't needed until later, and it's hidden behind further interactions).

You could also put the loading of these modules on a timer.
Load the baseline application stuff up-front (again at the bottom of the page, in one file), and then set a timeout for a half-second or so, and load other JS files.
You're now not getting in the way of the page's operation, or of the user's ability to move around. This, of course is the most important part.

这篇关于我应该将我的JavaScript分成多个文件吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆