JavaScript에서 불변성이 중요한(또는 필요한) 이유는 무엇입니까?
저는 현재 React JS와 React Native 프레임워크에 대해 연구하고 있습니다.도중에 Facebook의 Flux와 Redux의 실장에 대해 읽고 있을 때, 불변성 또는 불변 JS 라이브러리를 발견했습니다.
문제는 불변성이 왜 그렇게 중요하냐는 것입니다.개체를 변환하는 데 어떤 문제가 있습니까?그렇게 하면 일이 간단해지지 않나요?
예를 들어, 간단한 뉴스 리더 앱을 생각해 봅시다.첫 화면은 뉴스 헤드라인 목록 보기입니다.
처음에 값을 가진 객체 배열로 설정하면 조작할 수 없습니다.불변의 원칙이 그렇게 말하죠? (내가 틀렸다면 정정해 주세요.)그러나 업데이트해야 하는 새 뉴스 개체가 있으면 어떻게 합니까?평소에는 개체를 배열에 추가할 수도 있습니다.이 경우 어떻게 하면 좋을까요?저장소를 삭제하고 다시 생성하시겠습니까?어레이에 개체를 추가하는 것이 비용이 적게 들지 않습니까?
저는 최근에 같은 주제에 대해 연구하고 있습니다.당신의 질문에 답하고 지금까지 배운 것을 공유하도록 노력하겠습니다.
문제는 불변성이 왜 그렇게 중요하냐는 것입니다.개체를 변환하는 데 어떤 문제가 있습니까?그렇게 하면 일이 간단해지지 않나요?
기본적으로 불변성은 예측 가능성과 성능을 (간접적으로) 향상시키고 돌연변이 추적을 가능하게 한다는 사실로 귀결됩니다.
예측 가능성
돌연변이는 변화를 숨깁니다.변화는 (예상치 못한) 부작용을 일으키고, 그로 인해 심각한 버그가 발생할 수 있습니다.불변성을 적용하면 애플리케이션 아키텍처와 mental model을 단순하게 유지할 수 있기 때문에 애플리케이션을 쉽게 이해할 수 있습니다.
성능
불변의 객체에 값을 추가하는 것은 기존 값을 복사해야 하는 곳에 새 인스턴스를 생성하여 메모리를 소비하는 새 객체에 새 값을 추가해야 함을 의미하지만, 불변의 객체는 구조 공유를 사용하여 메모리 오버헤드를 줄일 수 있습니다.
모든 업데이트는 새로운 값을 반환하지만 내부적으로 구조를 공유하여 메모리 사용량(및 GC 스레싱)을 대폭 줄입니다.즉, 1000개의 요소가 있는 벡터에 추가할 경우 실제로는 길이가 긴 새로운 벡터 1001-요소가 생성되지 않습니다.대부분의 경우 내부적으로 소수의 작은 개체만 할당됩니다.
자세한 내용은 여기를 참조하십시오.
변환 추적
메모리 사용량을 줄일 뿐만 아니라, 불변성을 통해 참조 및 가치 균등을 활용하여 애플리케이션을 최적화할 수 있습니다.이렇게 하면 변경된 것이 있는지 쉽게 확인할 수 있습니다.예를 들어 반응 성분의 상태 변화를 들 수 있습니다.하시면 됩니다.shouldComponentUpdatestate Objects를 비교하여 상태가 동일한지 확인하고 불필요한 렌더링을 방지합니다.자세한 내용은 여기를 참조하십시오.
기타 자원:
처음에 값을 가진 객체 배열로 설정했을 경우.나는 그것을 조작할 수 없다.불변의 법칙이 말하는 거 맞죠?(내가 틀렸다면 정정해 주세요)그러나 업데이트해야 하는 새 뉴스 개체가 있으면 어떻게 합니까?평소에는 개체를 배열에 추가할 수도 있습니다.이 경우 어떻게 하면 좋을까요?스토어를 삭제하고 다시 작성하시겠습니까?어레이에 개체를 추가하는 것이 비용이 적게 들지 않습니까?
네, 맞습니다.응용 프로그램에서 이 기능을 구현하는 방법이 혼란스럽다면 핵심 개념을 이해하기 위해 redux가 이 기능을 수행하는 방법을 살펴보는 것이 좋습니다.
나는 Redux가 불변성을 수용하기 때문에 그것을 예로 들기를 좋아한다.은 하나의 트리 1불변의 상태 트리)를 있습니다.store모든 상태 변경은 리듀서에 의해 처리되는 액션을 디스패치함으로써 명시적입니다.리듀서는 이전 상태를 받아들여서(한 번에 1개씩) 어플리케이션의 다음 상태를 반환합니다.주요 원리에 대한 자세한 내용은 여기를 참조하십시오.
redux의 저자 Dan Abramov는 다음과 같은 원칙을 설명하는 훌륭한 redux 코스가 있습니다(시나리오에 맞게 코드를 약간 수정했습니다).
import React from 'react';
import ReactDOM from 'react-dom';
// Reducer.
const news = (state=[], action) => {
switch(action.type) {
case 'ADD_NEWS_ITEM': {
return [ ...state, action.newsItem ];
}
default: {
return state;
}
}
};
// Store.
const createStore = (reducer) => {
let state;
let listeners = [];
const subscribe = (listener) => {
listeners.push(listener);
return () => {
listeners = listeners.filter(cb => cb !== listener);
};
};
const getState = () => state;
const dispatch = (action) => {
state = reducer(state, action);
listeners.forEach( cb => cb() );
};
dispatch({});
return { subscribe, getState, dispatch };
};
// Initialize store with reducer.
const store = createStore(news);
// Component.
const News = React.createClass({
onAddNewsItem() {
const { newsTitle } = this.refs;
store.dispatch({
type: 'ADD_NEWS_ITEM',
newsItem: { title: newsTitle.value }
});
},
render() {
const { news } = this.props;
return (
<div>
<input ref="newsTitle" />
<button onClick={ this.onAddNewsItem }>add</button>
<ul>
{ news.map( ({ title }) => <li>{ title }</li>) }
</ul>
</div>
);
}
});
// Handler that will execute when the store dispatches.
const render = () => {
ReactDOM.render(
<News news={ store.getState() } />,
document.getElementById('news')
);
};
// Entry point.
store.subscribe(render);
render();
또, 이러한 비디오에서는, 다음의 목적을 위해서 불변성을 실현하는 방법에 대해서도 자세하게 설명합니다.
불변성에 대한 상반된 견해
TL/DR: JavaScript에서는 불변성이 필요 이상으로 유행하고 있습니다.React를 사용하는 경우 상태 관리의 몇 가지 복잡한 설계 선택에 대한 간단한 해결 방법이 제공됩니다.그러나 그 외의 대부분의 상황에서는 복잡함을 넘어 충분한 가치를 창출할 수 없기 때문에 실제 고객의 요구를 충족시키기보다는 이력서를 보완하는 데 도움이 됩니다.
긴 답변: 아래를 읽으십시오.
Javascript에서 불변성이 중요한(또는 필요한) 이유는 무엇입니까?
물어봐줘서 고마워!
얼마 전 Dan Abramov라는 매우 재능 있는 사람이 순수한 함수와 불변성을 사용하는 Redux라는 Javascript 상태 관리 라이브러리를 만들었습니다.그는 아이디어를 정말 쉽게 이해할 수 있게 해주는 정말 멋진 비디오도 몇 개 만들었습니다.
타이밍은 완벽했다.Angular의 참신함은 사라지고 JavaScript 세계는 적절한 수준의 쿨함을 갖춘 최신 것을 고집할 준비가 되어 있었습니다.이 라이브러리는 혁신적일 뿐만 아니라 다른 실리콘 밸리의 강자가 판매하던 React와 완벽하게 연계되어 있었습니다.
슬프지만 자바스크립트 세계에서는 패션이 지배하고 있다.이제 아브라모프는 반신반의자로 환영받고 있고, 우리 모두는 불변의 도에 복종해야 한다.더 습할수록 말이 되든 안 되든.
개체를 변환하는 데 어떤 문제가 있습니까?
아무것도 아니예요!
사실 프로그래머들이 오브젝트를 변이시킨 건 어...변이시킬 물체가 있는 한 말입니다즉, 50년 이상에 걸친 애플리케이션 개발.
리고 왜왜 ?잡 잡?? ??? 「」가 .cat죽는다, 두 요?cat적할할 수??? '그냥'이라고 말할 이다.cat.isDead = true장낼수수수수
(물건을 바꾸는 것은) 일을 단순하게 하지 않습니까?
네! ..당연하죠!
특히 JavaScript에서는 실제로 다른 곳(데이터베이스 등)에서 유지되는 일부 상태의 보기를 렌더링하는 데 가장 유용합니다.
갱신해야 할 새로운 뉴스 오브젝트가 있으면 어떻게 해야 하나요?이 경우 어떻게 하면 좋을까요?스토어를 삭제하고 다시 작성하시겠습니까?어레이에 개체를 추가하는 것이 비용이 적게 들지 않습니까?
그럼 하면 요.News오브젝트, 즉 그 오브젝트의 메모리 내 표현은 변경됩니다(및 사용자에게 표시되는 뷰 등).
아니면...
FP해, FP/Immutability 에 변경을 할 수 .News모든 이력 변경을 추적하는 어레이에 대한 오브젝트입니다.그러면 어레이를 반복하여 올바른 상태 표현을 찾을 수 있습니다(휴!).
난 여기 뭐가 있는지 배우려고 노력 중이야.가르쳐 주세요:)
유행은 돌고 돈다, 친구.고양이 가죽을 벗기는 방법은 여러 가지가 있다.
계속 변화하는 프로그래밍 패러다임의 혼란을 감수해야 하는 점 죄송합니다.하지만 클럽에 온 걸 환영해!!
불변성과 관련하여 기억해야 할 몇 가지 중요한 점들이 있습니다. 그리고 여러분은 순진함만이 모을 수 있는 열정적인 강도로 이것들을 여러분에게 던지게 될 것입니다.
1) 불변성은 멀티 스레드 환경에서 레이스 조건을 회피하는 데 매우 적합합니다.
멀티 스레드 환경(C++, Java, C# 등)에서는 여러 스레드가 오브젝트를 변경할 때 오브젝트를 잠그는 문제가 있습니다.이는 성능에는 나쁘지만 데이터 손상보다는 좋습니다.그러나 모든 것을 불변하게 만드는 것만큼 좋지는 않다.
하지만 슬프다!JavaScript에서는 항상 단일 스레드로 작동합니다.웹 워커(각각 다른 컨텍스트 내에서 실행)도 가능합니다.따라서 실행 컨텍스트 내에 스레드 관련 레이스 조건을 둘 수 없기 때문에(모든 사랑스러운 글로벌 변수와 클로즈), 불변성을 지지하는 요점은 사라집니다.
(단, 웹워커에서는 순수 기능을 사용하는 것이 장점입니다만, 메인 스레드의 오브젝트를 만지는 것에 대한 기대는 없습니다.)
2) 불변으로 인해 앱 상태에서의 레이스 조건을 피할 수 있습니다.
그리고 이것이 문제의 핵심입니다. 대부분의 (React) 개발자들은 불변성과 FP가 어떤 식으로든 애플리케이션의 상태를 예측할 수 있는 이 마법에 효과가 있다고 말합니다.
물론 데이터베이스 내의 경쟁조건을 회피할 수 있다는 것은 아닙니다.이러한 조건을 해제하려면 모든 브라우저에서 모든 사용자를 조정해야 합니다.또한 앱을 실행하고 있는 모든 사용자에게 변경을 브로드캐스트하는 WebSockets 등의 백엔드 푸시 기술이 필요합니다(자세한 내용은 이하 참조).
또한 이는 애플리케이션 상태를 예측하기 위해 불변성이 필요한 JavaScript에 내재된 문제가 있다는 것을 의미하지 않으며, React 이전에 프런트 엔드 애플리케이션을 코딩해 온 개발자는 이를 알 수 있습니다.
이 다소 혼란스러운 주장은 단순히 React를 사용하면 애플리케이션이 경쟁 조건에 빠지기 쉽지만, 불변성을 통해 이러한 문제를 해결할 수 있다는 것을 의미합니다. 왜일까요?리액트는 특별하기 때문에..상태 관리가 목적에 맞게 하위화된 고도로 최적화된 렌더링 라이브러리로 먼저 설계되었으며, 따라서 컴포넌트 상태는 렌더링을 최적화하지만 사용자가 제어할 수 없으며 상태를 직접 변환하지 않는 것에 의존하는 비동기식 이벤트 체인(일명 "단방향 데이터 바인딩")을 통해 관리됩니다.
이러한 맥락에서 불변의 필요성이 JavaScript와 큰 관계가 없음을 알 수 있습니다.또한 새로운 어플리케이션에서 상호의존적인 변경이 많아 현재 상태를 파악할 수 있는 쉬운 방법이 없는 경우, 사용자는 혼란스러워지기 때문에 불변의 t를 사용하는 것이 이상적입니다.o 모든 이력 변경을 추적합니다.
3) 레이스 상황이 최악입니다.
React를 사용하는 경우 그럴 수 있습니다.하지만 다른 틀을 택하면 드물어요.
게다가, 당신은 보통 훨씬 더 큰 문제를 해결해야 합니다… 의존 지옥 같은 문제들.비대해진 암호 기반처럼요CSS가 로딩되지 않는 것처럼요빌드 프로세스가 느리거나 반복을 거의 불가능하게 만드는 단일 백엔드에 얽매이는 경우 등.미숙한 개발자들처럼 무슨 일이 일어나고 있는지 이해하지 못하고 일을 엉망으로 만들죠
아시잖아요.현실.하지만 그게 무슨 상관이야?
4) 불변성은 참조 유형을 사용하여 모든 상태 변화를 추적하는 성능 영향을 줄입니다.
상태가 바뀔 때마다 복사를 하려면 똑똑하게 대처해야 합니다.
5) 불변성을 통해 작업을 원래대로 되돌릴 수 있습니다.
왜냐하면 어..이것이 프로젝트 매니저가 요구하는 가장 중요한 기능이죠?
6) Web Sockets와 조합하여 많은 냉각 잠재력이 있는 불변의 상태
마지막으로 주의 델타 누적은 WebSockets와 조합하여 매우 설득력 있는 사례를 제시합니다.이것에 의해, 상태를 불변의 이벤트의 흐름으로서 간단하게 소비할 수 있습니다.
일단 한 푼이라도 이 개념에 떨어지면(최근의 관점을 나타내는 조잡한 기록들이 아니라 사건의 흐름인 상태), 불변의 세계는 거주하기에 마법의 장소가 된다.시간 자체를 초월한 이벤트 소스의 경이로움과 가능성의 땅.그리고 이렇게 하면 실시간 앱의 실행이 확실히 쉬워집니다.관심 있는 모든 사람에게 이벤트의 흐름을 브로드캐스트하기만 하면, 고객은 현재에 대한 자신의 표현을 작성하고, 자신의 변경 사항을 커뮤니티 플로우에 다시 쓸 수 있습니다.
하지만 어느 순간 당신은 깨어나서 그 모든 경이로움과 마법이 공짜로 오는 것이 아니라는 것을 깨닫는다.열성적인 동료와는 달리, 당신의 이해관계자(예, 당신에게 돈을 지불하는 사람들)는 철학이나 패션에 거의 관심이 없으며, 그들이 판매할 수 있는 제품을 만들기 위해 지불하는 돈에 대해 많은 관심을 가지고 있습니다.결론은 불변성을 코드화하는 것은 어렵고, 그것을 깨는 것은 용이하다는 것입니다.또, 그것을 서포트하는 백엔드가 없다면, 프런트 엔드의 불변은 거의 의미가 없습니다.WebSockets와 같은 푸시 테크놀로지를 통해 이벤트를 퍼블리싱하고 소비해야 한다는 것을 이해 관계자에게 납득시켰을 때(그리고 만약!) 프로덕션 확장이 얼마나 어려운지를 알게 됩니다.
자, 몇 가지 조언을 드리자면, 그것을 받아들이기로 선택하셨다면요.
FP/Immutability를 사용하여 JavaScript를 작성하는 것도 애플리케이션 코드 베이스를 보다 크고 복잡하며 관리하기 어렵게 만드는 방법입니다.이 접근방식을 Redux 리덕터로 한정하는 것을 강력히 주장하고 싶습니다만, 무엇을 하고 있는지 모르는 한…또한 불변성을 사용할 경우 클라이언트 측뿐만 아니라 전체 애플리케이션 스택에 불변 상태를 적용하십시오. 그렇지 않으면 진정한 가치를 놓치게 됩니다.
자, 만약 당신이 운 좋게 당신의 일을 선택할 수 있다면, 당신의 지혜를 사용하려고 노력하거나 하지 말고, 당신에게 돈을 주는 사람에게 옳은 일을 하세요.이는 자신의 경험, 직감 또는 주변에서 일어나는 일에 기초할 수 있습니다(모든 사람이 React/Redux를 사용하고 있다면 작업을 계속하기 위한 자원을 찾는 것이 더 쉽다는 타당한 주장이 있습니다).또는 개발 재개 또는 과장된 개발 방식을 시도할 수 있습니다.당신 취향일 수도 있어요
간단히 말해서, 불변성은 적어도 다음 열풍이 불기 전까지는 당신을 동료들과 함께 패셔너블하게 만들어 줄 것이고, 그 때쯤이면 당신은 기꺼이 앞으로 나아갈 것이다.
이 자기 평가 세션이 끝난 후, 이것을 제 블로그 => JavaScript의 불변성: Contrarian View에 기사로 추가했습니다.만약 당신이 강한 감정을 가지고 있다면, 당신도 속마음을 털어놓고 싶다면, 자유롭게 대답하세요;)
문제는 불변성이 왜 그렇게 중요하냐는 것입니다.개체를 변환하는 데 어떤 문제가 있습니까?그렇게 하면 일이 간단해지지 않나요?
사실, 그 반대는 사실입니다. 적어도 장기적으로 보면, 불변은 상황을 더 복잡하게 만듭니다.네, 원하는 장소에서 변경만 할 수 있기 때문에 초기 코딩이 쉬워집니다.그러나 프로그램이 커지면 문제가 됩니다.값이 바뀌면 무엇이 바뀌었을까요?
모든 것을 불변의 상태로 만든다는 것은 데이터가 더 이상 예기치 않게 변경될 수 없다는 것을 의미합니다.함수에 값을 전달하면 해당 함수에서 값을 변경할 수 없다는 것을 확실히 알고 있습니다.
간단히 말하면, 불변의 값을 사용하면 코드에 대한 추론이 매우 쉬워집니다.모든 사람이 고유*의 데이터 복사본을 얻을 수 있기 때문에 데이터를 낭비하거나 코드의 다른 부분을 파괴할 수 없습니다.이렇게 하면 멀티 스레드 환경에서 작업이 얼마나 쉬워질지 상상해 보십시오.
주의 1: 동작에 따라서는 불변성에 퍼포먼스 비용이 발생할 수 있지만 Unfound.js 등의 기능은 최대한 최적화되어 있습니다.
2: 및 주:2 : Unmutable.js 6 ES6const전혀 다른 의미를 지닙니다.
평소에는 개체를 배열에 추가할 수도 있습니다.이 경우 어떻게 하면 좋을까요?스토어를 삭제하고 다시 작성하시겠습니까?어레이에 개체를 추가하는 것이 비용이 적게 들지 않습니까?PS: 예를 들어 불변성을 설명하는 올바른 방법이 아닌 경우, 어떤 것이 적절한 실제적인 예인지 알려주세요.
네, 뉴스 예시는 완벽하고 당신의 추론은 정확합니다.기존 리스트를 수정할 수 없기 때문에 새로운 리스트를 작성해야 합니다.
var originalItems = Immutable.List.of(1, 2, 3);
var newItems = originalItems.push(4, 5, 6);
다른 답변은 괜찮지만 실용적인 사용 사례에 대한 질문을 해결하기 위해 (다른 답변의 코멘트로부터) 잠시 실행 중인 코드를 벗어나 바로 코앞에 있는 유비쿼터스 답변을 살펴보십시오: git.커밋을 푸시할 때마다 저장소의 데이터를 오버랩하면 어떻게 됩니까?
이제 우리는 불변의 컬렉션이 직면하는 문제 중 하나를 알게 되었습니다. 바로 기억의 팽창입니다.Git은 변경할 때마다 단순히 파일의 새로운 복사본을 만드는 것이 아니라 단순히 차이를 추적하는 것만으로 충분합니다.
git의 내부 동작에 대해서는 잘 모르지만, 당신이 참조하는 라이브러리와 같은 스트래티지를 사용하고 있다고 밖에 생각할 수 없습니다.구조 공유입니다.후드에서 라이브러리는 시도 또는 다른 트리를 사용하여 서로 다른 노드만 추적합니다.
이 전략은 인메모리 데이터 구조에도 상당히 적합합니다.이는 로그 시간에 동작하는 잘 알려진 트리 연산 알고리즘이 있기 때문입니다.
또 다른 사용 사례: 웹 앱에서 실행 취소 버튼을 원한다고 가정해 보십시오.데이터를 불변하게 표현하기 때문에 이러한 구현은 비교적 간단합니다.하지만 만약 돌연변이에 의존한다면, 그것은 세계의 상태를 캐싱하고 원자적인 업데이트를 하는 것에 대해 걱정해야 한다는 것을 의미합니다.
즉, 런타임 성능과 학습 곡선의 불변성에 대한 대가가 있습니다.그러나 경험이 풍부한 프로그래머라면 디버깅 시간이 코드 작성 시간보다 몇 배나 더 중요하다고 말할 것입니다.또한 런타임 성능에 미치는 영향은 사용자가 감내할 필요가 없는 상태 관련 버그보다 더 클 수 있습니다.
문제는 불변성이 왜 그렇게 중요하냐는 것입니다.개체를 변환하는 데 어떤 문제가 있습니까?그렇게 하면 일이 간단해지지 않나요?
가변성에 대해서
기술적 관점에서 보면 가변성에 문제가 있는 것은 없다.빠르고 메모리를 재사용하고 있습니다.개발자들은 처음부터 익숙하다.이러한 사용으로 인해 발생할 수 있는 문제와 가변성을 사용하는 데 문제가 있습니다.
객체가 어떤 것과도 공유되지 않는 경우(예를 들어 함수의 범위 내에 존재하며 외부에 노출되지 않는 경우)에는 불변의 이점을 찾기 어렵다.정말로 이 경우에 불변의 존재는 의미가 없다.불변의 느낌은 어떤 것이 공유될 때 시작된다.
변이성 두통
가변 공유 구조는 많은 함정을 쉽게 만들 수 있습니다.참조에 액세스할 수 있는 코드의 모든 부분이 변경되면 이 참조를 볼 수 있는 다른 부분에 영향을 미칩니다.이러한 충격에 의해 다른 모듈을 인식하지 않아도 모든 부품이 서로 연결됩니다.한 함수의 돌연변이는 앱의 전혀 다른 부분을 손상시킬 수 있습니다.그런 것은 나쁜 부작용이다.
다음으로 많은 경우 변환의 문제는 파손된 상태입니다.변환 프로시저가 중간에 실패하여 일부 필드가 변경되거나 변경되지 않은 경우 파손 상태가 발생할 수 있습니다.
게다가 돌연변이는 변화를 추적하기 어렵다.단순 참조 검사에서는 어떤 변경 사항이 있는지 알기 위해 어떤 차이가 나타나지 않습니다.또한 변화를 모니터링하기 위해 몇 가지 관찰 가능한 패턴을 도입해야 합니다.
마지막으로, 돌연변이는 신뢰 부족의 원인입니다.변환이 가능한 경우, 어떤 구조가 원하는 값을 가지고 있는지 확인하는 방법.
const car = { brand: 'Ferrari' };
doSomething(car);
console.log(car); // { brand: 'Fiat' }
위의 예에서 보듯이, 변환 가능한 구조를 통과하는 것은 항상 다른 구조를 갖는 것으로 끝날 수 있습니다.함수 doSomething이 외부에서 지정된 속성을 변환하고 있습니다.코드에 대한 신뢰는 없습니다. 무엇을 가지고 있고 무엇을 갖게 될지 정말 모릅니다.이러한 모든 문제가 발생하는 이유는 다음과 같습니다.가변 구조는 메모리에 대한 포인터를 나타냅니다.
불변은 가치관이다.
불변성은 변경이 동일한 오브젝트, 구조에서 이루어지는 것이 아니라 변화가 새로운 오브젝트, 구조에서 나타나는 것을 의미합니다.이는 참조가 메모리 포인터뿐만 아니라 값도 나타내기 때문입니다.모든 변경은 새로운 가치를 창출하고 오래된 가치는 건드리지 않습니다.이러한 명확한 규칙은 신뢰와 코드 예측 가능성을 제공합니다.함수는 변환 대신 자체 값으로 자체 버전을 처리하기 때문에 사용하기에 안전합니다.
메모리 컨테이너 대신 값을 사용하면 모든 개체가 특정 불변 값을 나타내며 이 값을 사용해도 안전하다는 확신을 얻을 수 있습니다.
불변의 구조는 가치를 나타낸다.
중간 기사 https://medium.com/@macsikora/the-state-of-intermitability-the-state-of-intermitibility-d2cd1010에서 이 주제에 대해 더 깊이 파고들고 있습니다.
JavaScript에서 불변성이 중요한(또는 필요한) 이유는 무엇입니까?
불변성은 다양한 컨텍스트에서 추적할 수 있지만 가장 중요한 것은 애플리케이션 상태와 애플리케이션 UI에 대해 추적하는 것입니다.
JavaScript Redux 패턴은 매우 트렌디하고 현대적인 접근 방식이라고 생각하겠습니다.
UI를 예측 가능하게 만들어야 합니다.만약 그렇다면 그것은 예상할 수 있을 것이다.UI = f(application state).
응용 프로그램(JavaScript)은 reducer 함수를 사용하여 구현된 작업을 통해 상태를 변경합니다.
reducer 함수는 단순히 액션과 이전 상태를 수행하고 새 상태를 반환하며 이전 상태를 그대로 유지합니다.
new state = r(current state, action)
은 모든 시킬 수 , 앱은 수 UI = f(state)
쉽게 실행 취소/재실행할 수 있습니다.
이 모든 상태를 만드는 것은 여전히 메모리 효율이 높고 Git과 유사하며 Linux OS에서도 심볼릭 링크(inode에 기반함)와 유사합니다.
Javascript의 불변성의 또 다른 장점은 일반적으로 설계에 상당한 이점이 있는 일시적 결합을 감소시킨다는 것입니다.오브젝트의 인터페이스를 다음 두 가지 방법으로 검토합니다.
class Foo {
baz() {
// ....
}
bar() {
// ....
}
}
const f = new Foo();
.baz()한 것입니다.bar()올바르게 동작합니다.데데이 걸걸? ???
f.baz();
f.bar(); // this is ok
f.bar();
f.baz(); // this blows up
퍼블릭 인터페이스를 조사해도 바로 알 수 없기 때문에 그것을 알기 위해서는 클래스 내부를 면밀히 조사할 필요가 있습니다.이 문제는 많은 가변 상태 및 클래스가 있는 대규모 코드베이스에서 폭발적으로 증가할 수 있습니다.
ifFoo을 사용법 해서 '아주 좋다'라고 될 것 같아요.baz ★★★★★★★★★★★★★★★★★」bar클래스 내부 상태는 변경할 수 없기 때문에 어떤 순서로든 상관없습니다.
옛날에 스레드 간의 데이터 동기화에 문제가 있었습니다.이 문제는 10개 이상의 솔루션이 있을 정도로 큰 문제가 되었습니다.어떤 사람들은 그것을 근본적으로 해결하려고 했다.그곳은 기능적 프로그래밍이 탄생한 곳이었다.그것은 마치 마르크스주의 같다.Dan Abramov가 어떻게 JS에 이 아이디어를 팔았는지 이해할 수 없었습니다.왜냐하면 싱글 스레드이기 때문입니다.그는 천재다.
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★에는 아트리뷰트가 .__attribute__((pure))gcc로 지정합니다.컴파일러는 특별히 학습하지 않으면 함수가 순수한지 아닌지를 해결하려고 합니다.상태가 변해도 기능은 순수할 수 있습니다.불변성은 순수함을 보증하는 100가지 이상의 방법 중 하나에 불과합니다.95%를 차지하다
실제로 심각한 이유가 없다면 어떤 제한(예: 불변)도 사용하지 않는 것이 좋습니다.일부 상태를 "실행 취소"하려는 경우 트랜잭션을 작성할 수 있습니다.통신을 간소화하고 싶은 경우는, 불변의 데이터로 이벤트를 송신할 수 있습니다.너한테 달렸어.
나는 이 메시지를 포스트 마르크스주의 공화국에서 쓰고 있다.나는 어떤 아이디어의 급진화는 잘못된 방법이라고 확신한다.
다른 견해...
제 다른 대답은 매우 실용적인 관점에서 그 질문을 다루고 있고, 저는 여전히 그것이 좋습니다.저는 이것을 부록이 아닌 다른 답변으로 추가하기로 했습니다. 왜냐하면 그것은 지루한 철학적 외침이기 때문입니다. 그것은 희망적으로도 질문에 답하지만, 저의 기존 답변과는 잘 맞지 않기 때문입니다.
TL;DR
작은 프로젝트에서도 불변성은 유용하지만, 불변성이 존재한다고 해서 당신을 위한 것이라고 생각하지 마세요.
훨씬, 훨씬 더 긴 대답
참고: 이 답변의 목적상, 저는 '규율'이라는 단어를 어떤 이익을 위해 자기 거부를 의미합니다.
이것은, 「타입 스크립트를 사용할 필요가 있는가」라고 하는 또 다른 질문과 같은 형식입니다.JavaScript에서 유형이 중요한 이유는 무엇입니까?"이것도 비슷한 대답이에요.다음 시나리오를 고려합니다.
귀하는 약 5000줄의 JavaScript/CSS/HTML 코드베이스의 유일한 작성자 및 유지관리자입니다.귀사의 준기술적 상사는 Typescript-as-the-new-hotness에 대한 내용을 읽고 델이 이행을 원할 수도 있지만 결정은 당신에게 맡기라고 제안합니다.그래서 읽거나 가지고 놀거나...
이제 선택할 수 있습니다. Typescript로 이동하시겠습니까?
타이프스크립트에는 인텔리센스, 오류 조기 발견, API 선행 지정, 리팩토링 시 수정 용이성, 테스트 횟수 감소 등 몇 가지 장점이 있습니다.타이프스크립트에는 비용도 있습니다.특정 자연스럽고 올바른 JavaScript 관용구는 특별히 강력하지 않은 타입 시스템으로 모델화하기가 까다로울 수 있습니다.주석은 LoC를 증가시킵니다.기존 코드 베이스를 재작성하기 위한 시간과 노력, 빌드 파이프라인의 추가 절차 등이 있습니다.보다 근본적으로, 코드가 정확할 가능성이 높다는 약속과 교환하여 올바른 JavaScript 프로그램의 서브셋을 추출합니다.그것은 임의로 제한된다.그것이 요점이다: 당신은 당신을 제한하는 어떤 규율을 부과한다(자신의 발을 쏘지 않기를 바란다.
위의 문맥에서 다시 한 번 질문해 봅시다.그것이 가치가 있는가?
전술한 시나리오에서는 중소규모 JS 코드베이스에 매우 익숙하다면 Typescript를 사용하는 선택이 실용적이라기보다는 심미적이라 생각합니다.괜찮아요. 미학에는 문제가 없어요.그냥 매력적이라고는 할 수 없어요.
시나리오 B:
당신은 직업을 바꾸고 지금은 Foo Corp.의 LOB 프로그래머입니다.90000 LoC(및 카운트)의 JavaScript/HTML/CSS 코드 베이스에서 10명의 팀과 함께 작업하고 있습니다.이 코드 베이스에는 babel, Web pack, 폴리필 스위트, 다양한 플러그인, 상태 관리 시스템, 20개의 서드파티 라이브러리, ~10개의 내부 라이브러리, gui-house 규칙을 가진 린터 같은 에디터 플러그인이 포함되어 있습니다.de 등
당신이 5K LOC 남자/여자였을 때, 그것은 그다지 중요하지 않았습니다.문서 작성도 그다지 큰 문제가 되지 않았습니다.또, 6개월 후에 코드의 특정 부분을 참조해도, 충분히 간단하게 파악할 수 있었습니다.하지만 이제 규율은 좋은 것뿐만 아니라 필요하다.이 분야에는 타입스크립트가 포함되지 않을 수 있지만, 어떤 형태의 정적 분석뿐만 아니라 다른 모든 형태의 코딩 분야(문서, 스타일 가이드, 빌드 스크립트, 회귀 테스트, CI)가 포함될 수 있습니다.규율은 더 이상 사치품이 아니라 필수품이다.
것이 다 되었습니다.GOTO은 1978년을 할 수 있다: C의 리틀 블랙잭 게임GOTOs와 스파게티 논리, 그리고 그것을 스스로 선택하는 것은 그다지 큰 문제가 되지 않았지만, 프로그램이 점점 커지고 야망이 커지면서, 규율 없는 사용이 가능해졌다.GOTO지속할 수 없었습니다.그리고 이 모든 것이 오늘날 불변에도 적용됩니다.
스태틱 타입과 마찬가지로 대규모 코드 베이스에 대해 엔지니어 팀이 유지보수/확장 작업을 하고 있지 않은 경우, 불변성을 사용하는 것은 실용적이라기보다는 심미적인 선택입니다.즉, 이점은 아직 존재하지만 비용을 넘지 않을 수 있습니다.
하지만 모든 유용한 분야와 마찬가지로, 더 이상 선택사항이 아닌 시점도 찾아옵니다.건강한 체중을 유지하고 싶다면, 아이스크림과 관련된 규율은 선택 사항일 수 있습니다.하지만 만약 내가 경쟁력 있는 선수가 되고 싶다면, 아이스크림을 먹을지 말지에 대한 나의 선택은 나의 목표 선택에 달려있다.소프트웨어를 사용하여 세상을 변화시키고 싶다면, 불변성은 자신의 무게로 인해 붕괴되는 것을 방지하기 위해 필요한 것의 일부일 수 있습니다.
예를 들어 다음과 같습니다.
const userMessage = {
user: "userId",
topic: "topicId"
content: {}
}
validateMessage(userMessage)
saveMessage(userMessage)
sendMessageViaEmail(userMessage)
**sendMessageViaMobilePush(userMessage)**
console.log(userMessage) // => ?
몇 가지 질문에 답해 주십시오.
- userMessage on line sendMessageViaMobilePush(userMessage) 아래에 있는 것은 무엇입니까?
{
id: "xxx-xxx-xxx-xxx", //set by ..(Answer for question 3)
user:"John Tribe", //set by sendMessageViaEmail
topic: "Email title", //set by sendMessageViaEmail
status: FINAL, //set by saveMessage or could be set by sendMessageViaEmail
from: "..", //set by sendMessageViaEmail
to:"...", //set by sendMessageViaEmail
valid:true, //set by validateMessage
state: SENT //set by sendMessageViaEmail
}
Surprised?? Me too :d. But this is normal with mutability in javascript.
(in Java too but a bit in different way. When You expect null but get some object). userMessage는 불변 코드의 같은 줄 아래에 무엇입니까?
const userMessage = { user: "userId", topic: "topicId", content: {} } Easy right ?스니펫 1의 가변 코드에서 어떤 방법으로 "id"가 업데이트되는지 추측할 수 있습니까?
By sendMessageViaEmail. Why? Why not? Well it was at first updated by saveMessage, but then overridden by sendMessageViaEmail.가변 코드에서 사람들은 푸시 메시지를 받지 못했습니다(sendMessageViaMobilePush).왜 그런지 아세요?
because I am amazing developer :D and I put safety check in method sendMessageViaMobilePush(userMessage) function sendMessageViaMobilePush(userMessage) { if (userMessage.state != SENT) { //was set to SENT by sendMessageViaEmail send(userMessage) } } Even if You saw this method before, was this possible for You to predict this behavior in mutable code ? For me it wasn't.
이것이 Javascript에서 가변 객체를 사용하는 주요 문제를 이해하는데 도움이 되었기를 바랍니다.
복잡성이 증가하면 특히 다른 사람과 작업할 때 설정된 내용과 위치를 확인하는 것이 너무 어렵습니다.
libs(redux, vuex 등)와 같은 모든 불변의 스토리지를 대체할 수 있는 가변(또는 불변) 상태의 프레임워크에 의존하지 않는 오픈 소스(MIT) lib를 만들었습니다.
해야 할 일이 너무 많고(단순한 읽기/쓰기 작업에 대한 작업이 많으며), 코드가 읽기 어렵고, 큰 데이터 세트의 성능이 허용되지 않았기 때문에(전체 구성 요소 재렌더:/) 불변의 상태는 내게는 매우 심각했습니다.
deep-state-observer를 사용하면 도트 표기로 업데이트 할 수 있는 노드는 1개뿐이며 와일드카드를 사용할 수 있습니다.또한 변경된 구체적인 가치만을 유지한 상태 이력(언도/레도/시간 여행)을 작성할 수 있습니다.{path:value}= ★★★★★★★★★★★★★★★★★★★★★★★★★
Deep-State-Observer를 사용하여 미세 조정이 가능하며 컴포넌트 동작을 세밀하게 제어할 수 있어 성능을 대폭 향상시킬 수 있습니다.코드 가독성이 향상되고 리팩터링이 훨씬 쉬워집니다.패스 문자열을 검색 및 치환하기만 하면 됩니다(코드/로직 변경 불필요).
불변의 주된 장점은 단순함이다.
기존 개체를 변경하는 것보다 개체를 교체하는 것이 더 쉽습니다.
한 곳에서 정확성에 초점을 맞출 수 있습니다.가능한 모든 장소보다 당신의 물건이 바뀔 수 있습니다.
오브젝트가 비활성 상태인 경우 장애는 생성 시 발생해야 하므로 수정이 용이합니다(불변하기 때문에).
불변의 사물이 존재하는 주된 이유는 사물의 상태를 유효하게 유지하기 위해서라고 생각합니다.
를 들어, '어울리다'라는 해 보겠습니다.arr이 오브젝트는 모든 항목이 같은 문자일 때 유효합니다.
// this function will change the letter in all the array
function fillWithZ(arr) {
for (var i = 0; i < arr.length; ++i) {
if (i === 4) // rare condition
return arr; // some error here
arr[i] = "Z";
}
return arr;
}
console.log(fillWithZ(["A","A","A"])) // ok, valid state
console.log(fillWithZ(["A","A","A","A","A","A"])) // bad, invalid state
arr불변의 객체가 되면 arr은 항상 유효한 상태에 있게 됩니다.
언급URL : https://stackoverflow.com/questions/34385243/why-is-immutability-so-important-or-needed-in-javascript
'programing' 카테고리의 다른 글
| MySQL: 필드 크기/길이순으로 정렬 (0) | 2023.01.30 |
|---|---|
| 정규식을 사용하여 문자열 내의 모든 YouTube 비디오 ID를 찾으려면 어떻게 해야 하나요? (0) | 2023.01.30 |
| busboy에 문제가 있어 Content-Type을 찾을 수 없다 (0) | 2023.01.30 |
| Intelij Spring Initializer를 사용할 수 없습니다. (0) | 2023.01.30 |
| ES6에 심볼을 도입하는 동기는 무엇입니까? (0) | 2023.01.30 |