未加星标

Client-side routing and parameters

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

This blog post was inspired by this article , which explains the author's issues with SPAs. His main point is that a lot of single page apps don't behave like proper web pages.

A single-page application (SPA) is a web application or web site that fits on a single web page with the goal of providing a user experience similar to that of a desktop application.

According to Wikipedia (and me) a SPA is still web page, which means it should be bookmarkable, refreshable, navigatable with history buttons and shareable by links . Using an app that doesn't do these can be very frustrating and writing an app that handles them all can be very challenging.

A SPA should be bookmarkable, refreshable, navigatable with history buttons and shareable by links.

The aforementioned issues are all routing related and they are all general enough to be handled at a framework level. There are many client-side routing libraries in the wild with slightly different flavors, but most commonly they are inspired by server-side routers.

In this article I explain my view on client-side routing and the main idea behind the routing related NX middlewares. Finally I provide some examples - written in NX - to prove my theory. The first few sections are framework independent, while the end is NX specific.

A typical server-side routing snippet looks like this.

It routes the request to the handler, which sends a response based on the parameters. The handler runs once for each request and thats it.

The client-side has pages instead of handlers. Unlike handlers, pages tend to stick around for a while and parameters can frequently change during this. Server-side inspired routers usually handle static paths well, but they have problems with dynamic parameters.

A page's parameters must be reflected in the URL and browser history and vice versa. A commonly used hack is to re-route the application to the same page with the new parameters whenever a parameter changes.

This is very similar to the server-side solution, but running the route handler on parameter changes raises two issues.

Depending on the implementation of router.go , the page might be totally re-initialized and re-rendered. Calling router.go every time a state property changes is time consuming and easy to forget. A declarative solution would be nicer. NX separates routing into static path routing and dynamic parameter routing.

The path serves as a static unique identifier for a page and it works like server-side routing. Changing it runs a handler once, which displays the correct page. The dynamic parameters must be stored in the query strings and they are automatically reflected in the current page's state. The parameter handler is client-side specific and it may run multiple times while the page is active.

As an example the previously used /user/12/books/5 would turn into /user/books?userId=12&bookId=5 . It looks a lot uglier, but it comes with two big advantages.

It allows optional parameters, as they are never hard coded as path tokens. It makes it possible to decouple path routing from parameter routing.

Path routing is really simple without dynamic parameters. In fact it is simple enough to be configurable by a few HTML attributes only. The below example is a fully functional client-side routed NX app with two pages and a navigation bar.


Client-side routing and parameters

The router-comp component simply changes it's content based on the current URL path.

If the current url is page.com/profile , the profile page is displayed. If the current url is page.com/home , the home page is displayed. In every other case the home page is displayed as it is tagged as the default-route .

Navigation is equally simple. Anchor elements change the path to match with their iref attribute on click. Clicking the anchor with iref="home" changes the URL path to page.com/home and updates the router to display the home page.

If you would like to learn more about path routing in NX, check the related docs page . It has editable examples for nested routers, navigation options and router events.

Parameter routing reflects the state of the current page in the query string and the browser history and vice versa. Parameters can be declaratively configured for every page. A simple and fully functional example looks like this.


Client-side routing and parameters

The greeting-app automatically synchronizes its state's name property with the name query parameter whenever either of these change. If you would like to know more about parameter routing in NX, check the related docs page .

Path routing creates the skeleton of the page, while parameter routing handles the parameters of the current page. They work independently, but they can be used together as a full routing solution.


Client-side routing and parameters

This example has two pages and it switches between them when the path or the browsers history changes. The home page doesn't have any state, while the greeting page has a state with a name property. It is kept in sync with the URL query and the history by the parameter routing. Changing the name parameter re-renders the Hello @{name}! text node only.

I hope you found this a good read. If you are interested in a complete guide for the example app, check the Getting started page. If you have any thoughts on the topic, please share them in the comments.

Have a nice day!

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: HTML
分页:12
转载请注明
本文标题:Client-side routing and parameters
本站链接:http://www.codesec.net/view/522995.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(36)