React 문서가 componentWillMount가 아닌 componentDidMount에서 AJAX를 권장하는 이유는 무엇입니까?


102

제목에 모든 것이 나와 있습니다. componentDidMountDOM 액세스가 필요한 모든 것에 왜 적절한 지 이해 하지만 AJAX 요청이 반드시 필요한 것은 아닙니다.

무엇을 제공합니까?


@FurkanO 나는 그가 구성 요소에 의해 렌더링 된 DOM 요소에 대한 액세스를 의미한다고 생각합니다. 그리고 그는 전적으로 옳습니다. 왜냐하면 당신이 componentWillMount그 안에있는 요소들에 접근하려고 한다면 그 구성 요소가 ... 탑재되지 않았기 때문에 실패 할 것이기 때문입니다.
ZekeDroid

@AlanH. 내 질문을 삭제했습니다. 물론 componentDidMount에서 dom에 액세스 할 수 있습니다. 이것은 규칙이며 설명 할 것이 없습니다. 감사.
FurkanO

제 생각에는 componentDidMount 후에 Ajax 함수를 호출하는 이유는 요소가 처음에 부드럽게 렌더링되는지 먼저 확인해야하기 때문입니다. 그 후에 우리는 ajax 호출을 할 수 있습니다. 우리가 호출하면 아약스 제 뭔가 오류는 렌더링에 문제가 발생할 것 일
패리스 Rayhan을

답변:


62

componentDidMount부작용입니다. 이벤트 리스너, AJAX 추가, DOM 변경 등

componentWillMount거의 유용하지 않습니다. 특히 서버 측 렌더링에 관심이있는 경우 (이벤트 리스너를 추가하면 오류와 누수가 발생하고 다른 많은 문제가 발생할 수 있습니다).

componentWillMount생성자와 동일한 목적을 제공하기 때문에 클래스 구성 요소에서 제거하는 것에 대한 이야기가 있습니다 . createClass구성 요소에 남아 있습니다 .


1
이벤트 리스너를 추가 하면 서버에서 항상 오류와 누출이 발생 하거나 componentWillMount? 나는 정말로 구별을 보지 못합니다.
Alan H.

18
@Alan-클라이언트 측과 서버 측 모두에서 React를 사용하는 경우 내부의 모든 것이 서버 측 componentWillMount렌더링에서 실행 된다는 것을 알 수 있습니다. Wheras를 사용하는 경우 componentDidMount클라이언트 측에서만 실행됩니다. 결과적으로 componentWillMount외부 상호 작용을 수행하거나 이벤트 등에 바인딩하는 것을 넣는 것은 좋은 생각이 아닙니다. 서버 측에서 구성 요소를 렌더링 할 계획이없는 경우 잠재적 인 코드 이식성을 위해 여전히 좋은 생각이 아닙니다. 이것은 @daniula의 답변에 설명되어있는 주된 이유가 아닙니다.
Mike Driver

3
componentWillMount는 서버에서 실행되지만 componentWillUnmount (리스너를 제거하는 위치)는 실행되지 않습니다. 이로 인해 리스너를 추가하고 정리하지 않습니다.
Brigand 2014

React 핵심 팀의 사람들은 향후 버전에서 componentWillMount 제거를 고려하고 있습니다.
cchamberlain

1
@AnkitSinghaniya 서버 렌더링 및 얕은 단위 테스트를 중단합니다.
Brigand

36

나는 처음에도 같은 문제가 있었다. 의뢰를 해보기로 componentWillMount했지만 여러 가지 사소한 문제로 끝납니다.

ajax 호출이 새 데이터로 완료되면 렌더링을 트리거했습니다. 어떤 시점에서 컴포넌트 렌더링은 서버에서 응답을받는 것보다 더 많은 시간이 걸렸고이 시점에서 ajax 콜백은 마운트되지 않은 컴포넌트에서 렌더링을 트리거했습니다. 이것은 일종의 엣지 케이스이지만 아마도 더 많을 것이므로을 고수하는 것이 더 안전합니다 componentDidMount.


괜찮 감사. 그럴 수 있다고 생각했지만 당신 말이 맞습니다. 렌더링이 끝나기 전에 ajax 요청이 끝날 수 있다는 것이 놀랍습니다.
Alan H.

1
@daniula 확실합니까? AJAX 요청은 렌더링 전에 어떻게 완료 될 수 있습니까?
Leon Grapenthin 2015

4
이것은 브라우저 비동기 세계입니다. 한 기능이 항상 나머지 기능보다 빠르다고 가정해서는 안됩니다. 내가 언급했듯이 그것은 가장자리의 경우이며 아마도 렌더링 프로세스를 최적화해야 함을 의미하지만 적절한 수명주기 방법을 사용하면이 시점에서 삶이 훨씬 쉬워집니다.
daniula

1
@SooChengKoh ES6 클래스 생성자는와 동일 componentWillMount하므로 componentDidMount아약스 호출에 계속 사용해야 합니다.
daniula

1
@SooChengKoh-설정해야하는 상태로 이어지는 생성자에서 어떤 작업도하지 말아야합니다. 그러면 클라이언트와 서버에서 경합 상태가 발생합니다. setState구성 요소 생성자에서 호출해서는 안되며 AJAX 호출이 완료되는시기를 결정할 방법이 없습니다. twitter.com/dan_abramov/status/576453138598723585
cchamberlain

3

문서에 따르면 상태를 설정하면 componentWillMount다시 렌더링이 트리거되지 않습니다. AJAX 호출이 차단되지 않고 Promise성공시 구성 요소의 상태를 업데이트하는 을 반환하는 경우 구성 요소가 렌더링 된 후 응답이 도착할 가능성이 있습니다. 으로 componentWillMount트리거하지 않습니다 당신이 요청 된 데이터 렌더링 컴포넌트 존재 당신이 예상되는 동작을하지 않습니다 재 렌더링.

플럭스 라이브러리 중 하나를 사용하고 요청 된 데이터가 저장소에서 끝나는 경우 구성 요소가 연결되거나 연결된 구성 요소에서 상속되는 경우 해당 데이터의 수신이 대부분의 경우 props를 변경하므로 문제가되지 않습니다. 결국.


1
componentWillMount첫 번째 렌더링 전에 새 상태가 정의 되었기 때문에 다시 렌더링을 트리거하지 않습니다. 그러나 setStateAJAX 콜백에서 호출되면 첫 번째 렌더링 후에 가장 확실하게 호출되며 다시 렌더링을 트리거합니다.
webdif
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.