我正在查看后端的 express.js 和客户端的 JS。我的应用程序是单页 Web 应用程序。
服务器将只提供 JSON 消息,我的问题是关于快递的“路由”。是否应该使用路由来连接 UI 和服务器端业务逻辑?这将如何与我的单页应用程序一起使用?
可以说,客户端向服务器发出 Ajax 调用以在数据库中查找值,并且有服务器端脚本将 JSON 提供回 UI。这个 UI 和节点脚本的关系是如何设置的?
有人可以对此有所了解吗?
我正在查看后端的 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 中。
因此,在单页应用程序中,您在服务器上有一个处理应用程序 HTML 文档 (index.html) 的路由,并且您有负责处理应用程序数据的路由(在数据库,登录和注销,编辑或销毁数据库中的实例,以及获取数据......)通过 AJAX 请求调用。
这实际上是一个相当复杂的情况,因为 HTML5 允许我们能够放弃哈希(在服务器上的一些链接重写的帮助下)并且还能够像我们一样使用“后退”和“前进”按钮实际上已经离开了原始文档(我们没有这样做,因为我们只是将浏览器指向完全相同的 URL,只是修改了哈希值,所以没有发生新的页面加载)。传统的站点导航和链接可以通过使用浏览器的 History API 来实现,该 API 从版本 10 开始可用于 IE(我相信),其他大型浏览器供应商已经在很早之前就已经开始使用它了,所以框架利用这项技术将允许您的用户在 URL 中没有哈希的情况下浏览您的应用程序。
应该使用 AJAX 从服务器请求 JSON。AJAX 请求将始终访问您的服务器,因为您没有在 AJAX 请求中包含哈希符号(这样做很荒谬,因为哈希仅用于文档内浏览),因此服务器端路由必须负责公开您的数据 API(考虑一个 RESTful 的 API)。虽然这不是他们在单页应用程序中的唯一目的,但它可能是他们最重要的目的。
太棒了,总结一下,你将有两组路线。一个在客户端(作为 AngularJS 或 EmberJS 等客户端框架的一部分,不胜枚举……我更喜欢 Angular,但它的学习曲线相当陡峭。),一个在服务器上。当您考虑“服务器路由”时,请考虑数据 API。当您想到“页面路由”时,请记住这一切都在客户端上由您与初始服务器响应一起交付的 javascript 处理(这是与将 HTML 呈现到浏览器有关的唯一必要的服务器端路由,加载您的“index.html”以及所有必要的脚本和样式表等)。您将使用 express.static 中间件来提供静态文件,因此您不必担心为这些东西分配路由。
编辑 快速提及 AJAX 实现。在服务器上,您将拥有与 Alex 提供的示例类似的路由,并且您将使用您选择的框架或库公开的任何 XMLHttpRequest (XHR) 对象从客户端调用这些 URL。现在,框架/库将这些请求实现为 Promises http://wiki.commonjs.org/wiki/Promises/A或多或少被认为是标准和最佳实践. 您应该自己阅读一些有关它的内容,但我可以通过说它是一种异步操作来总结它,类似于同步操作中的“尝试、捕获、抛出”。您将实例化一个 Promise 对象,并通过它尝试从服务器加载数据,例如,通过 GET 请求。确保您已分配函数来处理向您发出请求的 URL 发出的请求(服务器端路由)!您实例化并随后通过该对象向服务器发出请求,承诺一旦从服务器返回请求的结果(无论是否成功),都会将请求的结果返回给您。如果成功,它将调用您编写的一个函数,它将为它提供来自服务器的数据。如果失败,它将调用不同的函数,
希望这有助于回答您的问题。
您只需路由动态服务的请求。你的 HTML、CSS、JS 都是静态资产。因此,您需要处理的只是您的数据。
听起来你想要一个Restful API,这基本上意味着你有特定资源的 URL,以及用于操作它们的 HTTP 动词。
就像是:
GET /books.json
- 获取所有书籍POST /books.json
- 使用请求正文中传递的属性创建一本新书GET /books/123.json
- 获取 id 为 123 的书PUT /books/123.json
- 使用请求正文中传递的属性更新现有书籍一旦你有一个理智的 API 来传递 JSON,你只需让你的 AJAX 调用根据你想要获取的对象来使用它。