随着vue 3越来越受重视并成为默认版本,许多事情正在发生变化,生态系统逐渐完善中。直到最近,Vue3 的状态管理默认推荐的是使用 Pinia。这节课,我们根据项目的规模,探索不同的状态管理方式,并尝试预测 Vue 中状态管理的未来会是什么样子。
在options API中,我们可以使用 data() 选项为一个组件声明响应式数据。在内部,返回的对象被包在响应式帮助器中。这个帮助器也可以作为一个公共API使用。
如果是多个数据被多个实例共享的状态,那么 可以使用 reactive()来创建一个 reactive 对象,然后从多个组件中导入它。
import { reactive } from "vue";
export const store = {
state: reactive({
heroes: ['Aragorn', 'Legolas', 'Gimli', 'Gandalf']
}),
addHero(hero) {
this.state.heroes.push(hero);
}
};
通过这种方法,数据被集中起来,并可以在各个组件之间重复使用。这可能是一个简单的选择,对一个小的应用程序来说占用的空间最小。
一个类似的概念,即composition API带来的概念,是使用一个组合 。这种模式在React 那么非常流行,结合Vue强大的响应性机制,可以编写一些优雅的、可重复使用的可组合,比如下面这些:
import { ref, computed } from "vue";
import fakeApiCall from "../api";
export default function useFellowship() {
const heroes = ref([]);
const loading = ref(false);
async function init() {
loading.value = true;
heroes.value = await fakeApiCall();
loading.value = false;
}
return {
heroes: computed(() => heroes.value),
loading: computed(() => loading.value),
init
};
}
然后,可以这样使用:
<template>
<p v-if="loading">Loading...</p>
<p v-else>Companions: {{ heroes.join(", ") }}</p>
</template>
<script>
import useFellowship from "../composables/useFellowship";
import { computed } from "vue";
export default {
name: "MiddleEarth",
setup() {
const { heroes, loading, init } = useFellowship();
init();
return {
heroes: computed(() => heroes.value),
loading,
};
},
};
</script>
事例地址:https://codesandbox.io/s/composables-middle-earth-07yc6h?file=/src/composables/useFellowship.js
这种模式最初是为了取代 mixins 而引入的,因为现在的组合比继承更受欢迎。但它也可以用来在组件之间共享状态。这也是许多为取代 Vuex 而出现的库背后的主要想法。
Vuex是不会消失的。它支持Vue 3,具有相同的API和最小的破坏性变化(这可能是其他库应该注意的)。唯一的变化是,安装必须发生在一个 Vue 实例上,而不是直接安装在 Vue 原型上。
import { createApp } from 'vue'
import { store } from './store'
import App from './App.vue'
const app = createApp(App)
app.use(store)
app.mount('#app')
Vuex 4 仍在维护中。不过,不会再有很多新的功能被添加到它里面。如果你已经有一个使用Vuex 3的项目,并想推迟迁移到其他东西上,这是一个不错的选择。
Pinia 开始是一个实验,但很快就成为 Vue 3 的主要选择。它提供了比 Vuex 更多的 API ,有更好的架构和更直观的语法,充分利用了组合API。
在开发工具的支持上(状态检查、带动作的时间线和时间旅行的能力),以及 Vuex 所提供的使用插件的扩展性,pinia 在设计上是类型安全和模块化的,这是使用Vuex时最大的两个痛点。
此外,定义 story 的语法与 Vuex 模块非常相似,这使得迁移的工作量非常小,而在使用该 store 时,用到的 API,接近于 Vue3 使用组合API的方式。
import { defineStore } from 'pinia'
export const useFellowship = defineStore('fellowship', {
state: () => {
return { heroes: ['Aragorn', 'Legolas', 'Gimli', 'Gandalf'] }
},
actions: {
addHero(hero) {
this.heroes.push(hero)
},
},
})
<script>
import { useFellowship } from '@/stores/fellowship'
export default {
setup() {
const fellowship = useFellowship()
// 对状态的访问
//可以直接进行
console.log(fellowship.heroes)
// Using an action
fellowship.addHero('Boromir')
},
}
</script>
你可能已经注意到的,最大的区别是 mutations 完全消失了。它们通常被认为是极其冗长的,而使用它们没有任何真正的好处。此外,也不再需要命名空间了。有了新的导入 store 的方式,所有的东西都被设计成了命名空间。这意味着,在 Pinia 中,你没有一个带有多个模块的 store ,而是有多个按需导入和使用的 store 。
Pinia支持另一种语法来定义 store。它使用一个定义响应式属性和方法的函数,并返回它们,与Vue Composition API的 setup 函数非常相似。
import { defineStore } from 'pinia'
export const useFellowship = defineStore('fellowship', () => {
const heroes = ref([]);
function addHero(hero) {
heroes.value.push(hero)
}
return {
heroes,
addHero
};
})
在 Setup Stores 中:
Setup stores 比 Options Store 带来了更多的灵活性,因为可以在一个 store 内创建 watchers ,并自由使用任何可组合的。
创建一个 fellowship store,它可以容纳一个 heroes 列表,并能添加和删除对应的元素:
import { defineStore } from 'pinia'
export const useFellowship = defineStore('fellowship', {
state: () => ({
heroes: [],
filter: 'all',
// type will be automatically inferred to number
id: 1
}),
getters: {
aliveHeroes(state) {
return state.heroes.filter((hero) => hero.isAlive)
},
deadHeroes(state) {
return state.heroes.filter((hero) => !hero.isAlive)
},
filteredHeroes() {
switch (this.filter) {
case 'alive':
return this.aliveHeroes
case 'dead':
return this.deadHeroes
default:
return this.heroes
}
}
},
actions: {
addHero(name) {
if (!name) return
// Directly mutating the state!
this.heroes.push({ name, id: this.id++, isAlive: true })
},
killHero(name) {
this.heroes = this.heroes.map((hero) => {
if (hero.name === name) {
hero.isAlive = false
}
return hero
})
},
setActiveFilter(filter) {
this.filter = filter
}
}
})
如果你熟悉Vuex,那么理解这段代码应该不是什么难事。
首先,每个 state 都需要一个作为命名空间的键。这里,我们使用 fellowship。
state 是一个函数,保存这个 store 的所有响应性数据,getters 是访问 store 里面的数据。state 和 getters 都与Vuex相同。
但对于 actions 来说与 Vuex 差异比较大。上下文参数已经消失了,actions 可以直接通过 this 访问 state 和 getters 。你可能已经注意到的,actions 直接操作 state,这在Vuex 中是被严格禁止的。
最后,由于状态操作现在是在 actions 进行的,所以 mutations 被完全删除。
使用 pinia store 很简单:
<script>
import { useFellowship } from '../store/fellowship'
import HeroFilters from './HeroFilters'
export default {
name: 'MiddleEarth',
components: {
HeroFilters
},
setup() {
const fellowship = useFellowship()
return {
fellowship
}
}
}
</script>
<template>
<div>
<template v-if="fellowship.heroes.length">
<HeroFilters />
<ol>
<li v-for="hero in fellowship.filteredHeroes" :key="hero.id">
{{ hero.name }} - {{ hero.isAlive ? 'Alive' : 'Dead' }}
<button v-if="hero.isAlive" @click="fellowship.killHero(hero.name)">Kill</button>
</li>
</ol>
</template>
<p v-else>Your fellowship is empty</p>
<div>
<input type="text" ref="heroName" />
<input type="button" value="Add new hero" @click="fellowship.addHero($refs.heroName.value)" />
<p>
Sugestions:
<button
v-for="suggestion in ['Aragorn', 'Legolas', 'Gimli']"
:key="suggestion"
@click="fellowship.addHero(suggestion)"
>
{{ suggestion }}
</button>
</p>
</div>
</div>
</template>
所有的逻辑都发生在 setup 函数中。导入的 useFellowship 钩子被执行并返回。这样在 template 就可以直接。
当然,这个组件应该被分解成更小的可重复使用的组件,但为了演示的目的,就先这样吧。
如果一个不同的组件需要访问相同的 state,可以用类似的方式来完成。
<script>
import { useFellowship } from '../store/fellowship'
export default {
name: 'HeroFilters',
setup() {
const fellowship = useFellowship()
return {
fellowship
}
}
}
</script>
<template>
<div>
Filter:
<div v-for="filter in ['all', 'dead', 'alive']" :key="filter">
<input
type="radio"
:value="filter"
:id="filter"
@click="fellowship.setActiveFilter(filter)"
v-model="fellowship.filter"
/>
<label :for="filter">{{ filter }}</label>
</div>
</div>
</template>
事例地址:https://codesandbox.io/s/composables-middle-earth-07yc6h?file=/src/composables/useFellowship.js
Pinia的文档很乐观,认为代码可以在库之间重复使用,但事实是,架构非常不同,肯定需要重构。首先,在Vuex中,我们有一个带有多个模块的 store ,而 Pinia 是围绕着多个 store 的概念建立的。将这一概念过渡到Pinia 中的最简单方法是,以前使用的每个模块现在都是一个 store 。
此外,mutations 不再存在。相反,这些应该转换为直接访问和改变状态的操作。
Actions 不再接受上下文作为其第一个参数。它们应该被更新以直接访问状态或任何其他上下文属性。这同样适用于 rootState、rootGetters等,因为单一全局存储的概念并不存在。如果你想使用另一个 store,需要明确地导入它。
很明显,对于大型项目来说,迁移将是复杂和耗时的,但希望大量的模板代码将被消除,store 将遵循一个更干净和模块化的架构。改造可以逐个模块进行,而不是一次性改造所有内容。实际上,在迁移过程中,可以将 Pinea 和Vuex混合在一起,这种方法对于复杂的项目来说也是不错的选择。
预测未来并不容易,但就目前而言,Pinea 是最安全的赌注。它提供了一个模块化的架构,通过设计实现类型安全,并消除了模板代码。如果你要用Vue 3开始一个新的项目,Pinia 是值得推荐的选择。
如果你已经在使用Vuex,你可以在迁移到Pinia之前升级到第4版,因为这个过程看起来很简单,但需要大量的时间。
作者:Fotis Adamakis 译者:前端小智 来源:mediun
原文:https://fadamakis.medium.com/the-future-of-state-management-in-vue-js-fa3f94865d1f
网页是用户与网站对接的入口,当我们允许用户在网页上进行一些频繁的操作时,对用户而言,误删、误操作是一件令人抓狂的事情,“如果时光可以倒流,这一切可以重来……”。
在React写应用的时候,难免遇到跨组件通信的问题。现在已经有很多的解决方案。React本身的Context,Redux结合React-redux,Mobx结合mobx-react
这个库的作者希望使用 React 内置 API ,直接实现状态管理的功能。看完这个库的说明后,没有想到代码可以这个玩。短短几行代码,仅仅使用 React Hooks ,就实现了状态管理的功能。
我们平时开发的大部分项目,由于复杂度不够, 很少使用 Vuex、Redux 等状态管理库,就算引入了 Vuex 这些库,也只是当作一个全局数据引用,并非对应用状态进行管理。但一旦页面的复杂度比较高,必然要引入状态管理,今天就聊聊我理解中的状态管理。
React Hooks 在 2018 年年底就已经公布了,正式发布是在 2019 年 5 月,关于它到底能做什么用,并不在本文的探讨范围之内,本文旨在摸索,如何基于 Hooks 以及 Context,实现多组件的状态共享,完成一个精简版的 Redux。
首先要明确为什么要使用redux,这一点很重要,如果不知道为什么使用redux,那么在开发的过程中肯定不能合理的使用redux.首先来看redux的本质:redux做为一款状态管理工具,主要是为了解决组件间通信的问题。
当我们使用编译器创建一个新Flutter应用的时候,我们可以在主界面看到两个小部件StatelessWidget和StatefulWidget。这是两个最常见使用最频繁的小部件了。StatelessWidget ,StatefulWidget
本文回答了以下问题:么是共享可变状态?为什么会出现问题?如何避免其问题?标有(高级)的部分会更深入,如果你想更快地阅读本文,可以跳过。
项目不大, 又不想用Vuex, 那么使用Observable来实现状态共享也不失为一个选择。用法 :让一个对象可响应。Vue 内部会用它来处理 data 函数返回的对象
当我们登录成功,在这个页面刷新,页面并没有保存登录状态;今天我们就来看一下如何在后台使用cookie保存用户登录状态。做到刷新页面仍然显示在用户登录界面。node实现保持登录状态的方法如下:
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!