Vuex 작업 vs 돌연변이
Vuex에서 "동작"과 "교화"를 모두 갖는 논리는 무엇인가?
구성 요소들이 상태를 수정할 수 없다는 논리(똑똑해 보이는 것)는 이해하지만, 작용과 돌연변이를 모두 갖는 것은 다른 기능을 촉발시키고, 그 다음 상태를 변화시키기 위해 하나의 함수를 쓰는 것처럼 보인다.
'행동'과 '교화'의 차이점은 무엇이며, 어떻게 함께 작동하는지, 게다가 Vuex 개발자들이 왜 이렇게 하기로 했는지 궁금하다.
질문 1: Vuejs 개발자들이 왜 이런 식으로 하기로 결정했는가?
답변:
- 당신의 어플리케이션이 커지면, 그리고 이 프로젝트를 위해 여러 개발자들이 일하고 있을 때, 당신은 "국가 관리" (특히 "글로벌 상태")가 점점 더 복잡해 질 것이라는 것을 알게 될 것이다.
- vuex 방식(Redex in reaction.js와 마찬가지로)은 상태를 관리하고 상태를 유지하며 "저장 및 추적 가능"을 위한 새로운 메커니즘을 제공한다(즉, 상태를 수정하는 모든 작업은 디버그 도구:vue-devtools를 통해 추적할 수 있음).
질문 2: "행동"과 "교화"의 차이는 무엇인가?
먼저 공식 설명을 보시겠습니다.
돌연변이:
Vuex 돌연변이는 본질적으로 사건이다: 각각의 돌연변이는 이름과 처리기를 가지고 있다.
import Vuex from 'vuex' const store = new Vuex.Store({ state: { count: 1 }, mutations: { INCREMENT (state) { // mutate state state.count++ } } })작업:행동은 돌연변이를 보내는 기능일 뿐이다.
// the simplest action function increment ({commit}) { commit('INCREMENT') } // a action with additional arguments // with ES2015 argument destructuring function incrementBy ({ dispatch }, amount) { dispatch('INCREMENT', amount) }
위 사항에 대한 나의 설명은 이렇다.
- 돌연변이가 상태를 수정하는 유일한 방법이다.
- 돌연변이는 사업논리에 신경쓰지 않고 단지 "국가"에만 신경쓴다.
- 행동은 비즈니스 논리다.
- 동작은 한 번에 1개 이상의 돌연변이를 일으킬 수 있으며, 단지 비즈니스 논리를 구현하고, 데이터 변경에 상관하지 않는다(변이에 의해 관리됨).
돌연변이는 동기식인 반면, 동작은 비동기식일 수 있다.
다른 방식으로 말하자면, 동기식 운영인 경우 작업이 필요하지 않고, 그렇지 않은 경우 작업을 구현할 필요가 없다는 것이다.
나는 돌연변이와 행동 뒤에 숨겨진 동기를 이해하는 것이 사람들이 언제 그리고 어떻게 사용해야 하는지를 더 잘 판단할 수 있게 해준다고 믿는다.그것은 또한 "규칙"이 모호해지는 상황에서 프로그래머를 불확실성의 부담으로부터 해방시킨다.각자의 목적에 대해 조금 추론해 본 결과, 행동과 돌연변이를 사용하는 방법이 분명히 잘못된 것일 수 있지만, 나는 표준적인 접근법이 있다고 생각하지 않는다는 결론에 도달했다.
먼저 우리가 왜 돌연변이나 행동을 겪었는지 이해해보자.
애초에 왜 보일러를 통과했을까?구성 요소에서 직접 상태를 변경하지 않는 이유는?
엄밀히 말하면, 당신은 그것을 바꿀 수 있다.state구성 요소로부터 직접.그state단지 자바스크립트 객체일 뿐이며, 그것에 대한 변화를 되돌릴 마법 같은 것은 없다.
// Yes, you can!
this.$store.state['products'].push(product)
하지만, 이렇게 함으로써 당신은 주정부 돌연변이를 사방에 흩어지게 된다.단순히 주(州)를 수용하는 단일 모듈을 여는 능력을 상실하고, 그것에 어떤 종류의 운영이 적용될 수 있는지 한눈에 볼 수 있다.중앙집중식 돌연변이를 갖는 것은 비록 일부 보일러플레이트 비용이 들지만 이것을 해결한다.
// so we go from this
this.$store.state['products'].push(product)
// to this
this.$store.commit('addProduct', {product})
...
// and in store
addProduct(state, {product}){
state.products.push(product)
}
...
나는 네가 짧은 것을 보일러 판으로 교체한다면 보일러 판도 작아야 한다고 생각해.그러므로 나는 돌연변이가 거의 사업논리가 없는 상태에서 주정부의 고유업무에 관한 매우 얇은 포장지일 것이라고 추측한다.즉 돌연변이는 대부분 세터처럼 사용되도록 되어 있다.
이제 돌연변이를 중앙 집중화했으므로 상태 변경에 대한 더 나은 개요를 얻을 수 있으며 툴링(vue-devtools)도 해당 위치를 알고 있으므로 디버깅이 더 쉬워진다.또한 많은 Vuex의 플러그인은 변화를 추적하기 위해 주를 직접 관찰하지 않고 오히려 그것을 위해 돌연변이에 의존한다는 것을 유념할 필요가 있다.따라서 국가에 대한 "무제한" 변화는 그들에게 보이지 않는다.
그렇게
mutationsactions그나저나 뭐가 다른데?
돌연변이와 같은 동작도 상점의 모듈에 상주하며, 이를 받을 수 있다.state반대하다그건 그들이 직접 변이할 수도 있다는 뜻이지그럼 둘 다 갖는 이유가 뭐야?만약 우리가 돌연변이를 작고 단순하게 유지해야 한다고 생각한다면, 그것은 우리에게 더 정교한 사업 논리를 수용하기 위한 대체 수단이 필요하다는 것을 암시한다.행동은 이것을 하기 위한 수단이다.그리고 우리가 앞서 구축한 바와 같이, vue-devtools와 플러그인은 돌연변이를 통한 변화를 인지하고 있으므로, 일관성을 유지하기 위해서는 우리의 행동에서 계속 돌연변이를 사용해야 한다.게다가 액션이 모두 포함되도록 되어 있고 액션이 캡슐화하는 논리가 비동기적일 수 있기 때문에 액션이 처음부터 비동기식으로 만들어지는 것도 일리가 있다.
돌연변이는 일반적으로 비동기적일 수 있는 반면, 행동은 비동기적일 수 있다는 것이 종종 강조된다.당신은 그 구별을 동기식(그리고 비동기식) 어떤 것에라도 돌연변이를 사용해야 한다는 표시로 볼 수 있지만, 예를 들어 둘 이상의 돌연변이를 저지르거나(동시적으로) 돌연변이를 통해 게터(Getter)와 작업해야 하는 경우, 돌연변이 펑티(funkti)로 몇 가지 어려움에 직면할 수 있다.온스는 게터도 돌연변이도 논쟁으로 받지 않는다...
...그것은 흥미로운 질문으로 이어진다.
돌연변이가 게이터를 받지 않는 이유는?
아직 이 질문에 만족할 만한 답을 찾지 못했다.기껏해야 무드를 발견했다는 핵심팀의 설명을 본 적이 있다.내가 그들의 사용법을 요약하면, 게터들은 주(州)에 대한 확장자를 계산(흔히 캐시)하도록 되어 있다.다시 말해서, 비록 초기 계산이 필요하지만, 그것들은 보통 읽기 전용이지만, 기본적으로 여전히 상태 입니다.적어도 그런 식으로 이용하도록 권장되는 것이다.
따라서 돌연변이가 게터스에 직접 접근하지 못하도록 막는 것은 후자가 제공하는 일부 기능으로부터 접근해야 하는 경우, (1) 게터가 제공하는 상태 계산이 돌연변이(나쁜 냄새)가 접근할 수 있는 어딘가에 중복되거나 (2) 계산된 값(또는)이 중복되는 경우, 이제 세 가지 중 하나가 필요하다는 것을 의미한다.관련 게터 자체)는 Getter(스텐치)가 제공하는 캐싱의 부가적인 이익 없이, 돌연변이(펑키) 또는 (3) 게터의 논리 자체가 직접 돌연변이 내에서 복제되는 명시적 주장으로 전승된다.
다음은 (2)의 예로서, 내가 접했던 대부분의 시나리오에서 "가장 나쁜" 옵션으로 보인다.
state:{
shoppingCart: {
products: []
}
},
getters:{
hasProduct(state){
return function(product) { ... }
}
}
actions: {
addProduct({state, getters, commit, dispatch}, {product}){
// all kinds of business logic goes here
// then pull out some computed state
const hasProduct = getters.hasProduct(product)
// and pass it to the mutation
commit('addProduct', {product, hasProduct})
}
}
mutations: {
addProduct(state, {product, hasProduct}){
if (hasProduct){
// mutate the state one way
} else {
// mutate the state another way
}
}
}
나에게 있어서, 위와 같은 것은 다소 난해할 뿐만 아니라, Action에 존재하는 코드의 일부가 Muti의 내부 논리로부터 분명히 흘러나오고 있기 때문에, 위와 같은 것은 다소 '약간'해 보인다.
내 생각에 이것은 타협을 암시하는 것이다.나는 돌연변이가 자동으로 겟터를 받는 것을 허용하는 것은 몇 가지 도전과제가 있다고 믿는다.그것은 Vuex 자체의 설계 또는 툴링(vue-devtools et al) 또는 일부 역호환성 또는 명시된 모든 가능성의 어떤 조합에 의해 이루어질 수 있다.
내가 믿지 않는 건 게터스를 네 돌연변이에게 직접 넘기는 건 네가 뭔가 잘못하고 있다는 징조라는 거야나는 그것이 단순히 프레임워크의 단점들 중 하나를 "패칭"하는 것으로 본다.
액션과 돌연변이의 주요 차이점:
- 돌연변이는 상태를 바꿀 수 있지만 그 상태는 변경할 수 없다.
- 내부 액션은 비동기 코드를 실행할 수 있지만 돌연변이는 실행할 수 없다.
- 돌연변이에 있는 게터, 상태, 돌연변이(암호화), 행동(분산) 등에 액세스할 수 있는 내부 액션은 상태에만 액세스할 수 있다.
내 생각에 TLDR의 대답은 돌연변이는 동기/트랜잭션을 의미한다는 것이다.따라서 Ajax 호출을 실행하거나 다른 비동기 코드를 실행해야 하는 경우, 작업에서 그런 다음 새로운 상태를 설정하기 위해 돌연변이를 실행해야 한다.
나는 약 3년 동안 Vuex를 전문적으로 사용해 왔으며, 여기에 행동과 돌연변이의 본질적 차이점, 그것들을 잘 함께 사용함으로써 어떻게 이익을 얻을 수 있는지, 잘 사용하지 않으면 어떻게 삶을 더 힘들게 할 수 있는지에 대해 알아냈다고 생각한다.
Vuex의 주요 목표는 애플리케이션의 동작을 제어하는 새로운 패턴을 제공하는 것이다.반응성.이 아이디어는 애플리케이션의 상태 조정을 전문 개체인 스토어로 오프로드하는 것이다.그것은 편리하게 당신의 구성품을 그들의 편의에 따라 사용하기 위해 당신의 저장 데이터에 직접 연결하는 방법을 제공한다.이렇게 하면 구성 요소가 사용자에게 표시할 템플릿, 스타일 및 기본 구성 요소 동작 정의와 같은 작업에 집중할 수 있다.한편, 저장소는 무거운 데이터 로드를 처리한다.
하지만 그것만이 이 패턴의 유일한 장점은 아니다.저장소가 애플리케이션 전체에서 단일 데이터 출처라는 사실은 많은 구성 요소에 걸쳐 이 데이터를 다시 사용할 수 있는 큰 잠재력을 제공한다.이것이 구성요소 간 통신의 이 문제를 해결하려는 첫 번째 패턴은 아니지만, 이 패턴이 빛을 발하는 부분은 구성요소가 이 공유 데이터의 상태를 수정하는 것을 기본적으로 금지함으로써 응용프로그램에 대해 매우 안전한 행동을 구현하도록 강요하고, 대신 변경을 요청하기 위해 "공용 엔드포인트"를 사용하도록 강제하는 것이다.
기본 아이디어는 다음과 같다.
- 스토어 내부 상태는 구성 요소에 의해 직접 액세스해서는 안 된다(mapState는 사실상 금지됨)
- 그 가게에는 내부 상태에 대한 동기식 수정인 돌연변이가 있다.돌연변이의 유일한 일은 상태를 수정하는 것이다.그들은 단지 행동에서 호출되어야만 한다.그들은 국가에 일어났던 일들을 설명하기 위해 이름을 지어야 한다(ORDER_CANCLEED, ORDER_CREATED).그것들을 짧고 달콤하게 유지해라.Vue Devtools 브라우저 확장 기능을 사용하여 디버깅할 수 있음(디버깅에도 적합!)
- 그 가게는 또한 비동기적이거나 약속을 반환해야 하는 행동들을 가지고 있다.그것들은 응용 프로그램의 상태를 수정하고자 할 때 구성 요소들이 호출하는 조치들이다.비즈니스 지향적인 작업(vbs, cancelOrder, createOrder)으로 이름을 지정해야 한다.이곳은 당신이 당신의 요청을 검증하고 보내는 곳이다.상태를 변경해야 하는 경우 각 조치는 다른 단계에서 다른 커밋을 호출할 수 있다.
- 마지막으로, 상점에 게터(getter)가 있는데, 이것은 당신이 당신의 상태를 당신의 부품에 노출시키기 위해 사용하는 것이다.애플리케이션이 확장됨에 따라 여러 구성 요소에 걸쳐 이러한 구성 요소가 많이 사용되기를 기대하십시오.Vuex 캐시는 불필요한 계산 주기를 피하기 위해 게터들을 많이 사용하므로(게터에 파라미터를 추가하지 않는 한, 파라미터를 사용하지 않도록 노력함) 망설이지 말고 광범위하게 사용하십시오.응용 프로그램이 현재 어떤 상태인지 가능한 가깝게 설명하는 이름을 지정하십시오.
말하자면, 마법은 우리가 이런 방식으로 우리의 응용 프로그램을 디자인하기 시작할 때 시작된다.예를 들면 다음과 같다.
- 사용자에게 주문 목록을 제공하는 구성 요소가 있으며 이러한 주문을 삭제할 수 있음
- 구성 요소가 ID가 있는 개체의 배열인 저장소 게터(deletableOrders)를 매핑한 경우
- 구성 요소에는 각 주문 행에 버튼이 있으며, 해당 클릭은 주문 개체를 전달하는 스토어 작업(deleteOrder)에 매핑되며, 이 작업은 스토어의 목록 자체에서 가져온 것임을 기억하십시오.
- store deleteOrder 작업은 다음을 수행한다.
- 삭제의 유효성을 확인하다.
- 임시로 삭제하라는 주문을 저장한다.
- 주문과 함께 주문 삭제된 돌연변이를 커밋함
- 실제로 주문을 삭제하기 위해 API 호출을 전송한다(예, 상태를 수정한 후!)
- 호출이 종료될 때까지 기다리며(상태는 이미 업데이트됨) 실패 시 ORDER_DELETE_를 호출한다.아까 우리가 지킨 명령으로 돌연변이가 실패했어.
- ORDER_DELINGED 돌연변이는 삭제 가능한 주문 목록에서 지정된 주문을 제거하기만 하면 된다(Getter 업데이트).
- ORDER_DELETE_고장 난 돌연변이는 단순히 오류를 되돌리고 오류에 대한 알림을 표시하도록 수정한다(오류 알림, 다른 구성 요소는 표시 시기를 알 수 있도록 상태를 추적하는 것이다).
결국, 우리는 "reactive"로 간주되는 사용자 경험을 가지고 있다.우리 사용자 입장에서는 아이템이 바로 삭제된 것이다.대부분의 경우, 우리는 우리의 엔드포인트가 단지 작동만 할 것으로 예상하기 때문에, 이것은 완벽하다.실패했을 때, 우리는 프런트 엔드 애플리케이션의 상태에 대한 우려와 실제 데이터를 성공적으로 분리했기 때문에, 우리의 애플리케이션이 어떻게 반응할지에 대한 통제력을 여전히 가지고 있다.
항상 가게가 필요한 건 아니잖아.다음과 같은 모양의 스토어를 작성하는 경우:
export default {
state: {
orders: []
},
mutations: {
ADD_ORDER (state, order) {
state.orders.push(order)
},
DELETE_ORDER (state, orderToDelete) {
state.orders = state.orders.filter(order => order.id !== orderToDelete.id)
}
},
actions: {
addOrder ({commit}, order) {
commit('ADD_ORDER', order)
},
deleteOrder ({commit}, order) {
commit('DELETE_ORDER', order)
}
},
getters: {
orders: state => state.orders
}
}
내게는 당신이 그 저장소를 단지 데이터 저장소로만 사용하고 있는 것 같고, 당신의 애플리케이션이 반응하는 변수를 통제하지 못하게 함으로써 그것의 반응성 측면도 놓치고 있는 것 같다.기본적으로, 당신은 당신의 구성 요소에 쓰여진 코드 몇 줄을 당신의 상점으로 오프로딩 할 수 있고 그리고 아마도 해야 할 것이다.
에 따르면
작용은 돌연변이와 유사하며, 차이점은 다음과 같다.
- 그 상태를 변이하는 대신, 행동은 변이를 저지른다.
- 작업은 임의의 비동기 작업을 포함할 수 있다.
다음 조각들을 고려해보라.
const store = new Vuex.Store({
state: {
count: 0
},
mutations: {
increment (state) {
state.count++ //Mutating the state. Must be synchronous
}
},
actions: {
increment (context) {
context.commit('increment') //Committing the mutations. Can be asynchronous.
}
}
})
작업 핸들러(증가)는 저장소 인스턴스에 동일한 메서드/속성 집합을 표시하는 컨텍스트 개체를 수신하므로 context.commit을 호출하여 돌연변이를 커밋하거나 context.state 및 context.getter를 통해 상태 및 getter에 액세스할 수 있다.
돌연변이:
Can update the state. (Having the Authorization to change the state).
작업:
Actions are used to tell "which mutation should be triggered"
인 리듀렉스 웨이
Mutations are Reducers Actions are Actions
왜 둘 다?
애플리케이션이 성장하고, 코딩 및 라인이 증가할 때, 돌연변이가 상태를 변화시킬 수 있는 유일한 권한이기 때문에 돌연변이가 아닌 행동의 논리를 처리해야 할 때, 가능한 한 깨끗해야 한다.
고지 사항 - 나는 방금 vuejs를 사용하기 시작했을 뿐이므로 이것은 단지 내가 설계 의도를 추론하는 것이다.
타임머신 디버깅은 상태의 스냅샷을 사용하며 작업 및 돌연변이의 타임라인을 보여준다.이론상으로는 우리가 그냥 할 수 있었을 텐데.actions돌연변이를 동시에 설명할 수 있는 상태 설정자와 게이터의 기록과 함께그러나 그 다음:
- 우리는 세터나 게이터를 유발하는 불순한 입력(아신크 결과)을 가질 것이다.이것은 논리적으로 따르기가 어려울 것이고 다른 비동기 세터들과 게터들이 놀랄 만큼 상호작용을 할 수 있다.그것은 여전히 와 함께 일어날 수 있다.
mutations거래는 행위에서 경쟁조건이 되는 것과는 반대로 개선될 필요가 있다고 말할 수 있다.비동기 프로그래밍은 취약하고 어렵기 때문에 행동 내부의 익명의 돌연변이는 이러한 종류의 버그를 더 쉽게 재조명할 수 있다. - 상태 변경에 대한 이름이 없기 때문에 트랜잭션 로그는 읽기 어려울 것이다.그것은 훨씬 더 코드같고 영어도 덜해서 변이들의 논리적인 그룹들을 놓칠 것이다.
- 돌연변이 함수 호출 전후에 동기적으로 정의된 확산 지점이 있는 현재와는 달리 데이터 개체의 돌연변이를 기록하는 계측기는 더 까다롭고 덜 수행될 수 있다.나는 그것이 얼마나 큰 문제인지 잘 모르겠다.
다음 트랜잭션 로그를 명명된 돌연변이와 비교하십시오.
Action: FetchNewsStories
Mutation: SetFetchingNewsStories
Action: FetchNewsStories [continuation]
Mutation: DoneFetchingNewsStories([...])
명명된 돌연변이가 없는 트랜잭션 로그:
Action: FetchNewsStories
Mutation: state.isFetching = true;
Action: FetchNewsStories [continuation]
Mutation: state.isFetching = false;
Mutation: state.listOfStories = [...]
비동기 및 익명 돌연변이의 잠재적 추가적 복잡성을 그 예에서 추론할 수 있기를 바란다.
https://vuex.vuejs.org/en/mutations.html
이제 우리가 앱을 디버깅하고 데브툴의 돌연변이 로그를 보고 있다고 상상해 보십시오.기록된 모든 돌연변이에 대해 devtool은 상태의 "전" 및 "후" 스냅샷을 캡처해야 한다.그러나 위의 예시 돌연변이 내부에 있는 비동기 콜백은 그러한 것을 불가능하게 만든다: 콜백은 언제 실행될 것인지 아직 콜백은 호출되지 않으며, 콜백에서 수행된 상태 돌연변이는 근본적으로 추적할 수 없다!
나도 헷갈려서 간단한 데모를 했어.
구성 요소부에를 하다
<template>
<div id="app">
<h6>Logging with Action vs Mutation</h6>
<p>{{count}}</p>
<p>
<button @click="mutateCountWithAsyncDelay()">Mutate Count directly with delay</button>
</p>
<p>
<button @click="updateCountViaAsyncAction()">Update Count via action, but with delay</button>
</p>
<p>Note that when the mutation handles the asynchronous action, the "log" in console is broken.</p>
<p>When mutations are separated to only update data while the action handles the asynchronous business
logic, the log works the log works</p>
</div>
</template>
<script>
export default {
name: 'app',
methods: {
//WRONG
mutateCountWithAsyncDelay(){
this.$store.commit('mutateCountWithAsyncDelay');
},
//RIGHT
updateCountViaAsyncAction(){
this.$store.dispatch('updateCountAsync')
}
},
computed: {
count: function(){
return this.$store.state.count;
},
}
}
</script>
store.js.
import 'es6-promise/auto'
import Vuex from 'vuex'
import Vue from 'vue';
Vue.use(Vuex);
const myStore = new Vuex.Store({
state: {
count: 0,
},
mutations: {
//The WRONG way
mutateCountWithAsyncDelay (state) {
var log1;
var log2;
//Capture Before Value
log1 = state.count;
//Simulate delay from a fetch or something
setTimeout(() => {
state.count++
}, 1000);
//Capture After Value
log2 = state.count;
//Async in mutation screws up the log
console.log(`Starting Count: ${log1}`); //NRHG
console.log(`Ending Count: ${log2}`); //NRHG
},
//The RIGHT way
mutateCount (state) {
var log1;
var log2;
//Capture Before Value
log1 = state.count;
//Mutation does nothing but update data
state.count++;
//Capture After Value
log2 = state.count;
//Changes logged correctly
console.log(`Starting Count: ${log1}`); //NRHG
console.log(`Ending Count: ${log2}`); //NRHG
}
},
actions: {
//This action performs its async work then commits the RIGHT mutation
updateCountAsync(context){
setTimeout(() => {
context.commit('mutateCount');
}, 1000);
}
},
});
export default myStore;
이것을 연구한 후, 내가 내린 결론은 돌연변이는 오직 데이터를 변경하여 우려를 더 잘 분리하고 업데이트된 데이터 전후의 로깅을 개선하는 데 초점을 맞춘 관습이라는 것이다.반면에 행동은 더 높은 수준의 논리를 처리한 다음 적절히 돌연변이를 부르는 추상화 계층이다.
1.문서:
작용은 돌연변이와 유사하며, 차이점은 다음과 같다.
- 그 상태를 변이하는 대신, 행동은 변이를 저지른다.
- 작업은 임의의 비동기 작업을 포함할 수 있다.
액션은 비동기 연산을 포함할 수 있지만 돌연변이는 포함할 수 없다.
2.우리는 돌연변이를 일으키고, 상태를 직접 변화시킬 수 있다. 또한 우리는 다음과 같이 행동하면서 상태를 변화시킬 수 있다.
actions: {
increment (store) {
// do whatever ... then change the state
store.dispatch('MUTATION_NAME')
}
}
액션은 다른 것들을 다루도록 설계되어 있고, 우리는 그 안에서 많은 것들을 할 수 있다. 그리고 돌연변이를 거기에 파견함으로써 상태를 바꿀 수 있다.
돌연변이 없는 상태는 없으니까!합의된 경우 - 예측 가능한 방식으로 상태를 변화시키는 논리가 실행된다.돌연변이는 상태를 설정하거나 변경할 수 있는 유일한 방법이며(그래서 직접적인 변화는 없다!), 더 나아가서는 동기식이어야 한다.이 솔루션은 매우 중요한 기능을 구동한다: 돌연변이가 개발 도구에 로그인하고 있다.그리고 그것은 당신에게 대단한 가독성과 예측가능성을 제공한다!
한 가지 더, 행동.말했듯이, 행동은 돌연변이를 일으킨다.그래서 그들은 가게를 바꾸지 않고, 이것들이 동기화할 필요가 없다.하지만, 그들은 비동기식 로직의 추가 부분을 관리할 수 있답니다!
한 겹의 추가 층을 갖는 것은 불필요해 보일 수도 있다.actions그냥 이라고 부르면mutations, 예를 들어,
const actions = {
logout: ({ commit }) => {
commit("setToken", null);
}
};
const mutations = {
setToken: (state, token) => {
state.token = token;
}
};
그래서 만약 전화한다면actions전화를 하다logout돌연변이 자체를 부르는 게 어때?
행동의 전체 아이디어는 하나의 행동 안에서 여러 개의 돌연변이를 불러내거나 아약스 요청이나 당신이 상상할 수 있는 어떤 종류의 비동기식 논리를 만드는 것이다.
우리는 결국 여러 개의 네트워크 요청을 하고 결국 많은 다른 돌연변이를 부를 수 있다.
그래서 우리는 우리의 복잡성을Vuex.Store()우리측에서 가능한 한.actions그리고 이것은 우리의mutationsstate그리고getters깨끗하고 직설적이며, Vue와 Reaction 같은 도서관을 인기 있게 만드는 모듈화의 종류에 부합한다.
참조URL: https://stackoverflow.com/questions/39299042/vuex-action-vs-mutations
'IT이야기' 카테고리의 다른 글
| Vue 조건부 v-on 이벤트 차단 한정자 (0) | 2022.05.12 |
|---|---|
| Vuex 모듈의 형식 오류 "표현으로 호출될 때 클래스 장식가의 서명을 확인할 수 없음" (0) | 2022.05.12 |
| 현재 구성 요소와 동일한 수준이 아닌 다른 구성 요소에서 $ref 액세스 (0) | 2022.05.12 |
| Global Guard 내부 모의 상점 게이터가 작동하지 않음 (0) | 2022.05.12 |
| C 프로그래밍:유니코드를 프로그래밍하는 방법? (0) | 2022.05.11 |