node.js和单页Web应用程序 [英] node.js and single page web application
问题描述
我正在看后端的express.js和客户端的JS。
我的应用程序是单页Web应用程序。
服务器将只提供JSON消息，我的问题是关于路由的快递。
应该使用路由连接UI和服务器端的业务逻辑？
如何使用单页面应用程序？
所以让我们说，客户端对服务器进行Ajax调用，寻找数据库中的值，有服务器端脚本将JSON提供回UI。这个UI和节点脚本关系如何设置？
有人可以点亮这个吗？
单页应用程序是生活在单个HTML文档上的应用程序。这意味着如果要向用户显示一些不同的内容，根据应用程序的状态，您将需要进行一些DOM操作（使用不同的HTML切割并替换当前文档的某些元素）以更新用户看到的视图。对不起，如果这是显而易见的，请不要犯罪。我想我从这里开始。挂起我，我会解释你的路由情况会如何发挥（或多或少）。
URL由几个不同的部分组成，每个部分通知浏览器为了下载用户尝试访问的资源所需的特定位信息。通常，您正在寻找的资源在某处的服务器上关闭，浏览器知道这是因为URL（协议（http：）和主机（www.mydomain.com）中的片段，因此它到达该服务器以找到您要求的内容。 URL中还有查询参数，它们向服务器提供关于特定操作的一些附加信息，如搜索查询的搜索条件。查询参数后，出现哈希。哈希是单页应用程序的魔法发生的地方...呃，好吧..... ............
首先有一点关于哈希。当您向URL添加＃时，浏览器会将其后的信息解释为当前显示的文档中的某个位置（元素）。这意味着，如果你有一个'id'为'main'的元素，并且添加'#main'到URL的末尾，就像这样：'http：//www.example.com#main'，浏览器将'滚动'（通常是跳）到该元素的开头，以便您可以看到它。请注意，如果您输入 http://www.example.com/#main '（通过斜杠与URL分开的哈希），那么您将强制完成一个页面重新加载，浏览器将尝试通过服务器上的名称#main找到一个文件（我敢打赌，它没有找到它） 。
这里的外表是，如果URL 中有哈希，浏览器将不会尝试远离当前文档，异常当然这是上面提到的，这是非常好的，因为单页面应用程序不想远离页面或从服务器请求一个新的文档。 （查看单页应用程序的路由方式是否不同？）
现在，关于哈希的整个事情对于单页应用程序来说并不重要，您可以一个没有处理这一切。一堆点击处理程序和DOM操作是您真正需要的...但是，这意味着用户将无法在应用程序中分享特定视图的链接。该URL永远不会改变，我们永远无法直接导航到任何特定的视图。我们总是从您的应用程序的起始位置开始，这可能很容易成为一个非常烦人的情况。
如果您的单页应用程序将有不同的视图，并且您希望用户能够通过书签或链接直接导航到特定的用户，那么您将需要在前端实现一种路由选择，以及您需要在后端实现的路由（数据API的路由等），这意味着您将需要使用哈希。
我不想进入不同的框架如何完成路由但是在用户点击链接时，基本上是更新浏览器的地址字段，并且观看地址栏以确定当前的URL是什么，并将与该URL相关联的HTML加载到DOM中在文档树中的指定位置。
所以，在单页应用程序中，您在服务器上有一条路由处理r列出应用程序的HTML文档（index.html），并且具有负责处理应用程序数据的路由（在数据库中创建新实例，登录和退出，编辑或销毁数据库中的实例以及获取数据） ...）通过AJAX请求调用。
这实际上是一个相当复杂的情况，因为HTML5允许我们放弃哈希（借助于一些链接重写在服务器上），并且还可以使用后退和转发按钮，就像我们实际上已经远离原始文档（我们并不是因为我们只将浏览器指向了相同的URL，只有修改的哈希值，所以没有新的页面加载已经发生）。传统的网站导航和链接可以通过使用浏览器的历史API来实现，该API可以从第10版开始使用IE（我相信），其余的大型浏览器供应商已经早了一些，所以利用该技术将允许您的用户浏览您的应用程序，而不需要URL中的哈希。解释这是一个转移，而不是理解单页应用程序的路由，但它是有趣的，你将不得不学习它最终无论如何，可能..
应该使用AJAX来从服务器请求JSON。 AJAX请求将始终打到您的服务器，因为您不会在AJAX请求中包含散列符号（这样做可能是荒谬的，因为哈希仅用于文档内浏览），因此服务器端路由必须负责公开你的数据API（考虑一个RESTful的）。虽然这不是单页应用程序的唯一目的，但也许是他们最重要的一个。
Soooo要包装，您将有两套路由。一个在客户端（作为客户端框架的一部分，如AngularJS或EmberJS，列表继续...我更喜欢Angular，但是有一个相当陡峭的学习曲线），一个在服务器上。当你想到'服务器路由'认为数据API。当您想到页面路由时，请记住，这一切都在客户端处理，您使用初始服务器响应提供的JavaScript（这是与浏览器呈现HTML相关的唯一必需的服务器端路由，加载'index.html'和所有必需的脚本和样式表等）。您将使用express.static中间件来提供静态文件，因此您不必担心为该内容分配路由。
编辑快速提及AJAX实现。
在服务器上，您将具有类似于Alex提供的路由作为示例，您将使用任何XMLHttpRequest（XHR）对象由您的框架或库选择的对象从客户端调用这些URL。现在，它被认为是框架/图书馆实施这些请求的标准和最佳做法，作为承诺 http： //wiki.commonjs.org/wiki/Promises/A 。你应该自己阅读一下，但我可以总结一下，说它是一个类似于在同步操作中try，catch，throw的异步操作。您将实例化一个承诺对象，通过它，您将尝试从服务器加载数据，例如，通过GET请求。确保已经分配了函数来处理对您发出请求的URL所做的请求（服务器端路由）！这个对象，您实例化并随后通过服务器发出请求，承诺从服务器返回请求的结果（无论是否成功）如果成功，它将调用您已经编写并将从服务器提供数据的功能。如果它失败，它会调用一个不同的函数，也由你编写，并将提供它的错误对象（或'reason'为失败），所以你可以适当地处理错误。
希望有助于回答您的问题。
I am looking at express.js for the back end and JS on the client side. My app is a single page Web App.
The server will only serve JSON messages and my question is about "routing" for express. Is one supposed to use routing to connect the UI and the server side business logic? How will that work with my single page app?
so lets say, the client makes an Ajax call to the server looking for a value in the database and there is server side script that provides the JSON back to the UI. How is this UI and node script relationship setup?
Can someone shed some light on this?
Single page apps are those that live on a single HTML document. This means that if you want to display some different content to the user, depending on the state of the application, you will need to do some DOM manipulation (cutting out and replacing certain elements of the current document with different HTML) in order to update the 'view' that the user sees. Excuse me if this is obvious to you, please don't take offense. I figured I'd start from here. Hang with me and I'll explain how your routing situation is going to play out (more or less).
URLs are composed of a few different parts, each of which informs the browser of a particular bit of information that is required in order to download the resource that the user is attempting to access. Typically the resources that you are looking for are off on a server somewhere and the browser knows this because of pieces in the URL like 'protocol' ('http:') and 'host' ('www.mydomain.com'), so it goes off to that server to find what you're requesting. There are also 'query' parameters in URLs which provide some additional information to the server regarding a particular action, like the search terms of a search query. After the query parameters, comes the 'hash'. The hash is where the magic of single page apps happens... eh, well, kind of.....
First a bit about the hash. When you add a '#' to a URL, the browser then interprets the information that comes after it to be some location (element) within the currently displayed document. That means, if you have an element with an 'id' of 'main' and you add '#main' to the end of the URL, like so: 'http: //www.example.com#main', the browser will 'scroll' (typically 'jump') to the beginning of that element, so that the you can see it. Be aware, though, that if you type 'http://www.example.com/#main' (with the hash separated from the URL by a slash) then you will force a complete page reload and the browser will attempt to find a file by the name '#main' on the server (I bet it doesn't find it).
The takeaway here is that the browser will not attempt to navigate away from the current document if there is a hash in the URL, the exception being of course the case mention above, and this is great because single-page apps don't want to navigate away from the page or request a new document from the server. (See how routing is different for single-page apps?)
Now, this whole thing about the hash isn't vital to single-page apps, as you could make one without dealing with it all. A bunch of click handlers and DOM manipulation is all you'd need really... But, that would mean that users will have no way of sharing links to particular views in your app. The URL would never change, and we would never be able to navigate to any particular view directly. We'd always be starting from the starting position of your app, which could easily be a very annoying situation.
If your single-page app is going to have different views, and you want users to be able to navigate directly to particular ones via bookmarks or links, then you will need to implement a form of routing on the front-end in addition to the routing that you'll need to implement on the backend (routing for data API, etc.), which means that you will need to make use of the hash.
I don't want to get into how different frameworks accomplish routing on the front-end, but it's basically a matter of updating the browser's address field when the user clicks a link, and watching the address bar to determine what the current URL is and loading the HTML that is associated with that URL into the DOM in the designated location in the document tree.
So, within a single-page app, you have one route on the server that deals with rendering the app HTML document (index.html), and you have routes that are responsible for dealing with the data of your app (creating new instances in the database, logging in and out, editing or destroying instances in the DB, and fetching data...) which are called via AJAX requests.
This is actually a fairly complicated situation in that HTML5 allows us to be able to forgo the hash (with the help of some link rewriting on the server) and also be able to use the 'back' and 'forward' buttons as if we've actually navigated away from the original document (which we haven't because we have only pointed the browser to the exact same URL, only with modified hash values, so no new page loads have occurred). Traditional site navigation and linking can be achieved by utilizing the browser's History API, which is available for IE beginning with version 10 (I believe), the rest of the big browser vendors were already on to it quite a bit earlier, so frameworks that leverage this technology will allow your users to navigate your app without the hash in the URL. Explaining this is a diversion and not necessary for understanding routing in single-page apps, but it is interesting and you'll have to learn it eventually anyway, probably..
AJAX should be used to request JSON from the server. AJAX requests will always hit your server because you don't include the hash symbol in AJAX requests (it would be ridiculous to do so because the hash is meant only for in-document browsing), so server-side routes must be responsible for exposing your data API (consider a RESTful one). While this is not their sole purpose in single-page apps, it is perhaps their most important one.
Soooo, to wrap it up, you will have two sets of routes. One on the client (as part of a client-side framework like AngularJS or EmberJS, the list goes on... I prefer Angular, but there is a fairly steep learning curve for that one.), and one on the server. When you think about 'server routes' think data API. When you think of 'page routing', remember that this all gets handled on the client, by the javascript that you delivered with the initial server response (this is the one and only necessary server-side route involved with rendering HTML to the browser, loading your 'index.html' and all of the necessary scripts and stylesheets, etc). You will use express.static middleware to serve static files, so you don't have to worry about assigning routes for that stuff.
EDIT A quick mention of AJAX implementation. On the server, you will have routes similar those that Alex has provided as examples and you will make calls to those URLs from the client using whatever XMLHttpRequest (XHR) object is exposed by your framework or library of choice. It is now considered more or less standard and best practice for frameworks/libraries to implement these requests as Promises http://wiki.commonjs.org/wiki/Promises/A. You should read a bit about it on your own, but I might be able to summarize it by saying that it is an asynchronous operation analogous to 'try, catch, throw' in synchronous operations. You will instantiate a promise object and through it you will attempt to load data from the server, for instance, via GET request. Make sure that you have assigned functions to handle requests made to the URL that you made the request to (server-side route)! This object that you instantiate and subsequently make the request to the server through, promises to return the result of the request to you once it comes back from the server (no matter whether it was successful or not) If it is successful, it will call a function that you have written and will supply it with the data from the server. If it fails, it will call a different function, also written by you, and will supply it with the error object (or 'reason' for failure), so you can handle the error appropriately.
Hope that helped answer your question.
这篇关于node.js和单页Web应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
