React.js에서 componentWillMount 또는 componentDidMount에서 초기 네트워크 요청을 해야 합니까?

React.js에서 componentWillMount 또는 componentDidMount에서 초기 네트워크 요청을 해야 합니까?

에서는 react docs에서 를 할 합니다.componentDidMount★★★★

componentDidMount()컴포넌트가 마운트된 직후에 호출됩니다.DOM 노드가 필요한 초기화가 여기에 있어야 합니다.원격 엔드포인트에서 데이터를 로드해야 하는 경우 네트워크 요청을 인스턴스화할 수 있습니다.이 메서드로 상태를 설정하면 재렌더링이 트리거됩니다.

ifcomponentWillMount컴포넌트를 렌더링하기 전에 호출됩니다.요구를 하고 상태를 설정하는 것이 좋지 않을까요?에서 componentDidMount컴포넌트가 렌더링되고 요구가 이루어지며 상태가 변경된 후 컴포넌트가 다시 생성됩니다.왜 어떤 것이 제출되기 전에 요청을 하는 것이 더 낫지 않을까요?

은 '어디로 할까요?'에서 .componentDidMount.

컴포넌트를 렌더링하기 전에 componentWillMount가 호출되면 여기서 요청하여 상태를 설정하는 것이 더 낫지 않을까요?

아니요. 구성요소가 렌더링될 때까지 요청이 완료되지 않기 때문입니다.

componentDidMount에서 이렇게 하면 컴포넌트가 렌더링되고 요구가 이루어지며 상태가 변경되고 컴포넌트가 다시 렌더링됩니다.왜 어떤 것이 제출되기 전에 요청을 하는 것이 더 낫지 않을까요?

모든 네트워크 요구는 비동기이기 때문입니다.데이터를 캐시하지 않는 한 두 번째 렌더링을 피할 수 없습니다(이 경우 요청을 실행할 필요가 전혀 없습니다).두 번째 렌더링을 더 일찍 실행함으로써 이를 피할 수 없습니다.도움이 안 될 거야.

에서는 React가 됩니다.componentWillMount는 여러 번 기동할 수 있으므로 네트워크 요구에 사용해야 합니다.

하면 됩니다.componentDidMount.

왜 어떤 것이 제출되기 전에 요청을 하는 것이 더 낫지 않을까요?

이유:

• 당신의 요구는 컴포넌트가 렌더링되기 전에 거의 확실히 완료되지 않습니다(대량의 마크업을 렌더링하거나 지연이 없는 양자 얽힘 접속을 하지 않는 한).그리고 컴포넌트는 최종적으로 재렌더해야 합니다.대부분의 경우,
• componentWillMount서버측 렌더링 중에도 호출됩니다(해당하는 경우).

---

하지만, 만약 당신이 물어본다면, 요청을 시작하는 것이 더 낫지 않을까요?componentWillMount(실제로 처리하지 않고) 저는 확실히 '네'(ES6)라고 대답하고, 로드 시간으로부터 몇 밀리초를 단축하기 위해 직접 이 작업을 수행합니다.

componentWillMount() {
    // if window && window.XMLHttpRequest
    if (!this.requestPromise) {
        this.requestPromise = new Promise(resolve => {
            // ... perform request here, then call resolve() when done.
        });
    }
}

componentDidMount() {
    this.requestPromise.then(data => ...);
}

그러면 다음 시간 동안 요청이 프리로드되기 시작합니다.componentWillMount단, 요청은 에서만 처리됩니다.componentDidMount그때까지 이미 완료되었는지 아직 진행 중인지 여부입니다.

componentWillMount에서는 부작용 요청을 할 수 없으므로 componentDidMount에서 요청을 해야 합니다.componentWillMount에서 setState를 설정해도 상관없습니다.componentDidMount에서 setState를 설정하면 두 번째 렌더가 즉시 트리거됩니다.

안티패턴(UGHH)으로 일부 라인터에서는 금지(eslint-react-plugin)되어 있는 것을 알 수 있습니다만, DOM과 대화하는 유일한 방법이기도 하기 때문에 크게 신경 쓰지 않습니다.연결된 babel 단계를 사용하는 경우 willMount 또는 메서드 속성( state = { })으로 기본 상태를 설정할 수 있습니다.

말씀하신 것처럼 컴포넌트는 이미 한 번 렌더링되지만, 어떤 종류의 로더 또는 리소스가 로드하는 다른 형태의 정보를 표시할 수 있으므로 좋습니다.

class MyComp extends Component {

    // What I do with stage 0
    state = { mystate: 1 }

    // What you might want to do if you're not 
    // on the experimental stage, no need to do 
    // the whole constructor boilerplate
    componentWillMount() {
        this.setState({ mystate: 1 });
    }

    componentDidMount() {
        dispatch(yourAction());

        // It's fine to setState here if you need to access 
        // the rendered DOM, or alternatively you can use the ref
        // functions
    }

    render() {
        if (!this.props.myCollection) return <Loader />

        return (
           <div> // your data are loaded </div>
        )
    }
}

렌더 메서드 전에 라이프 사이클 훅에서 페치를 피해야 하는 진짜 이유는 React 커뮤니티가 렌더 메서드 호출을 비동기화할 계획이기 때문입니다.

gaeron으로부터의 응답을 확인하려면 , https://github.com/reactjs/reactjs.org/issues/302 를 참조해 주세요.

즉, 렌더링 전에 라이프 사이클 메서드 중 하나에 fetch(또는 그 문제에 대한 비동기 조작)와 같은 비동기 액션을 배치하면 렌더링 프로세스에 방해가 됩니다.

따라서 오늘날 생각할 수 있는 동기 실행과는 달리 다음과 같습니다.

1. 컨스트럭터 << imagine buring fetch （ here > > = > 2. derrent State From Props << fetch 완료, 콜백이 이벤트 루프에 의해 콜백 큐에 추가됨 = > 3. render = > 4. componentDidentDidMount = > 5. 콜백이 추가되어 콜백이 실행되므로 콜백이 지금 콜백이 실행됩니다.

대신 다음과 같습니다.

1. 컨스트럭터 << 여기서 fetch()를 기동한다고 생각한다> => 2. derived State From Props << 그 사이에 fetch가 완료되어 콜백이 큐잉 된다>< 여기서 비동기 렌더()를 기동한다고 생각한다.콜백도 큐잉됩니다>> = > 콜백은 추가된 순서대로 실행됩니다.따라서 fetch callback은 처음에 실행됩니다= > 4. render callback runs = > 5. componentDidMount

렌더가 가져오기 변경 사항을 재정의하는 이전 상태를 적용할 수 있기 때문에 이 간섭으로 인해 상태 변경이 반환될 수 있습니다.

또 다른 이유는 DOM에 대응하는 컴포넌트의 존재를 보증하는 것은 componentDidMount 라이프 사이클이며 fetch가 DOM을 사용 가능하기 전에 조작하려고 하거나 갱신하기 전에 어플리케이션 표시에 장애가 발생할 수 있다는 것입니다.

언급URL : https://stackoverflow.com/questions/41612200/in-react-js-should-i-make-my-initial-network-request-in-componentwillmount-or-co