如何使用Laravel 和 Vue 构建一个简单的SPA

luigi liccardo unsplash

本教程是作者自己在学习Laravel和Vue时的一些总结,有问题欢迎指正。

Laravel是PHP的一个框架,Vue是前端页面的框架,这两个框架如何结合起来构建一个SPA(Single Page Application)呢?流程大致分为下面三步:

  1. 页面请求Laravel的一个路由
  2. 路由返回渲染一个包含了Vue的SPA框架
  3. 在上面渲染出来的框架中使用Vue来加载不同的页面单元模块

主要会学习使用到三个东西:

  1. laravel
  2. vue.js
  3. Vue-router
  4. axios

上面是一个简单的流程图,从图中我们可以看到,当请求34的路由时,并不会再次请求后端的Laravel,而是前端渲染了。

说了这么多,我们开始写代码吧~

1. 安装

1
2
3
4
5
6
composer create-project --prefer-dist laravel/laravel laravel-spa "5.6.*"

cd laravel-spa

npm install
npm install vue-router

安装好laravelvue-router后,我们需要配置前端路由和路由对应的组件

2. 配置Vue Router

Vue Router中把route和vue组件做了一个映射,在渲染时会把不同的组件渲染到<router-view></router-view>标签中。

首先,我们修改resources/assets/js/app.js这个文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
window.Vue = require('vue');
// 或者
import Vue from 'vue'

import VueRouter from 'vue-router'
// 引入Vue Router并加载到Vue中
Vue.use(VueRouter)

// 引入我们要使用到的几个组件
import App from './views/App'
import Hello from './views/Hello'
import Home from './views/Home'

// 实例化一个Vue Router
const router = new VueRouter({
mode: 'history',
base: '/spa',
routes: [
{
path: '/', // 这是路径
name: 'home', // 这是名称
component: Home // 这是使用的组件
},
{
path: '/hello',
name: 'hello',
component: Hello
}
],
});

// 注入Vue Router 实例,我们就能在vue里面这样使用: this.$router, this.$route
const app = new Vue({
el: '#app',
components: { App, },
router
});

然后,新建以下几个文件:

1
2
3
4
mkdir resources/assets/js/views
touch resources/assets/js/views/App.vue
touch resources/assets/js/views/Home.vue
touch resources/assets/js/views/Hello.vue

App.vue是所有组件的父组件,负责渲染其他页面,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<template>
<div>
<h1>Vue Router Demo App</h1>

<p>
<router-link :to="{ name: 'home' }">Home</router-link> |
<router-link :to="{ name: 'hello' }">Hello World</router-link> |
</p>

<div class="container">
<router-view></router-view>
</div>
</div>
</template>
<script>
export default {}
</script>

注意这个router-view标签,Vue Router会将组件渲染到该标签里面。其他几个页面就是我们需要展示的组件页面了。

Home.vue :

1
2
3
<template>
<p>This is the homepage</p>
</template>

Hello.vue :

1
2
3
<template>
<p>Hello World!</p>
</template>

现在的目录结构是把页面的模版和组件模版放在同一个目录里面的,为了方便管理,我们可以把重用的组件单独放一个component目录里。

3. 后端代码

SPA应用主要是以接口的形式请求的,后端在接收到页面请求时不需要做过多的处理,代码也很简单,routes/web.php修改如下,删除了原来的/路由:

1
Route::get('/{any}', 'SpaController@index')->where('any', '.*');

创建一个SpaController

1
php artisan make:controller SpaController

SpaConrtollerindex方法中我们直接返回需要渲染的模版:

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class SpaController extends Controller
{
public function index()
{
return view('spa');
}
}

最后,编辑resources/views/spa.blade.php模版:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Laravel Vue SPA Demo</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="csrf-token" content="{{ csrf_token() }}">
</head>
<body>
<div id="app">
<app></app>
</div>
</body>

<script src="{{ mix('js/app.js') }}"></script>
</html>

基本完成,现在来看看效果,因为laravel已经集成了一些前端开发的脚手架,可以说非常友好了,所以在写好前端的组件后,运行如下命令就能打包前端代码了:

1
npm run watch



现在我们简单的SPA静态页面已经搭建完成了,可以看到当切换URL时,整个页面的主题和菜单并没有换,更新的只是下面的内容,接下来我们是这调用后端的API。

4. 编写一个测试API

由于是测试,后端代码很简单,就几行,routes/api.php修改如下:

1
2
3
Route::get('/users', function () {
return factory('App\User', 10)->make();
});

上面就是我们编写的一个简单接口,我么直接在路由中使用了Laravel现成的User模型mock10条数据,注意,由于Laravel中webapi是单独分开的,所以在访问api接口时需要加上/api前缀,分析App\Providers \RouteServiceProvider文件就能看出来:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/**
* Define the "api" routes for the application.
*
* These routes are typically stateless.
*
* @return void
*/
protected function mapApiRoutes()
{
Route::prefix('api')
->middleware('api')
->namespace($this->namespace)
->group(base_path('routes/api.php'));
}

我们试着访问下接口:

接口写好,现在我们需要在前端用axios调用我们的接口。

5. axios上手

现在回到我们Vue Router的配置中,添加一个组件并定义一个新的路由:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import UsersIndex from './views/UsersIndex'


const router = new VueRouter({
mode: 'history',
base: '/',
routes: [
{
path: '/',
name: 'home',
component: Home
},
{
path: '/hello',
name: 'hello',
component: Hello
},
{
path: '/users',
name: 'users.index',
component: UsersIndex
}
],
});

实现UsersIndex组件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<template>
<div class="users">
<div v-if="loading" class="loading">Loading</div>
<div v-if="error" class="error">
<p>{{ error }}</p>

<p><button @click.prevent="fetchData">Try again</button></p>
</div>

<ul v-if="users">
<li v-for="{name, email} in users" @key="name">
<strong>Name: </strong>{{ name }},
<strong>Email: </strong>{{ email }}
</li>
</ul>
</div>
</template>

<script>
import axios from 'axios';

export default {
data() {
return {
loading: false,
users: null,
error: null,
};
},
created() {
this.fetchData()
},
methods: {
fetchData() {
this.error = this.users = null;
this.loading = true;
axios.get('/api/users')
.then(response => {
this.loading = false;
this.users = response.data;
})
.catch(error => {
this.loading = false;
this.error = error.response.data.message || error.message;
})
}
}
}
</script>

这个Vue的组件很简单,说说fetchData这个方法,使用了axiosget我们写好的后端接口,将得到的数据用Vue在前端渲染出来,看看效果:

我们成功获取到了后端数据,并在前端渲染出来。到此,我们现在已经了解了开发SPA应用的简单流程。

6. 最后再来个总结吧

使用SPA有什么好处呢?第一,不同页面之前切换时不会有明显的变化,至少整个页面框架不会切换,前端再配合一个loading动画,会更加友好,而全部用服务端渲染,页面在切换时会有一段时间的页面空白现象,在网速不理想的情况下空白的时间会更长。第二,职责更加清晰,SPA应用完全是前后端分离,后端只需要认真编写接口,前端只要获取并渲染,开发人员不需要同时看后端代码和前端代码,职责清晰的同时保证了码代码的效率,第三,SPA是无状态的,不需要管理session

参考 :
https://laravel-news.com/using-vue-router-laravel
https://router.vuejs.org/zh/

软件设计复杂性的体现

封面来源: https://www.pexels.com

《A Philosophy of Software Design》读书笔记(2)

软件设计的复杂性到底有哪些表现呢?

一般表现为三种方式,并且每一种方式都会是开发任务更难执行。

1. 当新增特性时,需要修改大量的代码


首先,复杂性会体现在代码修改上,看似很简单的一处代码修改,往往需要涉及到很多地方。比如,一个网站由许多页面组成,每个页面都需要显示一个带背景的导航栏,最糟糕的方式是这个背景颜色分别定义在每一个页面上,如果要改变这个网站的背景颜色,我们就必须针对每一个页面手动修改,如果有数百个页面这就很不现实。解决办法是我们可以将这个背景颜色定义到一个单独的样式文件中,在每个页面引用这个样式文件,这样如果要修改背景颜色就只需要做一次修改。好的设计可以减少受每个设计决策影响的代码量,因此设计更改不需要太多的代码修改。

2. 当需要完成一个功能时,开发人员需要了解许多知识


这种体现在当我们要完成一个任务时,我们要对代码有多深入的理解。理解程度高,就代表我们要花更多的时间来阅读代码,我们都知道读别人写的代码是很艰难的,可能还得骂人。在这过程中,很可能就会产生bug,因为我们会疏忽某些地方的代码。比如有一个C函数用来申请内存空间的,并返回指针,设计这个函数的人想着调用者自己释放内存,这种情况就增加了对代码的理解成本,后面的人如果忘记释放内存,就会导致程序内存溢出。如果这个函数在设计的时候,不需要调用者关心内存的释放,这就可以降低对代码的理解程度。

一般,有多个方法的API、全局变量、代码的不一致和模块间的依赖都会使代码难理解。

系统的设计者通常都会用代码的行数来衡量系统的复杂性,他们认为代码行数越少,系统就越简单,在修改代码时,修改的越少那么这个修改就越简单。但是,这种观点忽视了前期理解代码的成本。相反,行数多的代码事实上才是简单的,因为它不需要花费很多精力理解代码。

3. 当新增/修改功能时,不能明显地知道要修改哪些地方


第三个就是在修改代码时,不能很明显的确认哪一部分代码需要修改或者是在修改时不清楚需要注意的点。比如在一个控制器中,我们给一个Model设置一些筛选条件来获取列表数据,由于这个Model已经有了base条件,后加的条件有可能会和base条件产生冲突,在不清楚的情况下,我们添加筛选后就可能会返回空数据。还是拿上面的背景颜色举例,我们把背景颜色放在了一个单独的样式文件中,只要修改一个地方就能使所有页面更新,但是在某些页面,导航栏还需要一个深色的阴影,更改了导航栏背景色后还需要修改阴影的颜色,如果没有意识到这一点,网站看起来可能就不协调,尽管有人会意识到这个问题,但也需要搜索每一个页面查看是否有这个阴影并修改。

上面三个代码复杂的体现中,第三点是最糟糕的,不知道不知道意味着有些点你应该知道,但是你没有办法发现它,这存在很大的隐患,只有出现bug时你才会发现。修改的复杂也是很恼人的,但只要让需要修改的代码保持干净清晰,系统就会正常工作,同样的,对于第二点,只要保证有清晰的文档就可以使修改正确,第三点因为不知道不知道,最保险的方式就是去阅读每一行代码,当然这也不太现实,项目中往往会有很多依赖,也许某些依赖还没有文档。

对于一个设计良好的软件系统来说,工程师能很快理解现有代码并很快修改它,而不会有任何疑惑。

关于软件设计的复杂性

封面来源: https://unsplash.com

《A Philosophy of Software Design》读书笔记(1)

通常,在描述一款软件系统的开发过程时,都会使用复杂性来衡量,而这里所说的复杂性是指:任何与软件系统结构有关并使整个系统难以理解和修改的设计。在软件设计时,复杂性有很多不同形式的体现,比如:某一段代码很难理解;一些小的代码修改却要花费很大的精力,或者是修改代码时不确定这段代码是否必须修改;修改一个 bug又会引入新的bug。事实上,如果一个软件系统很难理解或修改,那么这个系统一定是复杂的,相反,就是简单的。

同时,软件设计的复杂性也和成本相关。在一个复杂的系统中,哪怕是一点小小的改进都需要消耗大量的资源(人力物力财力),而在简单的系统中,大的改进往往只需要很小的精力。

上面所说的复杂性是开发人员在尝试实现特定目标时在特定时间点所体验到的,它不一定与系统的整体大小或功能有关。人们通常用“复杂”这个词来描述一个有很多复杂功能的系统,但如果这个系统使用起来很方便,那么使用我们上面说的“复杂性”衡量是有失偏颇的。

当然,鱼和熊掌不能兼得。事实上几乎大多数大型的复杂的软件系统使用起来都不简单。

软件设计的复杂性通常是由一些常见的活动决定的,如果一个系统中有些部分特别复杂,但是这些部分从来不会被使用到,那么它们就不会影响到整个系统的复杂性,我们可以用如下的数学公式来描述一下:

整个系统的复杂性(C)是由每个部分的复杂性(cp)决定的,cp的权重是开发人员在该部分花费的时间(tp)的比例。

相较于开发人员,复杂性对使用者来说更加明显。比如你写了一段自认为很简单的代码,如果别人阅读你的代码时感觉到复杂,那就说明这段代码是复杂的。当遇到这种情况时,我觉得有必要向别人讨论复杂的原因,与别人交流观点也是很有意思的。工程师的职责并不只是写出你认为简单的代码,也需要让同事之间的合作更方便。

PHPStorm中快速选中多个相同的单词

如何在编辑器中快速选中相同的单词,类似于Visual Studio Code中的Command+D,强大的IDEA怎么会不支持呢。拿PHPStorm来说一下吧。

Preference里面,选择keymap,在右边搜索select next,会出现如下结果:

phpstorm preference

Add Selection for Next Occurrence就是我们想要的,默认是^+G,就是control+G,这两个键的距离里的还是很远的,我们可以手动设置,同时,这个选项的上一个选项Find Next / Move to Next Occurrence,这也是一个很实用的快捷键,可以快速调转到下一个相同的词,快捷键为Command+G

不止于此,插件市场中还有相关的插件,在插件市场中搜索browse wor(不需要写全,会自动出来)

BrowseWordCaret

但是这个插件我并没有弄懂它的快捷键在Mac上怎么用的,于是果断卸载用自带的快捷键。

简单聊聊PHP中的反射(Reflection)

简单聊聊PHP中的反射

和Java一样PHP中也提供了一套完整的反射API,何为反射?以前我们是先写类,再在类中添加各种方法和属性,最后实例化一个类对象调用属性和方法。那有我们没有办法只通过这个实例对象获取到关于这个类的全部信息呢,包括有哪些方法和属性它们分别在多少行?答案就是反射

几个常用的反射API的类
类名 作用
Reflection 为类提供摘要信息
ReflectionClass 对类提供反射
ReflectionMethod 对方法提供反射
ReflectionParameter 对方法参数提供反射
ReflectionProperty 对类属性提供反射
ReflectionFunction 对函数提供反射
ReflectionExtension 对扩展提供反射
ReflectionException 对异常提供反射

ReflectionClass

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class People {
protected $name = 'Foo';
protected $age = 18;

public function __construct($name,$age)
{
$this->name = $name;
$this->age = $age;
}

public function toString()
{
echo "Name: $this->name, Age: $this->age" . PHP_EOL;
}
}

class Student extends People {
public $major;

public function __construct($name, $age, $major)
{
$this->major = $major;
parent::__construct($name, $age);
}

public function toString()
{
echo "Name: $this->name, Age: $this->age, Major: $this->major" . PHP_EOL;
}
}

$reflect = new ReflectionClass('Student');
Reflection::export($reflect);

输出结果如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Class [ <user> class Student extends People ] {
@@ /…/demo1.php 18-31

- Constants [0] {
}

- Static properties [0] {
}

- Static methods [0] {
}

- Properties [3] {
Property [ <default> public $major ]
Property [ <default> protected $name ]
Property [ <default> protected $age ]
}

- Methods [2] {
Method [ <user, overwrites People, ctor> public method __construct ] {
@@ /…/demo1.php 21 - 25

- Parameters [3] {
Parameter #0 [ <required> $name ]
Parameter #1 [ <required> $age ]
Parameter #2 [ <required> $major ]
}
}

Method [ <user, overwrites People, prototype People> public method toString ] {
@@ /…/demo1.php 27 - 30
}
}
}

可以看到,Reflection::export几乎提供了Student类的所以信息,包括属性和方法的访问控制状态,每个方法需要的参数以及每个方法在脚本中的位置,和var_dump相比,在使用var_dump前总是需要实例化一个对象,而且无法提供那么多详细信息。

var_dump输出如下:

1
2
3
4
5
6
7
8
object(Student)#1 (3) {
["major"]=>
string(2) "CS"
["name":protected]=>
string(5) "Jason"
["age":protected]=>
int(21)
}

虽然var_dumpprint_r是打印数据的利器,但对于类和函数,反射API提供了更高层次的功能。