ReactNative 구성 요소 상태 설계 사고

디자인React 구성 요소와 원생 js 구성 요소를 디자인하는 가장 큰 차이점은 바로 상태의 디자인이다.

용어 정의

1. 속성

일반적으로 사용자가 구성 요소를 초기화할 때 구성 요소에 전달할 수 있는 것을 가리킨다

어떤 프레임워크도 옵션이라고 부른다

public입니다

RN 체계에서props라고 하는데 그 중에는 사건도 포함되어 있다

2. 이벤트

public입니다

function 타입입니다

RN 체계에서props를 사용하여 인용한다

3, 인터페이스

public입니다

function 타입입니다

구성 요소를 실례화한 후의 대상을 통해 호출할 수 있습니다

4. 내부 속성

프라이빗입니다

전통적인 설계 방안은 일반적으로 구성 요소의 상태, 데이터 등을 저장하는 데 쓰인다

RN 체계에서 이를 명확하게 하지 않아 자유롭게 설계할 수 있다

5. 상태

RN 체계에서 명확하게 제기된 개념

전통적인 디자인 방안에서 일반적으로 내부 속성을 사용하여 표시한다

전통적인 디자인 사고방식

원래 구성 요소를 설계하는 방법론에 따르면 하나의 UI 구성 요소는 대외적으로 속성, 이벤트, 인터페이스를 가지고 내부에 내부 속성, 내부 인터페이스를 가져야 한다.

속성은 구성 요소가 갖춰야 할 기능, 외관 또는 초기 상태를 설명하는 프로필과 같습니다

이벤트는 구성 요소가 작업 공정에서 어떤 조건을 만족시킬 때 촉발하는 리셋 함수입니다

인터페이스는 구성 요소 대상의 방법으로 구성 요소가 특정한 임무를 수행하도록 할 수 있다

원래의 디자인 이념에서 구성 요소 상태의 개념을 제기하지 않았지만 그 역시 줄곧 존재했고 일반적으로 구성 요소의 개인 속성을 사용하여 저장했다.
예를 들어 단추를 설계하면 정상적인 상태, 비활성화 상태가 있을 수 있습니다. 그러면 우리는 속성disable={true|false}를 설계하여 구성 요소가 초기화된 상태를 알립니다. 2개의 인터페이스disable,enable를 설계하여 js에게 동적으로 그 상태를 바꾸는 능력을 부여하고 2개의 이벤트onEnable,onDisable를 설계하여 리셋 함수 구성 요소의 상태가 변했음을 알립니다.위조 코드는 다음과 같습니다.// class button{ constructor(disable,pid){// this.disable=disable,// ： this.pid=pid;// ： id this._disable=null,// : if(this.disable==true){// this.disable(); }else{ this.enable(); } this.render();// } enable(){ this._disable=false; if(this.el)this.el.set('disable',false); this.fireEvent('onEnable');// } disable(){ this._disable=true; if(this.el)this.el.set('disable',true); this.fireEvent('onDisable');// } render(){ // ， $(this.pid).innerHTML=' '; // dom this.el=$(this.pid).getChild(); } } // // new button(false,'a');

RN 설계 사고방식

위의 예제에서는 기존 UI 구성 요소의 디자인 방향을 나타냅니다._disable은 바로 이 버튼 구성 요소의 관건적인 상태로 구성 요소의 표현과 행위에 직접적인 영향을 미친다.
반면react 구조는 구성 요소의 상태를 새로운 높이로 향상시켰다. 주로 다음과 같은 몇 가지가 있다.

구성 요소 상태와 상태의 기본값을 표시하기 위해 고정된 인터페이스를 사용합니다

고정된 인터페이스를 사용하여 구성 요소 상태의 값을 얻고 변경합니다

상태의 변화는 반드시 구성 요소의 표현을 바꾸고 구성 요소의 재렌더링을 초래할 것이다

앞의 두 항목은 모두 문제가 아니다. 왜냐하면 우리도 원래 이런 물건이 있어야 하기 때문이다. 단지 작법에 변화가 생겼을 뿐, 관건은 마지막 항목이다.여기서 말하는 것은 문제가 아니라 사고방식에서 비교적 쉽게 받아들일 수 있다는 것을 가리킨다.이런 고정 묘사법은 문제도 뚜렷하다. 왜냐하면 하나의 상태를 RN상태 체계에서 꺼내려면 일정한 작업 원가가 발생하기 때문에 매우 불쾌하다.
구성 요소 상태의 변화가 반드시view의 변화를 초래해야 합니까?
답은 틀림없이 no이다. 왜냐하면 일부 상태는 구성 요소의 행위에만 영향을 주고 표현에 영향을 주지 않기 때문이다.예를 들어 단추에 새로운 기능을 부여합니다. 폼의 데이터를 제출할 수 있습니다. 즉, 새로운 상태formName이 필요합니다. 그는 표현에 영향을 주지 않고 행위에만 영향을 줍니다.
성능의 극치를 감안하여 우리는 이런 상태를 RN의 상태 체계 외에 두고 대상의 사유 속성으로 존재할 수밖에 없다.
RN은 diff 알고리즘의 성능이 매우 높지만 0 손실도 아니다. 만약에 RN의 렌더링에 대한 이해가 투철하면 너도 당연히 이렇게 설계하지 않을 수 있다. 그러나 나는 보수적인 경향이 있다. 그렇지 않으면 후기의 조정도 작업량이 있다. 왜냐하면 정의, 초기화, 수치 추출, 수치 변경 등 조작 코드가 모두 다르기 때문이다.여기까지 썼는데 만약에 가능하다면 우리는 어떤 방법을 통해 어떤 상태가 표현에 영향을 미치는지 편리하게 수정할 수 있고 다른 코드를 바꾸지 않아도 된다면 우리가 상태를 설계할 때 구분하지 않아도 디자인 자체에 더욱 관심을 가지게 될 것이다.

결론

여기까지 말하면 기본적으로 생각을 정리할 수 있다.
구성 요소는 전통적인 방식에 따라 디자인하고 어떻게 디자인해야 하는지, 원래의 구성 요소 내부 속성을 디자인할 때 한 걸음 더 나아가 어떤 내부 속성의 변화가 표현에 영향을 주고 어떤 내부 속성이 표현에 영향을 주지 않는지 고려한다.영향 표현을 RN 상태 체계에 넣고 표현에 영향을 주지 않고 내부 속성에 넣는다.됐어.

tips

1. 결합성이 강한 부자 구성 요소는 상태를 부모 구성 요소에 통일하는 것을 권장합니다. 하위 구성 요소는 상태를 넣지 마십시오. 상태의 크로스 구성 요소가 공유되든view 렌더링에 대한 트리거가 편리합니다.어떤 상태를 하위 구성 요소 내부에서만 사용한다고 확신하지 않으면, 보통 이런 상황 뒤에도 변화가 발생할 수 있다.
2. 다음 질문은state인지 아닌지를 식별하는 데 도움을 줄 수 있습니다. 홈페이지에서 발췌

부급에서props를 통해 들어왔습니까?만약 그렇다면,state가 아닐 수도 있다..

시간에 따라 바뀔까요?아니라면state가 아닐 수도 있는데..

구성 요소의 다른state 데이터나props에 따라 계산할 수 있습니까?만약 그렇다면,state가 아니다..

속성의 변화는view의 변화에 영향을 줄 수 있다.state일 수 있다

3. 참조

https://facebook.github.io/react/docs/thinking-in-react.html

http://wiki.jikexueyuan.com/project/react/thinking-in-react.html

https://segmentfault.com/a/1190000004180955