管理和初始化表示 DOM 元素的 JS 对象的最佳方法
创建网页时,其内容将由用户动态创建和销毁,构建和初始化 javascript 功能和 DOM 元素的最佳方法是什么?
示例 - 假设您有一个todo-list 谁的项目可以由用户重新排序、创建和销毁:
- 每个项目将有一个视觉表示(即 Dom 元素),当用户添加项目时需要动态创建
- 每个项目也将有javascript 表示(即具有自定义方法和属性的 javascript 对象),当用户添加项目时将实例化,
处理创建初始 DOM 元素及其 javascript 表示的最佳方法是什么?我可以看到几种可能性:
- 让服务器输出结构化的 HTML,让 JS 通过遍历 DOM 来收集初始状态。
- 让服务器输出结构化 HTML 和一些 JS 代码来创建对象集并将它们与其 DOM 表示关联起来。
- 让服务器吐出 JS 对象并在页面加载后动态创建 DOM 元素。
When creating a web page who's content will be created and destroyed dynamically by the user, what is the best way to structure and initialize both the javascript functionality and the DOM Elements?
Example -- Lets say you have a todo-list who's items can be re-ordered, created, and destroyed by the user:
- Each Item will have a visual representation (ie. Dom elements) which will need to be created dynamically when the user adds an item
- Each item will also have a javascript representation (ie. javascript objects with custom methods and attributes) which will be instantiated when the user adds an item
What is the bet way to deal with creating the initial DOM elements and their javascript representation? I can see a couple possibilities:
- have the server spit out the structured HTML and have the JS glean the initial state by walking the DOM.
- have the server spit out the structured HTML and some JS code to create the set of objects and associate them with their DOM representation.
- have the server spit out JS objects and dynamically create the DOM elements once the page is loaded.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不确定最佳方式;这取决于你的要求是什么。
我最喜欢的方法是为每个数据结构提供一个 JavaScript 模板;这样,如果您正在进行 AJAX 调用,您只需通过网络发送数据本身,而不是 HTML。
您还可以使用混合方法,其中服务器为初始页面加载吐出结构化 HTML,读取结构(您的 HTML 中应该有足够的语义,以了解您正在处理的是什么,即使您不这样做)不要使用这种方法),但仍然使用 JavaScript 模板来填充数据以进行更新。这种方法的明显缺点是您最终将在客户端和服务器端复制模板;但是,有一些工具和框架(例如 Google Closure Templates)允许您编写一次模板,并为您生成适当的服务器和客户端版本。如果您希望应用程序在没有 JavaScript 的情况下运行,您将必须从服务器发送 HTML。如果您需要 JavaScript,我认为没有理由让服务器吐出 HTML,除非您担心多个 HTTP 请求。
因此,您是否要发送 JavaScript 结构和 HTML 以进行初始页面加载取决于几个因素:您的目标 CPU 是什么? (桌面、移动)您的客户将拥有什么类型的带宽? (低于 3G 的速度?)如果您的带宽不受限制但 CPU 有限,那么在首页加载时发送结构和数据会更有意义。如果您有无限的 CPU 但有限的带宽,您只想发送结构或数据并从中生成另一个,等等。
您还可以使用 GWT 或 jQuery 的小部件之类的东西来为您处理很多这种痛苦,但它们的想法都是相同的:每个小部件/结构/无论您想要调用什么,只有一份 HTML 布局副本,以便数据本身保持精简且易于使用。
当然,您可以使用的 HTTP 请求越少越好,但这可能会导致代码相当复杂和重复,除非您使用框架或工具包或自己开发。
I'm not sure about best way; it depends on what your requirements are.
My favorite approach is to have a JavaScript template for each data structure; that way, if you're doing AJAX calls, the only thing you have to send across the wire is data itself, and not HTML.
You could also use a hybrid approach where the server spits out the structured HTML for initial page load, read the structure in (you should have enough semantic meaning in your HTML to know what it is you're dealing with, even if you don't use this approach), but still use JavaScript templates to stuff data into for updates. The obvious downside to this approach is that you will end up duplicating your templates on the client and server-side; however, there are tools and frameworks (e.g. Google Closure Templates) that allow you to write the templates once and will generate the appropriate server and client versions for you. You will have to send the HTML from the server if you want your application to work without JavaScript. If you are requiring JavaScript, I don't see a reason to have the server spit out the HTML unless you're worried about multiple HTTP requests.
Whether you want to send the JavaScript structure and the HTML for initial page load therefore depends on several factors: what CPUs are you targetting? (desktop, mobile) What type of bandwidth will your clients have? (sub-3G speeds?) If you have unlimited bandwidth but limited CPU, it would make more sense to send both the structure and data on first page load. If you had unlimited CPU but limited bandwidth, you'd only want to send either the structure or the data and generate the other from it, etc.
You could also use something like GWT or jQuery's widgets to handle a lot of this pain for you, but they're all the same kind of idea: only have one copy of the HTML layout per widget/structure/whatever-you-want-to call-it so that the data itself stays lean and nice to work with.
Of course, the fewer HTTP requests you can get away with, the better, but that can lead to quite a bit of complexity and duplication in your code unless you use a framework or toolkit or roll your own.
就性能而言,您最好使用第三个选项 - 动态创建 DOM 元素。首先,因为服务器响应会更小,从而更快;其次,因为 JavaScript 在创建对象时性能会更好。
当您只需要向页面中注入元素时,看看性能,将这个:
与这个:
innerHTML 进行比较更快。但是,当您需要引用注入的元素时,将以下内容
与以下内容进行比较:
createElement 赢得了性能竞赛。
由于您需要元素引用,因此从服务器检索 JSON 并创建元素将获得更好的性能。
话虽这么说,您可以通过仅创建需要引用的元素并在其他地方注入 html 来获得最佳性能。例如,对于此 html:
如果您只需要对父级
的引用,而不需要对其子级的引用,那么不要动态创建子元素,而是创建父级
。 div>
动态地,然后为内容设置其innerHTML:因此,在性能方面,您可以两全其美。
编辑 - 添加超出性能考虑的信息
从架构上来说,我不喜欢服务了解太多有关客户端的信息,只了解它提供的数据。这样,如果您决定更改 UI,则无需修改该服务即可让它输出不同的 HTML。此外,如果您发现想要在其他地方使用相同的数据,您已经有了可以重复使用的服务。
Performance-wise, you'll do best using your 3rd option - Creating the DOM elements dynamically. First, because the server response will be smaller, and thus quicker, and second because JavaScript performance will be better in creating the objects.
Looking at performance when you just need to inject elements into a page, comparing this:
to this:
innerHTML is quicker. However, when you need references to the injected elements, comparing this:
to this:
createElement wins the performance contest.
Since you need element references, you'll get better performance from retrieving JSON from the server, and creating the elements.
That being said, you may get the best performance by only creating the elements you need references to and injecting html elsewhere. Eg, for this html:
If you only need a reference to the parent
<div>
, and not to its children, then rather than creating the child elements dynamically, create the parent<div>
dynamically, and then set its innerHTML for the content:Thus, you get the best of both worlds, performance-wise.
Edit - Adding information beyond performance considerations
Architecturally speaking, I don't like services to know much about the client, only the data it provides. This way, if you decide to change your UI, you don't have to muck with the service to get it to spit out different HTML. Additionally, should you find that you want to use the same data elsewhere, you've already got a service in place that you could re-use.