Category: 前后端技术

React Router V4使用介绍(一)

本文将和大家一起来看一下react router V4的使用,主要是通过一些实例来给大家展示如何编写一些代码。 环境准备 首先,我假设你基本的环境tool已经有了,比如npm,node等都已经装好了。 根据react官网,使用下面命令创建一个react的app React-router-tutorial-V4\lessons>npx create-react-app 01-setting-up 一切完成之后,让我们运行一下看看效果如何: npm start 这是我们最经典的react demo界面了,下面我们对代码做一些调整。把App.js中的代码进行一些简化,就直接返回一个div好了     这样我们看到的ui界面就如下所示了: 下面我们回到主题,我们要学习的是react router,所以,是时候加入react router了。 npm install –save react-router 在react router v4中,我们其实把router分成了三个包,除了我们之前熟悉的react-router外,还有两个包一个是react-router-dom,一个在react-router-native。这两个包其实是为了不同的运行环境提供其所需的特定组件。前者服务于我们常见的桌面浏览器,后者则专用于native部分。因此,我们再安装一下react router dom。 npm install –save react-router-dom 其实,react-router-dom中也包含了react-router的内容,只要安装它也就可以了。喜欢代码整洁,并不考虑跨平台移植代码的同学可以直接只使用react-router-dom。 至此,我们的环境准备部分就结束了。 假如你想直接使用我们相应的code,可以从github中直接下载相应的code: https://github.com/xdyang1986/React-router-tutorial-V4.git 基本router的rendering 首先我们需要让我们的url和对应的页面保持一致,也就是说在改变url,浏览器前进后退等操作的时候,我们能够同步对应的页面进行显示。在react router中目前提供了两种方法,一种是<BrowserRouter>,一种是<HashRouter>,前者是使用HTML5的history API(pushState, replaceState和poststate event)来保持同步的,后者则是使用URL的hash(比如window.location.hash)来保持URL和UI的同步的。需要重点注意的,<HashRouter>目前不支持location.key和location.state。总得来说,<HashRouter>更多的是为了和之前的浏览器兼容,目前还是推荐使用<BrowserRouter>。 所以,我们在代码中使用BrowserRouter。 先import我们需要使用的内容,下面再加入对应的route 这是我们可以看到其实浏览器的显示并没有什么特别大的改变,但其实此时我们是有了很多关于history的信息处理的,下面我们来多加入几个页面进行测试。 在src目录下加入About.js和Repos.js About.js    Repos.js 这时,我们继续修改index.js文件,为这几个page加上route: 这时,我们再进行测试,主要测试这两个页面: http://localhost:3000/about 以及http://localhost:3000/repos 并做一些浏览器的前进和后退的操作,我们可以看到一切和我们预想的还是一样的。 Link的使用 在我们的项目中其实用的比较多的就是link,达到的效果就是click某一个link之后,就会跳转到某一个页面,click另一个link则会跳转到另外一个页面,在react reouter里面可以通过link来简单实现。我们直接修改app.js如下,import进link 这是,打开对应的网页如下所示: 我们点击对应的about和repos超链接,可以到达不同的页面:…

Read More »

Azure Service Bus简单介绍和使用

我们知道现如今不同的应用或者服务之间decouple的趋势是越来越明显,而随之而来的问题就是这些应用或者服务之间如何进行可靠以及安全的数据或者状态传输,我们可以通过基于MSMQ或者RabbitMQ之类消息中间件来自我搭建和维护一套方案,也可以选择微软为我们提供的企业级的基于Azure的Service Bus来达到我们的目的。本文就来详细讨论一下Azure Service Bus。 两种基本的场景 目前Azure service Bus支持两种基本的场景,一种是基于Queue的message传输,一种是基于Topics的传输: Queue 发送端会把Message发送到queue,然后接收端从queue中接收message,在queue中的message是有序的,也就是所谓的FIFO,并且接收方只能是单一的,如下图所示: Topics 和Queue不同的是,一般来说Queue是点对点的传输,而Topic这是一个publish/subscribe的情况,也就是说可以有多接收方(我们称之为Subscriber),每个接收方都可以接收到一份完整的message的拷贝,你甚至可以设置一些filter的条件来决定在什么情况下哪些message可以被其中特定的receiver接收。 基本场景的实现 在我们实现sender和receiver端的代码之前,我们需要首先在azure上创建用来接收的queue或者topics,这个时候你需要一个Azure的订阅,或者注册一个免费的用户。 基于Queue的基本场景的实现 下面我们先来看一下基本场景中基于Queue的message的发送和接收如何用.NET代码实现: Azure portal中queue的创建 在Azure Portal中创建一个resource,选择service bus。 然后我们创建一个namespace,所谓的namespace就是一个container,他用来存放所有的service bus相关的内容,我们的queue或者topics都是建立于它的基础上。 在创建好了namespace之后,我们可以点击到刚刚创建的namespace,选择“Shared access policies”,然后点击“RootManageShareAccessKey”来得到我们在代码中需要使用的connection string,这里我们把primary connection string拷贝下来,后面的代码中会用到。 在我们的namespace中创建一个queue Send端的代码实现 在Portal创建好queue之后,我们就可以连接这个queue,进行发送message了。首先新建一个queueClient: 这里的ServiceBusConnectionString就是我们刚刚在portal那边拷贝的primary connection string。QueueName是我们创建的queue的名字。 然后利用下面的SendMessagesAsync来发送message到queue中: receiver端的代码实现 在我们发送message到queue中后,我们需要些一个简单的receiver端的代码来接收message,同样首先要创建一个queueClient: 通过RegisterMessageHandler来注册receiver的handler函数: 运行的结果 send端代码运行后的结果如下: 此时我们去azure portal的queue的界面可以看到有10个message在那边 此时再运行receiver端的代码,结果如下: 我们可以看到我们在receiver端按照顺序把所有的message都接收到了,此时再去看azure portal queue中,此时我们的active message count已经是0了。 至此,我们基于Queue的基本场景实现已经完成。 基于Topics的基本场景实现 基于Topics和基于Queue的实现基本很类似,就是在create queue那一步稍有不同,我们需要创建topic,毕竟这里使用的不是queue: 在namespace中create topic 在已经创建的topic上面创建subscriptions Send端代码的实现 和queue的场景类似,我们需要新建对应的topicClient,代码如下: 相应的参数意义从名字上看应该是一目了然。这之后的sendmessage代码就和queue比较类似了: Receiver端代码的实现…

Read More »

WebSocket 简单介绍和使用

今天我们来和大家聊聊HTML5的Web Socket。 什么样的背景让这些疯狂的程序员们想出了WebSocket 在正式解释Web Socket之前,我们先来看这样一个场景:假设我们现在正在一个网站上看股价的实时变化图 ,我们希望能够及时得到股票的变化信息,那么从技术角度来讲,我们就需要及时得到server端数据变化的情况。一个简单的解决方案就是和PM argue,让user去不停地刷新页面,可惜很显然这样做的后果很可能会被PM拉去祭天,哈哈。 在和PM讨论无果败下阵来之后,我们该怎么办呢?因为HTTP连接是一个半双工的连接,它是基于request/response这样的形式来进行数据传输的,要想在这个技术上面实现实时的数据变化,我们无非有这样几种思路,一种就是我们定期进行轮询,发送request过去,等待response的到来。另外一种就是把一次connection的时间放长,让他能够在有更新时及时发送回来。基于这样的基础,有了以下几种实现: 轮询(polling) 轮询就是我们定期发送request,立即接受response。看起来还不错,但很显然问题就出在这个定期上面,因为我们并不知道server端的数据是什么时候能好,所以很难设置这个轮询的interval。假如设置小了,轮询太频繁,会有很多无效的request。假如设置大了,轮询的频率太低,就无法及时得到server端的数据更新了。 长轮询(long polling) 所谓长轮询就是在一定时间内没有response就保持连接存在,就像乞讨一样,不给钱就不走。当然计算机还没有这么无赖,在一定时间没有response,也会timeout。这种方法就解决了上面轮询设置interval的苦恼,如是能设置一个合理的timeout,也不需要担心有太多无效的request了。他的模型如下图一所示: 图一 长轮询示意图 毫无疑问,长轮询解决了之前轮询中的一些问题,但是仍然有很多问题没有解决,比如说假设我们的数据更新比较频繁,那么长轮询和轮询基本就没有差别了,这样我们为了获取及时的数据,就需要不停地发送request,这必然会有performance的issue。 流(stream) 既然长轮询也有问题,天才的ITers显然不会止步于此,你不是说我总是发送request会让performance不好,那好,我建立连接之后就不close了,一直在等待数据的刷新,直到被关闭或者超时(比如防火墙丢弃时间过长的连接,或者服务器端的timeout等)。流模式的模型如下图二所示 图二 流模式的示意图 那么这样的流模式是否就是完美无缺的呢,事实上也不是,因为流模式依然基于HTTP,他很有可能被防火墙或者代码buffer住response从而导致latency,这时我们就需要选择TLS(SSL)来避免response被buffer,在这种情况下连接的建立和关闭就会很重。另外一个问题就是,这仍然是一个半双工的情况,就是client如果想在连接过程中发送数据给server,仍然只能建立一个新的连接。 什么是WebSocket 好了,讲了这么多,该是时候回归到本文想讲的内容了,WebSocket。 我想不用我多说,大家应该可以猜到了,websocket就是用来解决上面这些问题的。WebSocket是一个全双工的双向的通信通道。只需要建立一次连接,可以一直保持,而且是双向都可以主动进行通信。WebSocket的模式示意图如下图三所示: 图三 websocket的模式示意图 WebSocket的特点 WebSocket有以下几个特点: (1)建立在 TCP 协议之上,服务器端的实现比较容易。 (2)与 HTTP 协议有着良好的兼容性。默认端口也是80和443,并且握手阶段采用 HTTP 协议,因此握手时不容易屏蔽,能通过各种 HTTP 代理服务器。 (3)数据格式比较轻量,性能开销小,通信高效。 (4)可以发送文本,也可以发送二进制数据。 (5)没有同源限制,客户端可以与任意服务器通信。 (6)协议标识符是ws(如果加密,则为wss),服务器网址就是 URL。 WebSocket Client如何使用 我们从图三可以看出,WebSocket其实有Client端和Server端两块,那么Client端是如何编程的呢,首先我们第一步需要和server端建立一个连接,建立连接的代码如下: 其中第一个url就是我们要连接的url,也就是server端的url。第二个参数protocol是可选的,指定了可接受的子协议。 在我们使用了上面的代码建立了连接之后,我们可以通过Socket.send()的方法主动向server发送message,也可以通过Socket.close()来关闭连接了。 除了主动出击外,我们还可以设置各种事件的回调函数,用来处理连接的开关,出错以及收到message等事件,websocket支持的事件如下表所示: 事件 事件处理程序 描述 Open Socket.onopen 连接建立时触发 message Socket.onmessage 客户端接收到服务端的数据时触发 error Socket.onerror…

Read More »