React: 가로 데이터 로드 구현

undefined 는 onNext 를 통해 옵저버블이 첫 번째 값을 제공할 때까지 data 에 할당하는 가장 안전한 값일 것입니다. 예를 들어 Relay에서 null (데이터가 존재하지 않음) 및 undefined (아직 가져오지 않음)에 다른 의미를 할당하므로 이상적인 기본 데이터 값은 undefined 입니다. 대안은 예를 들어 getInitialData 와 같은 새로운 방법을 제공하는 것이지만 이것이 불필요하거나 과잉이라고 생각합니다.

이것은 꽤 흥미롭지만 정적 타이핑의 관점에서 나는 키/값 시스템에 그다지 만족하지 않습니다. 그 유형은 표현하기가 거의 불가능합니다.
observe 가 단일 관찰 가능 항목을 반환하고 this.data 로 확인된 값을 설정/병합하지 않는 이유는 다음과 같습니다.

class Foo {

  observe() {
    return (
      loadUser(this.props.userID)
        .map(user => { user })
  }

  render() {
    if (this.data.user.id !== this.props.userID) {
      // Ensure that we never show inconsistent userID / user.name combinations.
      return <Spinner />;
    }
    return <div>Hello, {this.data.user.name} [{this.props.userID}]!</div>;
  }

}

그리고 다중 가져오기의 경우 다음과 같습니다.

class Foo {

  observe() {
    return (
     combineLatest(
      loadUser(this.props.userID),
      loadSomethingElse(this.props.somethingElseId),
      (user, somethingElse) => ({ user, somethingElse})
     )
  }

  render() {
    ..
  }

}

이것은 아마도 조금 더 장황하지만 멋진 정적 유형을 가질 수 있습니다.

interface Comp<T> {
  observe(): Observable<T>;
  data: T;
}

또한 props/state가 변경될 때 observe 를 다시 실행하는 대신 'props' 'state'에 옵저버블로 액세스할 수 있습니다.

class Foo {

  observe(propsStream) {
    return (
      propsStream
        .flatMap(({ userID }) => loadUser(userId))
        .map(user => { user })
    );
  }

  render() {
    if (this.data.user.id !== this.props.userID) {
      // Ensure that we never show inconsistent userID / user.name combinations.
      return <Spinner />;
    }
    return <div>Hello, {this.data.user.name} [{this.props.userID}]!</div>;
  }
}

그 이유는 (여러) Observable을 구독할 수 있도록 RxJS를 이해하고 결합자를 사용하도록 요구하지 않기 때문입니다. 이러한 방식으로 두 개의 Observable을 결합하는 것은 매우 혼란스럽습니다. 사실, 최소한 데이터 소스의 경우 구독 API를 구현하지만 Observable의 프로토타입에 결합자는 포함하지 않을 것입니다. 필수 사항은 아니지만 필요한 경우 결합자를 자유롭게 사용할 수 있습니다.

그러나 간단한 Flux 스토어를 구독하기 위해 구독할 필요는 없습니다.

Flow는 아마도 제약 조건을 사용하여 이 정적 유형을 처리할 수 있을 것이라고 생각하지만, 확인하기 위해 해당 사람들에게 확인하겠습니다. 데이터 속성을 입력하고 관찰 유형을 암시하는 것으로 충분할 것이라고 생각합니다.

class Foo extends React.Component {
  data : { user : User, content : string };
  observe() /* implied as { user : Observable<User>, content : Observable<string> } */ {
  }
}

이 변경은 애플리케이션 상태를 설명하는 방법으로 Observables에 올인하는 것에 관한 것이 아닙니다. 이것은 이전에 했던 것처럼 이것 위에 구현될 수 있습니다. 이 메서드는 멱등성이기 때문에 명시적으로 응용 프로그램 상태에 관한 것이 아닙니다. 프레임워크는 필요에 따라 구독을 취소하고 다시 구독할 수 있습니다.

cc @ericvicenti

적어도 typescript의 경우 data 의 유형을 기반으로 observe 의 반환 유형을 제한하는 방법은 적어도 https://github.com/ 과 같은 때까지는 없습니다.

나는 이것을 React DnD의 다음 버전에 사용하고 싶지만 분명히 이것은 React 0.14를 기다려야 합니다.
ref 인스턴스에 this.data 를 설정하는 고차 구성 요소로 당분간 이것을 "폴리필"할 수 있는지 궁금합니다. 그래도 너무 미친 것 같습니다.

약속을 지키는 것이 가능할까요? 그런 다음 첫 번째 렌더링 전에 전체 구성 요소 트리에 대한 데이터를 확인하기 위해 약속 트리를 사용할 수 있습니다! 이것은 서버 측 React에 매우 유용합니다.

이것을 일류 API로 만들면 어떤 이점이 있습니까? 본질적으로 "고차 구성 요소"를 사용하여 수행할 수 있습니다.

이것을 일류 API로 만들면 어떤 이점이 있습니까? 본질적으로 "고차 구성 요소"를 사용하여 수행할 수 있습니다.

5개의 HOC로 래핑하여 5개의 구독을 얻는 것은 초보자에게 다소 다루기 어렵고 이해하기 어렵습니다. componentWillReceiveProps 를 이해하는 것도 쉽지 않습니다. 이렇게 하면 둘 다 해결됩니다.

나는 우선 우리의 새로운 관찰 가능한 대군주를 환영합니다.

이것이 https://github.com/chenglou/react-state-stream 을 React의 바닐라 API에 더 가깝게 만드는 데 도움이 될 수 있는지 궁금합니다.

하나의 HOC가 필요하지 않습니까? Medium 게시물 의 예에서 stores 를 반복하고 각각을 구독합니다.

stores.forEach(store =>
  store.addChangeListener(this.handleStoresChanged)
);

@aaronshaf 확실히 사용 사례에 따라 @sebmarkbage가 말하는 것을 들어보겠습니다.

이제 이것을 가지고 놀기 위해 일종의 폴리필을 좋아할 것입니다. 아직 아이디어를 완전히 이해하지 못했습니다. 향후 업데이트 처리와 관련된 메커니즘은 무엇입니까? 나는 그것을 이해하는 데 더 많은 시간을 할애 할 것입니다. 간단한 mixin으로 가능해야 한다고 생각합니다.

( @vjeux 는 내가 차임벨을

내 작업을 홍보하려는 것은 아니지만 이 후크는 React Nexus 의 getNexusBindings 후크와 매우 유사하다고 생각합니다. 수명 주기 후크(props에 따라 달라질 수 있음)를 통해 구성 요소 수준에서 데이터 deps를 선언합니다.

API는 다음과 같습니다.

class UserDetails {
  getNexusBindings(props) {
    return {
      // binding to data in the datacenter
      posts: [this.getNexus().remote, `users/${this.props.userId}/posts`],
      // binding to data in the local flux
      mySession: [this.getNexus().local, `session`],
    }
  }
}

바인딩은 componentDidMount 및 componentWillReceiveProps 동안 적용/업데이트됩니다. 후자의 경우 다음 바인딩은 이전 바인딩과 다릅니다. 제거된 바인딩은 구독 취소되고 추가된 바인딩은 구독됩니다. 기본 가져오기/업데이트 메커니즘은 Nexus Flux 구현에 설명되어 있습니다. 기본적으로 동일한 API를 사용하여 로컬 데이터(기존 로컬 저장소) 또는 원격 데이터(GET을 사용하여 가져오고 Websockets/polyfill을 통해 패치 수신)를 구독할 수 있습니다. 실제로 다른 창(postWindow 사용) 또는 WebWorker/ServiceWorker에서 데이터를 구독할 수 있지만 이에 대한 진정으로 유용한 사용 사례를 찾지 못했습니다.

간단히 말해서 Flux 추상화를 사용하여 구성 요소 수준에서 데이터 deps를 동기식으로 설명하고 후크는 종속성이 자동으로 구독되고 업데이트 시 주입되고 구독 취소되도록 합니다.

그러나 여기에는 멋진 기능도 함께 제공됩니다. 정확히 동일한 수명 주기 기능을 활용하여 서버 측 렌더링 시간에 데이터 프리페치를 수행합니다. 기본적으로 React Nexus는 루트에서 시작하여 거기에서 재귀적으로 바인딩을 미리 가져오고 구성 요소를 렌더링하고 모든 구성 요소가 렌더링될 때까지 하위 항목을 계속 진행합니다.

@aaronshaf @gaearon 일등석 으로 만드는 이점은 다음과 같습니다.

1) props 네임스페이스를 잡아먹지 않습니다. 예를 들어 고차 컴포넌트는 다른 용도로 사용할 수 없는 data 와 같은 이름을 props 객체에서 요구할 필요가 없습니다. 여러 개의 고차 구성 요소를 연결하면 더 많은 이름을 계속 사용하므로 이제 이러한 이름을 고유하게 유지하는 방법을 찾아야 합니다. 이미 작성되었을 수 있는 항목을 작성하고 있는데 이제 이름 충돌이 발생하면 어떻게 됩니까?

게다가, 고차 구성 요소에 대한 모범 사례는 래핑된 구성 요소의 계약을 변경하지 않는 것이어야 한다고 생각합니다. 즉, 개념적으로 아웃과 동일한 소품이어야 합니다. 그렇지 않으면 소비자가 수신한 것과 완전히 다른 props 세트를 제공할 때 사용하고 디버그하는 것이 혼란스럽습니다.

2) 마지막 값을 저장하기 위해 state 를 사용할 필요가 없습니다. data 개념은 순전히 메모이제이션이라는 점에서 props 와 유사합니다. 메모리를 회수해야 하는 경우 언제든지 자유롭게 버릴 수 있습니다. 예를 들어, 무한 스크롤에서 보이지 않는 하위 트리를 자동으로 정리할 수 있습니다.

@RickWong 예, Observable의 하위 집합이기 때문에 Promise를 지원하는 것은 매우 간단합니다. 우리는 의견이 없는 것처럼 그렇게 해야 할 것입니다. 그러나 나는 여전히 그것들을 사용하지 않는 것이 좋습니다. 다음과 같은 이유로 Observable보다 열등하다는 것을 알았습니다.

A) 프레임워크에서 자동으로 취소할 수 없습니다. 우리가 할 수 있는 최선은 늦은 해결을 무시하는 것입니다. 그 동안 Promise는 잠재적으로 고가의 리소스를 보유하고 있습니다. 장기 실행 타이머/네트워크 요청의 subscribe/cancel/subscribe/cancel...과 같은 난잡한 상황에 빠지기 쉽고 Promises를 사용하면 루트에서 취소되지 않으므로 그냥 기다려야 합니다. 리소스를 완료하거나 시간 초과합니다. 이는 facebook.com과 같은 대형 데스크톱 페이지의 성능이나 메모리가 제한된 환경(예: 반응 네이티브)의 대기 시간이 중요한 앱의 성능에 해로울 수 있습니다.

B) 당신은 오직 하나의 가치만을 얻는 것에 자신을 가두고 있습니다. 시간이 지남에 따라 해당 데이터가 변경되면 보기를 무효화할 수 없으며 결과적으로 일관성이 없는 상태가 됩니다. 반응하지 않습니다. 그러나 괜찮을 수 있는 단일 서버 측 렌더링의 경우 클라이언트에서 이상적으로는 새 데이터를 UI로 스트리밍하고 오래된 데이터를 방지하기 위해 자동으로 업데이트할 수 있는 방식으로 설계해야 합니다.

따라서 Observable은 필요한 경우 이러한 문제를 해결하기 위해 사용자를 잠그지 않기 때문에 빌드할 수 있는 우수한 API라는 것을 알았습니다.

@elierotenberg 참여 해주셔서 감사합니다! 실제로 매우 유사해 보입니다. 같은 종류의 혜택. 내 제안에 제한이 있습니까? 즉, React Nexus에 누락된 것이 있는데 이 위에 빌드할 수 없는 것이 있습니까? 중요한 사용 사례에서 스스로를 잠그지 않는다면 좋을 것입니다. :)

서버 렌더링 관점에서 Observable/Promise가 비동기적으로 가져올 수 있는 데이터로 해결될 때까지 최종 renderToString을 연기할 수 있는 것이 중요합니다. 그렇지 않으면 아직 페이지에 어떤 구성 요소가 있는지 알지 못한 채 React 외부에서 모든 비동기 데이터 가져오기를 수행해야 하는 위치에 있습니다.

나는 react-nexus가 렌더 트리를 계속 내려가기 전에 컴포넌트 내에서 비동기 로딩을 허용한다고 믿습니다.

예, react-nexus는 다음을 명시적으로 구분합니다.
1) getNexusBindings 로 선언 바인딩
2) 구독/업데이트를 applyNexusBindings 바인딩
3) 프리페칭을 prefetchNexusBindings 로 바인딩(비동기식이며 "초기"(이것이 의미하는 것이 무엇이든) 값이 준비되면 해결됨)

ReactNexus.prefetchApp(ReactElement) 는 Promise(String html, Object serializableData) 반환합니다. 이 후크는 React 트리의 구성을 모방하고( instantiateReactComponent ) 구성 요소를 재귀적으로 구성/프리페치/렌더링합니다. 전체 구성 요소 트리가 '준비'되면 모든 데이터가 준비되었음을 알면서 마침내 React.renderToString 호출합니다(모듈로 오류). 해결되면 이 Promise의 값을 서버 응답에 삽입할 수 있습니다. 클라이언트에서 일반 React.render() 수명 주기는 평소와 같이 작동합니다.

누군가가 이런 종류의 API를 가지고 놀고 싶다면 observe 에 대해 고차 구성 요소로 정말 멍청한 폴리필을 만들었습니다.

import React, { Component } from 'react';

export default function polyfillObserve(ComposedComponent, observe) {
  const Enhancer = class extends Component {
    constructor(props, context) {
      super(props, context);

      this.subscriptions = {};
      this.state = { data: {} };

      this.resubscribe(props, context);
    }

    componentWillReceiveProps(props, context) {
      this.resubscribe(props, context);
    }

    componentWillUnmount() {
      this.unsubscribe();
    }

    resubscribe(props, context) {
      const newObservables = observe(props, context);
      const newSubscriptions = {};

      for (let key in newObservables) {
        newSubscriptions[key] = newObservables[key].subscribe({
          onNext: (value) => {
            this.state.data[key] = value;
            this.setState({ data: this.state.data });
          },
          onError: () => {},
          onCompleted: () => {}
        });
      }

      this.unsubscribe();
      this.subscriptions = newSubscriptions;
    }

    unsubscribe() {
      for (let key in this.subscriptions) {
        if (this.subscriptions.hasOwnProperty(key)) {
          this.subscriptions[key].dispose();
        }
      }

      this.subscriptions = {};
    }

    render() {
      return <ComposedComponent {...this.props} data={this.state.data} />;
    }
  };

  Enhancer.propTypes = ComposedComponent.propTypes;
  Enhancer.contextTypes = ComposedComponent.contextTypes;

  return Enhancer;
}

용법:

// can't put this on component but this is good enough for playing
function observe(props, context) {
  return {
    yourStuff: observeYourStuff(props)
  };
}

class YourComponent extends Component {
  render() {
    // Note: this.props.data, not this.data
    return <div>{this.props.data.yourStuff}</div>;
  }
}

export default polyfillObserve(YourComponent, observe);

Observable은 라이브러리 구현을 제외하고 구체적이고 합의된 것입니까? 계약이란 무엇입니까? 베이컨이나 Rxjs를 사용하지 않고도 구현할 수 있을 만큼 간단합니까? 데이터를 사이드로딩하기 위한 일류 API만큼 훌륭하지만, 일반 js를 향한 React의 꾸준한 움직임을 감안할 때 React가 지정되지 않은/매우 초기 지정 프리미티브를 기반으로 하는 API를 추가하는 것은 이상해 보입니다. 이와 같은 것이 우리를 특정 사용자 토지 구현에 연결합니까?

제쳐두고 스트림이 아닌 이유는 무엇입니까? 경주에는 말이 없지만 솔직히 궁금합니다. 이미 웹 스트림에 대한 작업이 완료되었으며 물론 노드가 있습니다.

고려해야 할 또 다른 두 가지: https://github.com/cujojs/most 및 https://github.com/caolan/highland

@jquense Observable을 ECMAScript 7(+)에 추가하는 제안에 대한 활성 작업이 있으므로 이상적으로는 일반 JS가 됩니다. https://github.com/jhusain/asyncgenerator (현재 구식입니다.)

우리는 RxJS에 의존하지 않을 것입니다. API는 RxJS를 사용하지 않고 스스로 구현하기 쉽습니다. RxJS는 활성 ECMAScript 제안에 가장 가깝습니다.

most.js도 가능한 것 같습니다.

Bacon.js의 API는 값을 구분하기 위해 Bacon.Event 타입을 사용하기 때문에 Bacon에 의존하지 않고는 사용하기 어려운 것 같습니다.

Stream API는 너무 높은 수준이며 이 사용 사례에서 멀리 떨어져 있습니다.

"await before render" 옵션이 있습니까? 제 말은 클라이언트에서는 렌더링하기 전에 모든 Observable을 기다릴 필요가 없지만 서버에서는 각 구성 요소의 render()가 해결될 때까지 기다려야 한다는 뜻입니다. 부분이 아닌 전체 .

[parent] await observe(). full render(). -> [foreach child] await observe(). full render().

모든 탐색에서 이것이 서버 측 React에서 누락된 가장 중요한 수명 주기 후크임을 발견했습니다.

이 토론에 이어 다음 게시물에서 React Nexus가 하는 일을 요약하려고 했습니다.

React Nexus로 제대로 된 Ismorphic 앱

핵심 프리페칭 루틴의 다이어그램은 다음과 같습니다.

우리는 RxJS에 의존하지 않을 것입니다. API는 RxJS를 사용하지 않고 스스로 구현하기 쉽습니다. RxJS는 활성 ECMAScript 제안에 가장 가깝습니다.

:+1: 이것은 내가 무엇을 하고 있는지 알지 못하는 한 스스로 구현하는 것이 극도로 어려운 약속에 대해 생각하면서 가장 큰 관심사입니다. 그렇지 않으면 생태계의 특정 라이브러리에 대한 암시적 요구 사항으로 끝납니다. 접선적으로... Promise 세계의 좋은 점 중 하나는 A+ 테스트 스위트이므로 라이브러리 전체에 걸쳐서라도 .then 의 공통 기능에 대한 보증이 최소한 있었습니다. 표준화.

당신이 무엇을 하고 있는지 알지 못한다면 당신 자신의 것을 구현하는 것이 극도로 어려운 약속에 대해 생각하면서 이것이 저에게 큰 관심사입니다. 그렇지 않으면 생태계의 특정 라이브러리에 대한 암시적 요구 사항으로 끝납니다.

완전히 동의했습니다. 고맙게도 옵저버블은 정말 간단한 계약을 가지고 있고 then 와 같은 내장 메서드도 없기 때문에 어떤 면에서는 프라미스보다 훨씬 간단합니다.

위원회에서 next 호출이 Promises와 같은 미세 작업을 예약한다고 주장하면 더 복잡해지고 느려질 수 있습니다.

이는 onNext가 RxJS에서 동기식이라는 사실에 기반한 많은 패턴을 귀찮게 할 것입니다.

일반적인 Flux 저장소 패턴은 재사용할 수 있도록 키별로 Map of Observable을 유지하는 것일 수 있다고 생각합니다. 그런 다음 모든 사람이 구독을 취소할 때 정리합니다.

그렇게 하면 MyStore.get(this.props.someID) 와 같은 작업을 수행할 수 있으며 항상 동일한 Observable을 반환합니다.

그렇게 하면 MyStore.get(this.props.someID)과 같은 작업을 수행하고 항상 동일한 Observable을 반환할 수 있습니다.

this.props.key (gone I know)를 사용하는 것이 의미가 있습니까? 대부분의 경우 이러한 고유 식별자를 이미 <... key={child.id} .. /> 로 전달합니다.

그렇게 하면 MyStore.get(this.props.someID)과 같은 작업을 수행하고 항상 동일한 Observable을 반환할 수 있습니다.

이것이 내가 React Nexus에도 사용하는 패턴입니다. Store#observe는 메모화된 변경 불가능한 관찰자를 반환합니다. 모든 구독자가 적어도 한 틱 동안 사라지면 정리됩니다(실제 "구독 취소" 메시지 보내기와 같은 관련 백엔드별 정리 메커니즘 포함).

@sebmarkbage @gaearon v0.14 에서 서버 작업을 어떻게 관찰할까요?
react-nexus가 하는 것과 유사하게 문자열로 렌더링하기 전에 모든 관찰자가 해결될 때까지 적절하게 기다릴 수 있습니까(그러나 반응하도록 내장되어 있음)?

IMO 구성 요소가 서버에서 렌더링할 "준비"되기 전에 첫 번째 관찰 값을 기다린다면 좋을 것입니다.

@gaearon : IMO 구성 요소가 서버에서 렌더링할 "준비"되기 전에 첫 번째 관찰 값을 기다린다면 좋을 것입니다.

예, :+1: 비동기 렌더링의 경우. 그 동안 @andreypopp 의 react-async 가 대안이지만 React를 "해킹"하려면 fibers 가 필요합니다. React가 기본적으로 비동기 렌더링을 지원할 수 있다면 좋을 것입니다.

비동기 렌더링은 지원하고 싶지만 이 문제의 일부가 아닙니다. 엘

불행히도 0.14에서는 아마 그것을 만들지 않을 것입니다. 고려하고 리팩토링해야 할 다양한 디자인이 필요합니다.

그렇게 하는 데 필요한 내부 아키텍처 변경 사항을 작성하고 설명하는 문제를 자유롭게 작성하십시오.

@gaearon re: react-streaming-state 와 같은 생각을 했습니다 . 사이드 로딩 이외의 모든 잠재적인 응용 프로그램을 고려할 때 data 보다 더 나은 이름이 있을까요? 예를 들어 observed 는 메서드와 더 명확하게 연관됩니다.

Bikeshedding으로 탈선하려는 것은 아니지만 이것을 버리고 싶었습니다.

React에서 Observable을 기다릴 수 없습니다. 이것은 내가 이해할 때 React를 반응형으로 만들어야 합니다.

react-async 를 다시 작성하는 동안 비슷한 아이디어를 실험하고 있습니다. README 를 참조하십시오.

주목할만한 차이점은 React가 key prop 및 stateful 구성 요소를 사용하는 방식과 유사하게 프로세스를 조정하기 위해 명시적 관찰 가능/프로세스 ID를 도입한다는 것입니다.

명명된 프로세스의 id 가 변경되면 React Async는 이전 프로세스 인스턴스를 중지하고 새 인스턴스를 시작합니다.

API는 다음과 같습니다.

import React from 'react';
import Async from 'react-async';

function defineFetchProcess(url) {
  return {
    id: url,
    start() {
      return fetch(url)
    }
  }
}

function MyComponentProcesses(props) {
  return {
    user: defineFetchProcess(`/api/user?user${props.userID}`)
  }
}

@Async(MyComponentProcesses)
class MyComponent extends React.Component {

  render() {
    let {user} = this.props
    ...
  }
}

프로세스 API는 이제 구문적으로나 이름적으로 ES6 Promises API를 따르지만 의미상으로는 process.then(onNext, onError) 가 라이브 프로세스당 한 번만 호출될 것으로 예상되지 않습니다. Promise를 통해 데이터를 가져오는 가장 인기 있는(?) 사용 사례를 수용하도록 만들어졌습니다. 하지만 솔직히 지금은 혼란을 막기 위해 바꿔야 한다고 생각한다.

내가 틀렸을 수도 있지만 사용자 영역에서 제안된(이 문제에서) API를 구현하는 것을 방해하는 유일한 것은 componentWillUpdate 와 같이 렌더링 직전에 실행되지만 새로운 props 실행되는 수명 주기 후크가 없다는 것입니다. 그리고 state 이미 인스턴스에 설치되어 있습니다.

아직 논의되지 않은 한 가지는 onError 콜백 처리입니다. Observable에서 오류가 발생하면 해당 정보를 구성 요소에서 어떻게든 사용할 수 있어야 합니다. React는 실제 subscribe(callbacks) 호출을 처리하기 때문에 해당 콜백 객체에 주입하려면 표준화된 메서드가 필요합니다.

애플리케이션 개발자에게 최대한의 유연성을 제공하기 위해 두 가지 접근 방식이 있습니다. 첫 번째는 this.data 와 유사한 최상위 속성에 오류를 배치하는 것입니다. 이것은 엄청나게 무거워 보이며 구성 요소의 네임 스페이스를 더 많이 먹습니다.
두 번째는 개발자가 자신의 onError 콜백을 수명 주기 기능으로 정의할 수 있도록 합니다. 내 옵저버블에 대한 사용자 정의 오류 처리를 원하면 다음과 같은 것을 추가할 수 있습니다.

onObserveError(key, error) {
  // do something with the error
  this.state.errors[key] = error;
  this.setState({ errors: this.state.errors });
}

이것은 Parse+React의 다음 반복에서 수행한 작업과 유사합니다. 우리는 우리가 원하는 API를 생성하기 위해 자체 오류 처리를 만들었습니다. 개인 { name => error } 지도에 오류가 추가되고 구성 요소에는 비어 있지 않은 경우 지도의 복제본을 반환하는 최상위 공개 메서드인 queryErrors() 및 null 가 있습니다. 그렇지 않으면 (단순한 if (this.queryErrors()) 허용.

물론 새로운 예약 메서드를 정의하는 것도 까다로운 작업입니다. 아닌 척 하지 않겠습니다. 그러나 렌더링할 때 구성 요소에서 오류를 암시적 또는 명시적으로 사용할 수 있도록 하는 방법이 필요합니다.

@andrewimm 아이디어는 오류 경계에 의해 처리될 때까지 계층 구조 위로 오류를 버블링하는 일반 오류 전파 시스템에 입력하는 것입니다. https://github.com/facebook/react/issues/2928

이것은 또한 메서드를 던지고 정상적으로 복구하는 오류를 처리해야 합니다. render() 메서드가 throw하는 것과 같습니다. 이것은 훨씬 더 많은 작업이 필요하고 제대로 구현하는 데 시간이 좀 걸리지만 이러한 방식으로 오류 처리를 통합하는 것이 아이디어였습니다.

나는 이것이 적절한 반응 외부에 두어야 한다고 주장하고, 1개 또는 2개의 핵심 통합 지점은 react-async 및 react-nexus와 같은 프로젝트와 조정되어야 적절한 React 위에서 깔끔하게 수행될 수 있습니다....

동의합니다. 제안된 방법을 사용하는 것이
이것을 프레임워크 자체에 굽기

2015년 4월 21일 화요일 오후 11:38 Rodolfo Hansen [email protected]
썼다:

나는 이것이 적절한 반응 외부에 남겨 두어야한다고 주장하고 1 또는 2 키
통합 지점은 react-async 및
react-nexus를 사용하여 적절한 React 위에서 깔끔하게 수행할 수 있습니다....

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/facebook/react/issues/3398#issuecomment -95048028.

주말 동안 저는 Flexy 라는 또 다른 Flux 구현을 구축했습니다. 여기에서 상점의 코드를 확인하십시오. 실제로 사용되는 옵저버블이나 다른 Reactive 프레임워크가 없음에도 불구하고 옵저버블 API를 준수하는 .getObservable 메서드를 노출합니다.

따라서 API는 실제 Observable로 생성할 수 있을 만큼 쉽다고 말하고 싶습니다.

즉, 코드를 가혹하게 판단하지 마십시오. 주말 동안 수행되었습니다.

• 재미있는
• 이해
• js-csp를 사용하여
• 관찰 API 사용

참고로 이와 같은 시스템과 Flux는 실제로 서버 측 렌더링을 덜 고통스럽게 만듭니다. React-Nexus와 유사한 시스템을 사용하여 스토어를 초기화하고 React 앱에 전달할 수 있습니다. 그런 다음 상점과 디스패처를 모니터링하고 더 이상 작업이 실행되지 않을 때까지 계속 다시 렌더링할 수 있습니다(필요한 모든 데이터가 이미 상점에 있음).

나는 이것이 상태 비저장 데이터 구독의 새로운 의미를 얻기 위한 가장 작은 통합 지점이라고 주장합니다. 다른 어떤 통합 포인트를 제안하시겠습니까? 훨씬 더 복잡한 문제이고 자체 스레드가 필요한 비동기 렌더링을 포함하지 않으며 이 후크는 관계없이 비동기 렌더링과 함께 사용할 수 있습니다.

다른 모든 것은 이미 구성 요소별로 React를 기반으로 구현할 수 있습니다. 플러그인의 전역 주입은 환경 전반에서 구성 요소 재사용을 중단하므로 React를 기반으로 구축된 프레임워크는 개별 구성 요소에 대해 컨텍스트여야 하므로 플러그인의 전역 주입을 수행하지 않을 것입니다.

우리는 어떤 후크를 놓치고 있습니까?

야,

솔직히 말해서, 새로운 후크가 구현을 더 쉽게 만들긴 했지만 react-async 및 react-nexus 시연한 것처럼 후크 없이도 측면 데이터 로드를 확실히 달성할 수 있습니다.

어쨌든 탑재된 React 계층 구조 외부에서 React 구성 요소 인스턴스 수명 주기를 유지 관리하는 것을 노출하고 지원하는 것이 도움이 될 것입니다. react-nexus 에서 내부 instanciateReactComponent 하고 componentWillMount , componentWillUnmount 등을 직접 호출하며 이 접근 방식이 취약하다고 생각합니다( instanciateReactComponents 는 다음 버전의 React?에서 변경되는 내부 불변에 의존합니다.).

상태 비저장 접근 방식의 경우 비동기 데이터를 _is_ 상태로 가져오고 따라서 일부 구성 요소의 상태에 보류/완료/실패 상태를 저장하는 것이 관련이 있는 것 같습니다. 실제 앱에서 react-nexus 를 사용할 때 데이터 가져오기를 수행하고 가져오기 상태를 자식 구성 요소에 소품으로 주입하는 고차 구성 요소가 있습니다. 따라서 내부 구성 요소는 "상태 비저장"(바람직함)이고 외부 구성 요소는 "상태 저장"(예: 로딩 스피너 또는 자리 표시자를 표시하는 데에도 바람직함)입니다.

다른 어떤 통합 포인트를 제안하시겠습니까?

@ANDREYPOPP 가 올바른 질문을 한 것 같습니다. 렌더링하기 전에 사용자 영역에서 수명 주기 후크를 구현해야 하는 유일한 것이 아닌가요? 최소한의 API 변경이 필요한 것처럼 보이지만 나머지는 입력 스트림/이미터/관찰 가능한 항목에 따라 data 를 변경할 때 forceUpdate를 적절하게 설정하고 트리거하는 것입니다. 내가 그것에 대해 다른 특별한 것을 놓치고 있지 않다면 (완전히 가능)?

나는 여기서 더 큰 논의에 빠져들지 않습니다.
하지만 @sebmarkbage 에 답하기 위해 내가 원하는 가장 중요한 후크 중 하나는 실제 관찰 가능 항목을 사용하지 않을 때만 필요한 것이라고 생각합니다.

• 데이터로 설정되기 _전에_ 옵저버블에 의해 푸시된 값을 처리할 수 있는 기능을 제공할 수 있는 후크. 실제 옵저버블을 사용하면 .map 가 됩니다.

상황이 좀 더 개방적이었다면 Observable 관련 동작을 커스텀 훅으로 대체할 훅이 있어야 한다고 생각합니다. 이런 식으로 이벤트 이미터 또는 CSP 채널을 대신 ​​사용할 수 있습니다.

마지막 몇 댓글이 가장 작은 확장 지점이 실제로 "연결" 및 "연결 해제" 수명 주기 후크라고 말하는 것 같습니다. 이를 통해 구성 요소에 비동기 데이터를 쉽게 연결하고 해당 구독을 관리할 수 있습니까?

그런 다음 Observable은 (코어 내부 또는 외부) 이를 기반으로 상당히 사소하게 구축될 수 있지만 이러한 수명 주기 지점을 노출하는 것이 더 큰 매력이 있습니까?

합리적인 요약인가요?

나는 또한 이것이 React 자체에서 해결되어야 한다고 아직 확신하지 못합니다. 나는 React가 React 위에 이 기능을 구축하는 데 필요한 모든 후크를 제공해야 한다고 생각하는 경향이 훨씬 더 큽니다.

하지만 잠시 동안 observe() 한다고 가정해 보겠습니다. 몇 가지 생각:

this.props , this.state , this.context 및 현재 this.data 가 모두 render() 잠재적인 새 데이터 소스입니다. 이것은 나에게 과도한 것 같습니다. 구성 요소 상태에서 응용 프로그램 상태를 분리하는 아이디어입니까? 이것은 국가와 관련된 몇 가지 문제를 명확하게 하고 분리할 수 있지만 새로운 입력을 도입하는 비용이 이득보다 크지 않을 수 있다고 생각합니다. this.state 가 구성 요소 상태에만 집중되도록 하려면 this.data 의 필드를 this.props 또는 this.context 추가하지 않는 이유는 무엇입니까?

this.data 이름이 너무 일반적입니다. props는 데이터, state는 데이터, 모든 지역 변수는 데이터입니다. 이름은 의미를 추가하지 않고 기존 의미를 혼란스럽게 합니다. 저는 this.observed 또는 실제로 의미가 있는 다른 이름을 훨씬 선호합니다. 따라서 @matthewwithanm 의 댓글에 +1:

data 보다 더 나은 이름이 있을까요? 예를 들어 observed 는 메서드와 더 명확하게 연관됩니다.

observe() 가 서버에서 실행되도록 하면 마운트 해제가 절대 발생하지 않기 때문에 이로 인해 발생할 수 있는 메모리 누수를 정리하는 일종의 후크가 필요합니다.

props 또는 state 변경될 때마다 observe() 다시 호출하면(그리고 context ?) observe 는 성능에 최적화되어야 하며 이상적으로는 실수로 비싸게 만들 수 없습니다. 그것은 뜨거운 길의 일부가 됩니다. 나는 React Nexus에서 이것을 좋아합니다.

다음 바인딩은 이전 바인딩과 다릅니다. 제거된 바인딩은 구독 취소되고 추가된 바인딩은 구독됩니다.

나는 상태가 컴포넌트를 복잡하게 만든다는 것을 믿게 되었고, 내 자신의 컴포넌트에서 그것을 덜 사용 하고 대신 했습니다 . 이것이 @fisherwebdev가 제기한 우려( observe 가 state 에 의존하도록 하는 것이 좋은 생각이라고 확신하지 못하는 이유입니다. State는 props에 의존하고 관찰은 state _and_ props에 의존합니다. 너무 복잡하지 않습니까? 차라리 observe(props) 갖고 싶습니다.

나는 또한 관찰이 state 에 의존해서는 안 된다는 것을 깨닫고 있습니다. 대부분 그럴 필요가 없기 때문입니다. @gaearon 이 지적했듯이 상태를 한 단계 위의 수준으로 끌어올리는 것은 충분히 쉽기 때문에 관심사를 분리하고 나면 더 깔끔해집니다. observe 가 state 에 잠재적으로 의존할 수 있는 경우 구성 요소 내에서 업데이트를 처리하는 논리가 훨씬 더 복잡해집니다. props 에만 의존하는 경우 componentDidMount / componentWillReceiveProps 에 포크 없는 핸들러를 가질 수 있습니다. 중요 경로의 코드가 적으면 렌더링 주기가 더 단순해지고 구독을 다시 트리거하는 의도하지 않은 업데이트 수도 줄어듭니다.

관찰(소품)에 대해 +1

우리가 다루는 것이 적을수록 더 나은 IMO가 됩니다.

나는 라이브러리로서 React가 가능한 한 유연해야 한다고 생각합니다. 나는 관찰이 상태에 의존하는 것은 좋은 생각이 아니라는 데 동의합니다. 예, 복잡할 수 있습니다. 예, 가장 좋은 방법은 상태에 의존하지 않는 것입니다.
그러나 그것은 React 사용자에게 허용되어야 하는 선택입니다.
현재 API를 변경하지 않고(예를 들어 관찰 가능한 것 이상과 함께 작동하도록 하기 위해 유연성을 추가하기 위해 가능한 후크 제외), 관찰 메서드에서 상태를 사용하는 것이 권장되지 않음을 설명하는 문서를 증명하는 것이 좋습니다.

나는 모든 사람이 옳은 일을 하기를 원하고 우리가 올바른 방향으로 인도되기를 원한다고 믿습니다. 수락하지 않는 상태를 관찰하면 문서에서 "이것은 반패턴입니다"와 같은 것을 실수로 찾는 것보다 사용자에게 더 쉽습니다.

편집: 죄송합니다. 방금 flatMap 찾고 있었다는 것을 깨달았습니다. 나는 그것이 메시지 배열을 평평하게 할 것이라고 생각했기 때문에 혼란스러웠지만 더 높은 수준에서 작동하고 있습니다(메시지 관찰 가능).

제안된 API는 한 데이터 필드의 결과가 다른 데이터 필드의 결과에 종속되는 경우를 처리합니까? 즉, 첫 번째 결과를 매핑하고 관찰 가능 항목을 반환합니다.

observe(props, context) {
  if (!props.params.threadID) {
    return {};
  }

  const observeThread = ThreadStore.observeGetByID(
    {id: props.params.threadID}
  );
  return {
    thread: observeThread,
    messages: observeThread.map(thread => {
      return MessageStore.observeGetByIDs({ids: thread.messageIDs});
    })
  };
}

나는 일반적으로 옵저버블에 익숙하지 않기 때문에 이 문제에 대해 완전히 틀릴 수 있습니다. promise-land에서 이것은 매우 간단합니다. then 에서 promise를 반환하면 후속 then 이 해당 promise를 기반으로 하기 때문입니다.

this.state 의존해서는 안된다는 의견을 이해하지 못합니다. 캡슐화된 상태는 확실히 React를 훨씬 더 복잡하게 만들지만 그게 전부입니다. 캡슐화된 상태가 없으면 메모화된 즉시 모드 라이브러리만 필요합니다. "Stores"에 올인하면 네, 상태가 필요하지 않지만 React에서 그렇게 하도록 규정한 것은 아닙니다.

추가 래퍼를 생성해야 하는 몇 가지 패턴이 있지만 일반적인 사용에서는 그럴 필요가 없습니다. 상점 외에 관찰된 데이터는 간접적이더라도 항상 상태에 의존합니다. 관찰에 의존하는 것이 나쁜 습관은 아니라고 생각합니다. 예

observe() {
  return { items: Items.getPagedItems({ pageIndex: this.state.currentPage }) };
}

observe 가 state 에 의존하지 않더라도 여전히 props 및 context 에 의존합니다. context 에 의존하지 않더라도 $# observe 에서 사용하는 구성 요소의 소품을 렌더링하기 위해 context 를 사용하는 간접 참조가 있습니다.

observe 는 props가 변경되었을 수 있기 때문에 렌더 패스가 다운될 때마다 재평가되어야 합니다. 그러나 결과 관찰 가능 항목을 확실히 비교하고 동일한 관찰 항목이 반환되는 경우 구독 취소/재구독을 하지 않습니다. 그러나 개별 속성(shouldComponentUpdate 제외)에 대해 diff를 수행할 수 없으므로 Map 를 전원 기능으로 사용하여 고유한 캐시를 구현하는 것이 이상적입니다. 그렇게 하면 트리의 여러 구성 요소에 동일한 관찰 가능 항목을 반환할 수 있습니다. 예를 들어 동일한 사용자를 로드하는 여러 구성 요소. 그렇지 않은 경우에도 Observable을 다시 만들고 결국에는 하단 캐시에 도달하게 됩니다. 이것이 바로 React 조정이 작동하는 방식입니다. 그렇게 느리지 않습니다.

이 observe 후크는 상태가 Observable에서 캡처된다는 점에서 React를 완전히 반응적으로 만들도록 설계되지 않았습니다. 현재 주요 설계 목표는 클로저와 결합기에서 상태를 트래핑하는 것을 피하고 대신 동결 및 부활이 가능하고 작업자 간에 잠재적으로 공유할 수 있는 깨끗하고 별도의 상태 트리를 갖는 것입니다.

나의 마지막 요점에 이르게 하는 것은...

우리는 이것을 핵심 라이브러리에 추가할 필요가 _필요하지 않습니다_. 원래 "공개" 인터페이스는 mountComponent/receiveComponent였으며 그 위에 전체 복합 구성 요소 시스템을 구축할 수 있습니다. 그러나 이제 더 높은 추상화 막대에 의해 활성화되는 다른 것을 구축할 수 있기 때문에 추상화 막대를 높이는 것이 훨씬 더 강력하다는 것을 사용하는 사람은 많지 않습니다. 구성 요소 전체 최적화와 같은.

React의 주요 목적은 생태계의 서로 다른 추상화가 공존할 수 있도록 구성 요소 간에 계약을 생성하는 것입니다. 그 역할의 중요한 부분은 공통 개념에 대한 추상화 수준을 높여 새로운 교차 구성 요소 기능을 사용할 수 있도록 하는 것입니다. 예를 들어 하위 트리의 모든 상태를 저장한 다음 하위 트리를 부활시킵니다. 또는 서버에서 자동 마운트 해제를 포함하거나 서버에서 조정의 타이밍 측면을 변경할 수 있습니다.

이 모든 것을 맛있고 균일하게 만들기 위해 포함된 일부 배터리를 제공하는 것도 중요합니다.

마이크로 모듈화(예: 새로운 라이프 사이클 후크 추가)가 프레임워크에 빌드하는 것보다 엄밀히 말하면 순수한 승리가 아니라는 점을 깨닫는 것이 중요합니다. 또한 시스템 전체의 추상화에 대해 더 이상 추론할 수 없음을 의미합니다.

이와 같은 것이 "철학/설계 목표/비목표"로 문서에 있었으면 합니다.

React의 주요 목적은 생태계의 서로 다른 추상화가 공존할 수 있도록 구성 요소 간에 계약을 생성하는 것입니다. 그 역할의 중요한 부분은 공통 개념에 대한 추상화 수준을 높여 새로운 교차 구성 요소 기능을 사용할 수 있도록 하는 것입니다.

이거 너무 좋아. 나는 이것이 일종의 문서에 있다면 좋을 것이라는 @gaearon의 말에 동의합니다.

우리는 확실히 이것을 핵심 라이브러리에 추가할 필요가 없습니다.... 그러나, 더 높은 추상화 막대에 의해 활성화되는 다른 것을 구축할 수 있기 때문에 추상화 막대를 높이는 것이 훨씬 더 강력하다는 것을 사용하는 사람은 많지 않습니다. 구성 요소 전체 최적화와 같은.

나는 (적어도 나를 위해) 과묵함은 다른 API를 추가하는 것이 아니라 작동하기 위해 비언어(아직 정의되고 있는) 구조에 의존하는 API를 추가하는 것이라고 생각합니다. 이것은 완전히 잘 될 수 있지만 Promise 라이브러리가 서로를 신뢰할 수 없는 Promise 라이브러리에 대해 걱정합니다. 이로 인해 불필요한 래핑 및 방어 작업이 발생하여 올바르게 해결되었는지 확인하고 최적화 기회가 제한됩니다. . 또는 더 나쁜 것은 결코 변경할 수 없는 깨진 구현으로 jQuery처럼 갇히게 될 것입니다.

@jquense 전적으로 동의합니다. 오래전에 이 후크를 추가하고 싶었습니다. (원래 실험: https://github.com/reactjs/react-page/commit/082a049d2a13b14199a13394dfb1cb8362c0768a )

2년 전만 해도 아직 표준화까지는 멀었다는 것이 망설여졌다. 코어를 추가하기 전에 표준 프로토콜을 원했습니다.

많은 프레임워크가 Observable과 같은 것에 대한 필요성에 동의하고 표준화가 입맛에 맞는 API가 제안되는 지점에 도달하고 있다고 생각합니다. 나는 우리가 그것을 약간 조정해야 할 필요가 있다고 확신하지만 높은 수준의 아키텍처가 작동하는 한 교체 가능하고 결국 수렴해야 합니다.

프라미스에서 일어난 일은 Observable이 겪지 않는 특정 영역에서 API 및 디버깅 스토리가 심각하게 부족했다는 것입니다. Promises가 최소한의 불완전 솔루션을 표준화해야 하는 보다 완벽한 스토리입니다.

의견의 유일한 차이점은 다음과 같습니다. 내가 관찰한 Observables(저항할 수 없었습니다. 죄송합니다)는 Zalgo 잠재력입니다. Observable이 구독에 대한 응답으로 동기적으로 값을 푸시할 수 있는지 여부입니다. 어떤 사람들은 그것에 반대하는 것처럼 보이지만 내가 이해하는 한 React의 Observable 사용은 이것에 의존할 것입니다. 그것에 대해 논평할 수 있습니까?

일반적으로 소비자가 항상 제어할 수 있고 observeOn 와 같은 것으로 항상 비동기를 선택할 수 있기 때문에 Zalgo가 Observable에 문제가 있다는 것을 찾지 못했습니다.

마침내 이에 대한 합의가 이루어지게 되어 기쁩니다. 개인적으로 Observable보다 채널을 선호하지만 Observable이 언어에 추가된다면 더 이상 기다릴 필요가 없다는 데 동의합니다.

즉, 기본 API를 준수하는 비 Observable과 작동할 수 있도록 API를 충분히 열어 두도록 합시다.

나는 Zalgo도 문제라고 생각하지 않습니다. 그러나 Observable을 사용하면 스케줄러를 사용하여 원하는 경우 비동기를 확인할 수 있습니다. 이제 기본 스케줄러는 비동기이므로 필요에 따라 사용할 수 있습니다.

@sebmarkbage 나는 당신이 내 우려의 대부분을 해결했다고 생각하며 이제 이것을 프레임워크에 추가하는 이점을 봅니다. 그러나 this.data 에 대해 언급할 수 있습니까? -- (1) 해당 필드를 props/context/state로 접을 수/있어야 합니까, 아니면 (2) 이름을 바꿀 수 있습니까?

약간 자전거 타기 -y하지만 어쨌든 계속 ... Zalgo 문제는 API 기대 측면에서 중요한지 여부에 관한 것이 아니라 관찰 가능한 상호 운용성 및 구현 용이성 중 하나입니다. Promise 라이브러리 세계를 다른 라이브러리의 Promise를 처리할 때 매우 방어적이어야 하는 성가신 위치에 놓이게 한 Zalgo에 대한 초기 동의가 없습니다. (아래에서 반복되는 내 위의 요점)

...프로미스 라이브러리(사양 불만 라이브러리 포함)가 서로를 신뢰할 수 없는 곳에서는 올바르게 해결되었는지 확인하기 위해 불필요한 래핑 및 방어 작업이 필요합니다.

초기 약속이 모두 비동기 해결을 준수하지 않았기 때문에 라이브러리가 지정되더라도 thenables 가 신뢰할 수 있다고 가정할 수 없어 잠재적 최적화가 중단되는 위치에 있습니다. 이것은 React가 사용할 Observable 구현을 제공하지 않을 것이며(누가 그것을 원하겠습니까?) 여기에서 특히 관련이 있는 것으로 생각됩니다. 우리는 Observable이 제공하는 매우 쉬운 라이브러리에 전적으로 의존할 수 있게 되기까지는 몇 년이 걸릴 것입니다. 상호작용이 중요합니다. @gaearon 의 요점에 더하여 React가 동기화 호출에 의존하고 항상 비동기식으로 지정되어 있는 경우 jquery와 같은 위치가 불량 구현에 갇히게 됩니다.

완전히 동의 해. 오래전에 이 후크를 추가하고 싶었습니다. 2년 전만 해도 아직 표준화까지는 멀었다는 것이 망설여졌다. 코어를 추가하기 전에 표준 프로토콜을 원했습니다.

저도 참석하고 생각하니 기쁘고 확실히 위로가 ​​됩니다. :) 그리고 일반적으로 나는 Promise의 조기 채택이 내가 여기서 논의하는 단점의 가치가 있다고 생각하므로 내 우려를 싫어하거나 승인하지 않는 것으로 받아들이지 마십시오. 나는 이에 대한 일류 API의 전망에 꽤 흥분합니다. 그리고 나는 또한 Observable이 여기에서 얼마나 좋은/가장 합리적인 선택인지 알 수 있습니다.

"Observable의 RxJS 계약이 더 일반적이고 동기 실행을 허용하기 때문에 사용해야 하지만 @jhusain 의 제안이 더 일반적으로 사용되면 대신 해당 계약으로 전환할 것입니다."

컨텍스트를 조금 더 추가하면 됩니다. 비차단 역압을 사용하여 비동기 스트림 처리에 대한 표준을 제공하는 Reactive Streams 이니셔티브(http://www.reactive-streams.org/)가 있습니다. 여기에는 네트워크 프로토콜뿐만 아니라 런타임 환경(JVM 및 JavaScript)을 목표로 하는 노력이 포함됩니다.

현재 주요 구현은 fe Akka Streams 또는 RxJava입니다. RxJ가 이미 동일한 인터페이스, 구독자의 현재 인터페이스를 준수하는지 모르겠습니다.onSubscribe(Subscription s), onNext(T t), onCompleted(), onError(Throwable t)입니다.

@jhusain 의 제안이 무엇인지 더 밝힐 수 있습니까?

React가 이 이니셔티브를 엄격히 준수해야 하는지 모르겠습니다. 필요한 경우 RxJ(준수할 것이라고 가정)를 중간에 넣고 React 인터페이스에 적응하고 RxJ에 대한 역압과 같은 고급 개념을 허용할 수 있기 때문입니다. 많이 적응하지 않아도 됨).

이 이니셔티브에 대한 입장이나 목표가 있습니까?

@vladap 나는 이것이 @jhusain의 언급된 제안이라고 생각합니다.

@jhusain 을 읽었으며 향후 이 사양으로 이동할 동기가 확실하지 않습니다. 특별한 장점이 있나요?

Reactive-streams 사양은 더 큰 지원을 제공하며 이미 버전 1.0에 있습니다. RxJava는 이미 이 사양을 구현하고 있기 때문에 나는 RxJ가 따를 것이라고 가정합니다(그러나 확인하지는 않았습니다).

이 블로그 는 Akka 스트림을 사용하는 몇 가지 예와 함께 인터페이스를 요약합니다.

백엔드와 프론트엔드에서 동일한 인터페이스를 사용하는 것이 몇 가지 이점이 있음을 알 수 있습니다. 주로 둘 다에서 작업하기 때문입니다. 백엔드와 프론트엔드 그룹 간의 협력에 도움이 될 수 있지만 다른 한편으로는 websocket 또는 sse가 스트리밍을 위한 실제 통합 지점이라고 가정합니다.

지금은 www.reactive-streams.org 에서 구현자 목록을 찾을 수 없지만 마지막으로 확인한 것은 다음과 같습니다.

Björn Antonsson – Typesafe Inc.
개빈 비어만 – Oracle Inc.
존 브리스빈 – Pivotal Software Inc.
조지 캠벨 – Netflix, Inc
벤 크리스텐슨 – Netflix, Inc
마티아스 도에니츠 – spray.io
마리우스 에릭센 – Twitter Inc.
팀 폭스 – Red Hat Inc.
Viktor Klang – Typesafe Inc.
Roland Kuhn 박사 – Typesafe Inc.
Doug Lea – SUNY Oswego
스테판 말디니 – Pivotal Software Inc.
Norman Maurer – Red Hat Inc.
Erik Meijer – Applied Duality Inc.
토드 몽고메리 - Kaazing Corp.
패트릭 노드월 – Typesafe Inc.
요하네스 루돌프 – spray.io
Endre Varga – Typesafe Inc.

어쩌면 내가 너무 멀리 갈 수도 있지만 더 큰 맥락이 미래의 결정에 도움이 될 수 있다고 믿습니다.

@vladap 내가 이해하고 github 문제에서 본 것에서 @jhusain 은 이미 그들과 함께 작업하고 있으므로 그렇게 많은 문제가 없을 것이라고 생각합니다.
인터페이스 관점에서 다른 github 문제 및 기타 사양 문서에서도 파악할 수 있는 것에서 관찰자는 다음과 같은 생성기 인터페이스를 확실히 존중할 것입니다.

{
  next(value),
  throw(e),
  return(v)
}

반응에 대해 안전해야 하는 인터페이스를 존중하는 단일 '구독' 방법으로 매우 기본적인 관찰 가능 항목을 구현하기만 하면 됩니다.

같은 기능을 가진 다른 이름처럼 보이지만 그런 의미에서는 괜찮습니다. 아마도 사양에서와 같은 이름을 선호할 것이지만 결국에는 이러한 방법이 동일하게 수행되는 한 크게 신경 쓰지 않습니다.

onSubscribe()에 해당하는 누락을 평가할 수 없습니다. 내가 언급한 블로그에서 저자는 그것이 배압을 제어하는 ​​핵심이라고 말합니다. 다른 사용 사례가 있는지 모르겠습니다. 이것으로부터 나는 React가 배압 제어에 신경 쓰지 않거나 그것에 대한 다른 전략이 있다고 가정합니다. 그것은 복잡한 일이므로 React 관심사가 아님을 이해합니다.

전략이 선을 따라 있다는 것을 올바르게 이해하고 있습니까? 앱이 복잡하고 역압 문제가 발생할 수 있으며 RxJS와 같은 문제를 해결하기 위해 그 사이에 무언가를 사용하거나 React 구성 요소를 fe websocket에 직접 연결하면 앱이 간단하고 업데이트가 느리기 때문에 역압 문제가 없습니다.

향후 ECMAScript에 대해 제안된 관찰 가능한 인터페이스는 어디에서 찾을 수 있습니까? 이미 있는 경우.

현재 제안은 여기에서 찾을 수 있습니다:

https://github.com/jhusain/asyncgenerator

JH

2015년 5월 7일 오전 2시 32분에 vladap [email protected] 에서 다음과 같이 썼습니다.

향후 ECMAScript에 대해 제안된 관찰 가능한 인터페이스는 어디에서 찾을 수 있습니까? 이미 있는 경우.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

Reactive Streams Proposal(RSP)은 역압을 처리하는 Observable을 도입하기 때문에 TC-39 제안보다 더 나아갑니다. RSP Observable은 역압을 존중하면서 네트워크를 통해 스트림을 효율적으로 전송하도록 최적화되었습니다. 이것은 부분적으로 RxJava에서 수행된 작업을 기반으로 하며, 이는 매우 인상적인 엔지니어링 부분입니다(전체 공개: Netflix의 동료 Ben Christensen이 설계했습니다).

보다 원시적인 Observable 유형을 표준화하기로 결정한 주된 이유는 주의입니다. 더 원시적인 Observable은 ES2015 Iterable 계약의 이중으로, 유형이 적어도 ES2015에서 이미 표준화된 유형만큼 유연하다는 귀중한 보장을 제공합니다. 또한 JS에는 배압이 필요하지 않은 Observable에 대한 다양한 사용 사례가 있습니다. 브라우저에서 DOM은 푸시 스트림의 가장 일반적인 싱크이며 버퍼처럼 효과적으로 작동합니다. RSP 유형이 더 복잡하다는 점을 감안할 때 우리의 접근 방식은 더 원시적인 유형을 먼저 표준화한 다음 나중에 더 고급 유형을 구현할 여지를 남겨두는 것입니다. 이상적으로는 사용자 영역에서 검증될 때까지 기다려야 합니다.

참고로 RxJS는 현재 RSP Observable을 구현할 계획이 없습니다.

JH

2015년 5월 7일 오전 2시 30분에 vladap [email protected] 에서 다음과 같이 썼습니다.

같은 기능을 가진 다른 이름처럼 보이지만 그런 의미에서는 괜찮습니다. 아마도 사양에서와 같은 이름을 선호할 것이지만 결국에는 이러한 방법이 동일하게 수행되는 한 크게 신경 쓰지 않습니다.

onSubscribe()에 해당하는 누락을 평가할 수 없습니다. 내가 언급한 블로그에서 저자는 그것이 배압을 제어하는 ​​핵심이라고 말합니다. 다른 사용 사례가 있는지 모르겠습니다. 이것으로부터 나는 React가 배압 제어에 신경 쓰지 않거나 그것에 대한 다른 전략이 있다고 가정합니다. 그것은 복잡한 일이므로 React 관심사가 아님을 이해합니다.

전략이 선을 따라 있다는 것을 올바르게 이해하고 있습니까? 앱이 복잡하고 역압 문제가 발생할 수 있으며 RxJS와 같은 문제를 해결하기 위해 그 사이에 무언가를 사용하거나 React 구성 요소를 fe websocket에 직접 연결하면 앱이 간단하고 업데이트가 느리기 때문에 역압 문제가 없습니다.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

귀중한 세부사항을 위한 많은 감사합니다. 그것은 많은 의미가 있습니다.

@gaearon 복사했습니다. ES6 클래스와 함께 ParseReact를 사용하고 싶었기 때문에 mixin의 관찰 API를 고차 구성 요소로 다시 구현해야 했습니다.

https://gist.github.com/amccloud/d60aa92797b932f72649 (아래 사용법)

• 나는 관찰이 구성 요소에 정의되거나 데코레이터로 전달되도록 허용합니다. (나는 둘을 합칠 수도 있다)
• 옵저버블을 소품으로 병합합니다(this.data 또는 this.props.data 없음).

@aaronshaf @gaearon 일등석 으로 만드는 이점은 다음과 같습니다.

1) props 네임스페이스를 잡아먹지 않습니다. 예를 들어 고차 컴포넌트는 다른 용도로 사용할 수 없는 props 객체의 데이터와 같은 이름을 요구할 필요가 없습니다. 여러 개의 고차 구성 요소를 연결하면 더 많은 이름을 계속 사용하므로 이제 이러한 이름을 고유하게 유지하는 방법을 찾아야 합니다. 이미 작성되었을 수 있는 항목을 작성하고 있는데 이제 이름 충돌이 발생하면 어떻게 됩니까?

게다가, 고차 구성 요소에 대한 모범 사례는 래핑된 구성 요소의 계약을 변경하지 않는 것이어야 한다고 생각합니다. 즉, 개념적으로 아웃과 동일한 소품이어야 합니다. 그렇지 않으면 소비자가 수신한 것과 완전히 다른 props 세트를 제공할 때 사용하고 디버그하는 것이 혼란스럽습니다.

HOC 대신 일반 구성 요소가 될 수 있습니다.

import Observe from 'react/addons/Observe';

class Foo {
  render() {
    return (
      <Observe
        render={this.renderData}
        resources={{
          myContent: xhr(this.props.url)
        }} />
    );
  }

  renderData({ myContent }) {
    if (myContent === null) return <div>Loading...</div>;
    return <div>{myContent}</div>;
  }
}

render 소품으로 전달된 함수를 제어하기 때문에 이름이 충돌할 방법이 없습니다. 반면에 소유자의 상태를 오염시키지 않습니다.

여기서 내가 놓치고 있는 것이 무엇입니까?

Observe 구성 요소가 props에서 Observables를 가져온 경우 이것은 훨씬 덜 장황할 수 있습니다.

render() {
  return (
    <Observe myContent={Observable.fetch(this.props.url)}
             render={this.renderData} />
  );
}

renderData({ myContent }) {
  if (myContent === null) return <div>Loading...</div>;
  return <div>{myContent}</div>;
}

이것에 대한 좋은 점은 render 에 전혀 들어가지 않기 때문에 shouldComponentUpdate 가 false를 반환하면 재구독을 피할 수 있다는 것입니다.

마지막으로 Observe 구성 요소로 래핑하는 render 데코레이터를 작성할 수 있습니다.

@observe(function (props, state, context) {
  myContent: Observable.fetch(props.url)
})
render({ myContent }) {
  if (myContent === null) return <div>Loading...</div>;
  return <div>{myContent}</div>;
}

데이터 가져오기 논리를 삽입하는 대신 render 를 순수한 렌더링 함수로 유지하는 것을 선호합니다.
제 생각에는 초기 제안이 좋은 것 같습니다. 상태가 rx-react 로 작동하는 방식과 매우 유사하며 매우 일관성 있는 것처럼 보이는 데이터 가져오기 논리에서 상태 관리를 분리할 수 있습니다.

나를 괴롭히는 유일한 것은 하나의 옵저버블 대신 옵저버블의 맵을 사용하는 것입니다. 사용자에게 옵저버블 구성 방법을 선택할 수 있는 가능성을 제공하지 않지만 이것은 사소한 문제이기 때문입니다.

실제로 데이터 가져오기 논리를 주입하는 것이 아니라 일부 입력을 저장하는 것입니다. <Observe /> 구성 요소만 렌더링하는 위의 버전으로 설탕을 제거합니다. 상태 저장 구성 요소를 렌더링하는 것은 드문 일이 아니므로 render 가 지금보다 덜 순수하다고 생각하지 않습니다.

나는 #3858의 최선과 이 제안을 결합하려고 노력했다.

모든 HOC 접근 방식에서 이점은 명시적이지만 @sebmarkbage에 의해 단점이 설명됩니다 . props 이름은 어느 시점에서 충돌할 수 있습니다.

현재 제안에서 이점은 명시적이지만 부정적인 측면은 더 복잡한 수명 주기와 더 큰 핵심 구성 요소 API 표면입니다.

#3858에서 이점은 "memoized render" 종속성을 렌더링 자체와 함께 배치하는 것입니다(다른 곳에서는 사용되지 않으므로 의미가 있음). 그러나 저는 "look sync but is async" 에 대해 우려하고 있으며 어떻게 하는지 이해하지 못합니다. this 에 너무 의존하는 경우 불변 모델로 작업할 수 있습니다 . 또한 수동으로 변경 사항을 추적하고 데이터 소스를 React에 연결하는 것(또는 React와 함께 작동하도록 래핑하는 것)에 대해 쉽게 추론할 수 없기 때문에 React-was-eas-to-reason-about 방식으로 저를 잘못 문지릅니다. 나는 성능을 발휘하고 상용구를 줄이는 것 모두를 구현해야 한다는 압력이 있다는 것을 이해합니다.

내 제안에서 나는 코로케이션과 명시성을 유지하고 있지만:

• <Observe /> (또는 <Observe /> 로 render를 래핑하는 observe() 데코레이터)는 애드온일 뿐이며 React 코어에 _any_ 변경 사항을 제안하지 않습니다.
• 누구나 자신의 사용 사례에 대한 자체 관찰 논리를 구현할 수 있습니다. 원하는 경우 하나의 관찰 가능 항목만 사용하는 자신만의 <Observe /> 를 가질 수 있습니다. 데코레이터를 사용할 수도 있고 사용하지 않을 수도 있습니다.
• 구성 요소 수명 주기는 동일하게 유지됩니다.
• 데이터가 매개변수로 전달되기 때문에 소품 충돌이 없습니다.
• 우리는 우리가 가지고 있는 도구로 문제를 해결함으로써 도그푸딩을 하고 있습니다.
• 상용구를 줄이기 위해 새로운 핵심 개념을 도입하는 대신 상용구 축소 도구(데코레이터)를 사용합니다.

여기에서 훌륭한 토론과 작업, 많은 존경을 표합니다. :)

나는 이것이 그것을 핵심으로 만들 가치가 없다는 데 동의합니다. 아마도 추가 기능은 사람들이 더 완전히 커밋하기 전에 수렴하고 표준화하려고 시도할 수 있는 충분한 견인력을 이 제안에 제공합니다. 즉, 나는 이 제안이 미니멀리즘을 위해 https://github.com/facebook/react/issues/3858 및 https://github.com/facebook/react/pull/3920 보다 낫다고 생각합니다.

이것은 내가 사이드 프로젝트에서 사용하고 있는 것입니다(그래서 소금 알갱이) - @elierotenberg 의 멋진 작업과 유사하지만 이 앱이 React에서 100%가 아니며 상호

CoffeeScript와 믹스인에 대비하거나 원하는 경우 이것이 ES6처럼 보일 때까지 계속 눈을 가늘게 뜨고 있습니다. :)

_ = require 'lodash'

module.exports = DeclareNeedsMixin = 
  componentDidMount: ->
    <strong i="12">@needsConsumerId</strong> = _.uniqueId @constructor.displayName
    <strong i="13">@sinkNeeds</strong> <strong i="14">@props</strong>, <strong i="15">@state</strong>

  componentWillUpdate: (nextProps, nextState) ->
    <strong i="16">@sinkNeeds</strong> nextProps, nextState

  componentWillUnmount: ->
    @props.flux.declareNeeds <strong i="17">@needsConsumerId</strong>, []

  sinkNeeds: (props, state) ->
    if not @declareNeeds?
      return console.warn 'Missing method required for DeclareNeedsMixin: `declareNeeds`', @

    needs = <strong i="18">@declareNeeds</strong> props, state
    props.flux.declareNeeds <strong i="19">@needsConsumerId</strong>, needs

  # Intended to be overridden by the host class.
  # Returns a set of facts, stored as an array.
  # Yes, immutable data is awesome, that's not the point here though. :)
  # Facts are serializable data, just values.
  # declareNeeds: (props, state) ->
  #   []

그리고 다음과 같이 사용합니다.

module.exports = EmailThreads = React.createClass
  displayName: 'EmailThreads'
  mixins: [DeclareNeedsMixin]

  propTypes:
    flux: PropTypes.flux.isRequired

  declareNeeds: (props, state) ->
    [Needs.GmailData.myThreads({ messages: 20 })]

  ...

따라서 declareNeeds 는 이 구성 요소에 필요한 설명에 대한 props 및 state의 단방향 함수입니다. 실제 구현에서 @props.flux.declareNeeds 의 수신측은 최상위 구성 요소에 설정되어 이러한 요구 사항을 ProcessSink 개체로 흡수합니다. 원하는 대로 일괄 처리하고 동일한 flux 를 공유하는 구성 요소에서 needs 중복을 제거한 다음 이러한 요구 사항(예: 소켓 연결 또는 HTTP 요청 만들기)을 충족하기 위해 부작용을 수행합니다. 더 이상 필요하지 않은 구성 요소가 없을 때 소켓 연결과 같은 상태 저장 항목을 정리하기 위해 참조 카운팅을 사용합니다.

데이터는 소켓 이벤트 및 요청과 같은 상태 저장 비트에서 디스패처로(그런 다음 저장소 또는 어디든지) 필요를 충족시키기 위해 구성 요소로 다시 흐릅니다. 이것은 동기가 아니므로 데이터를 아직 사용할 수 없을 때 모든 구성 요소가 렌더링을 처리합니다.

나는 사용자 공간에서 이러한 종류의 솔루션을 탐색하는 것이 가능하며 현재 API가 그런 종류의 실험을 정말 잘 수행하고 있다는 또 다른 목소리로 이것을 공유하고 있습니다. 서로 다른 접근 방식 간의 상호 운용성을 지원하기 위해 코어가 취할 수 있는 최소 단계의 관점에서 @elierotenberg 가 이를 못 박았다고 생각합니다.

어쨌든 탑재된 React 계층 구조 외부에서 React 구성 요소 인스턴스 수명 주기를 유지 관리하는 것을 노출하고 지원하는 것이 도움이 될 것입니다.

상태 비저장 접근 방식의 경우 비동기 데이터 가져오기가 상태 저장이므로 일부 구성 요소의 상태에 보류/완료/실패 상태를 저장하는 것이 적절합니다.

@elierotenberg 와 @andrewimm 은 일류 오류 처리에 대해 훌륭한 지적을 했습니다. @sebmarkbage 최소한의 interop 지점에 대한 본능이 onError 및 onCompleted 값에 액세스하는 방법에 대한 똑같이 간단한 이야기가 있어야 합니다. this.observed 중 하나의 마지막 값을 보유하는 경우에도 마찬가지입니다 next/error/completed like { next: "foo" } . 관찰 가능한 계약을 일급 기능으로 지원하지 않고, 나는 이 제안이 삭감되는 것에 대해 약간 회의적입니다.

그리고 이것은 인터넷이고 여기에서 처음으로 소리를 낸 것 중 하나이기 때문에 React 문제 피드는 훌륭한 작업과 아이디어에 대한 최고의 읽기이자 만능 소스입니다. :+1:

나에게 바인딩과 같은 냄새가 난다.

이것이 현재 제안/구현과 어떤 관련이 있는지 확실하지 않지만 구성 및 고차 조작을 활성화하는 것이 실제로 데이터 종속성 추적의 핵심 기능이라는 것을 알았습니다. 특히 반응성 데이터 소스(플럭스, 플럭스 유선 또는 업데이트를 제공하는 것 이외의 모든 것).

react-nexus@^3.4.0 를 사용하여 다음 예를 살펴보세요.

// the result from this query...
@component({
  users: ['remote://users', {}]
})
// is injected here...
@component(({ users }) =>
  users.mapEntries(([userId, user]) =>
    [`user:${userId}`, [`remote://users/${userId}/profile`, {}]]
  ).toObject()
))
class Users extends React.Component {
  // ... this component will receive all the users,
  // and their updates.
}

대체로 컴포넌트 API에 데이터 바인딩이 있어야 하는지 궁금합니다. 고차원 구성 요소를 반환하는 데코레이터는 구성 요소 메서드 네임스페이스를 오염시키지 않고 데이터 바인딩을 표현하는 아주 좋은 방법을 제공하는 것 같습니다.

그러나 @sebmarkbage 가 언급했듯이 대신 props 네임스페이스가 오염될 위험이 있습니다. 지금은 소품 변환기 데코레이터( react-transform-props )를 사용하여 소품을 내부 구성 요소로 전달하기 전에 정리하거나 이름을 변경하고 있습니다. 더 일반적이고 이름 충돌의 위험이 증가합니다.
기호가 속성 키임을 사용하여 해결할 수 있습니까? propTypes 검사가 Symbol -keyed 소품을 지원합니까? JSX는 계산된 인라인 소품 키를 지원합니까(항상 계산된 속성 + 개체 확산을 사용할 수 있음)?

이것이 주제에서 조금 벗어나면 죄송하지만 구성 요소 수준에서 데이터 deps를 표현하기 위한 적절한 추상화/API를 여전히 찾아야 하는 것 같습니다.

내 2센트

나는 시간이 지남에 따라 변하는 가치에 대한 'children as a function' 패턴으로 많은 시간을 보냈습니다. @elierotenberg가 처음으로 생각해

<Springs to={{x: 20, y: 30}} tension={30}>
  {val => <div style={{left: val.x, top: val.y}}>moving pictures</div>}
</Springs>

소품 충돌이 없고 소유자 상태를 사용하지 않습니다. 또한 여러 스프링을 중첩할 수 있으며 반응은 모든 하드 비트를 관리합니다. 이러한 '관측 가능 항목'(하!)은 onError , onComplete 및 기타 소품(graphql 쿼리?)도 허용할 수 있습니다.

'플럭스'에 대한 대략적인 스케치 시도

<Store 
  initial={0}
  reduce={(state, action) => action.type === 'click'? state+1 : state} 
  action={{/* assume this comes as a prop from a 'Dispatcher' up somewhere */}}> 
    {state => <div onClick={() => dispatch({type: 'click'})}> clicked {state} times</div>}
</Store>

우리는 Asana에서 _render callbacks_이라고 부르는 이 패턴을 사용했지만 궁극적으로 이 패턴에서 멀어지고 있습니다.

장점

• 소품 충돌 가능성이 없습니다.
• 쉬운의 저자로 모두를 구현하는 StoreComponent 와의 사용자 StoreComponent

단점

• shouldComponentUpdate 는 렌더 콜백이 상태 이상으로 닫힐 수 있으므로 구현하기가 매우 어렵습니다. A -> Store -> B 의 구성 요소 트리가 있다고 상상해보십시오. A 에는 B 대한 props로 렌더링 콜백 중에 액세스되는 상태의 카운터가 있습니다. 카운터로 인해 A 업데이트되고 Store 가 업데이트되지 않으면 B 에는 오래된 버전의 카운터가 있습니다. 결과적으로 우리는 항상 스토어를 업데이트해야 했습니다.
• 구성 요소를 개별적으로 테스트하는 것은 매우 어려워졌습니다. 필연적으로 개발자는 렌더링할 구성 요소에 대한 렌더링 콜백에 복잡한 논리를 넣고 논리를 테스트하고 싶었습니다. 이를 수행하는 자연스러운 방법은 전체 트리를 렌더링하고 저장소 구성 요소를 _통해_ 테스트하는 것입니다. 이로 인해 얕은 렌더러를 사용할 수 없었습니다.

이제 StoreComponent 가 ReactElement 를 사용하는 모델로 이동하고 저장소가 새 데이터를 수신하면 저장소가 특정 소품을 재정의하는 ReactElement를 복제합니다. Component 생성자와 소품을 사용하는 것과 같이 이 패턴을 수행하는 방법에는 여러 가지가 있습니다. TypeScript에서 모델링하기가 가장 쉽기 때문에 이 접근 방식을 사용했습니다.

훌륭한 점, '옆으로' 요구 사항을 위반하지 않고는 방법을 생각할 수 없습니다.

@threepointone https://github.com/reactjs/react-future/pull/28 에 전원을 공급하기 위한 구현 제안 중 하나처럼 들립니다.

귀하의 예에서 @pspeter3 , Store를 항상 업데이트하도록 만드는 데 심각한 단점이 있습니까 / shouldComponentUpdate: ()=> true ? 어쨌든 '자식'이 체인에 Store 없이 렌더링되었을 것이라고 생각합니다. 시간 내 줘서 고마워!

@threepointone 그것이 바로 우리가 경계를 위해 한 일입니다. 그 영향이 정확히 무엇인지는 불분명했지만, 팀원들의 퍼포먼스 걱정이 있었다. 테스트의 어려움과 결합된 걱정은 React.cloneElement(this.props.child, {data: this.state.data}) 를 사용하도록 전환했습니다.

@pspeter3 테스트 각도가 확실히 문제입니다. ShallowRenderer가 '렌더 콜백'을 인식했다면 어떻게 될까요? 도움이 될까요?

Ps- '콜백 렌더링':thumbs_up:

@sebmarkbage es-observable 에 대한 현재 논의는 subscribe 가 비동기를 보장하고 [Symbol.observer] 메서드가 동기식으로 바로 가기 및 구독에 제공된다는 것입니다. 현재 논의 중이다.

동기 구독에 찬성하여 위에서 언급한 사용 사례와 함께 이 티켓 에 참여했지만 거기에 추가할 내용이 있는지 몰랐습니다.

나는 여기에 있는 아이디어가 외부 상태를 처리하기 위한 매우 깨끗한 패턴이라고 생각하지만 조금 가지고 놀고 난 후에는 HOC 접근 방식을 선호합니다.

- 또한 @gaearon 난 당신 HOC 정적 사용하여, 위의 비트 단순화 ComposedComponent.observe 하고 사용하여 this.state 보다는 this.state.data - https://gist.github.com/tgriesser/d5d80ade6f895c28e659

제안된 es7 데코레이터로 정말 멋지게 보입니다.

<strong i="20">@observing</strong>
class Foo extends Component {
  static observe(props, context) {
    return {
      myContent: xhr(props.url)
    };
  }
  render() {
    var myContent = this.props.data.myContent;
    return <div>{myContent}</div>;
  }
}

클래스 데코레이터는 data 에 대한 getter를 추가하여 원래 제안된 API(관찰 가능한 구독에 영향을 미치는 로컬 상태를 뺀 값으로 동의합니다. 주변 소음이 훨씬 적습니다. 구독/구독 취소).

동기 구독이 없으면 큰 문제가 될 수 있습니다.

"상태 문제"와 "측면 데이터 로드"(파생 데이터)를 일관된 방식으로 해결하는 방법을 알고 있다고 생각합니다. stateless "React-way"로 만듭니다. 어떤 시점에서든 상태 일관성을 유지하는 방법을 찾았고 UI = React(state) 패턴에 맞습니다. 나는 그것을 완전히 방탄으로 만들고, 더 많은 예를 추가하고, 좋은 프레젠테이션을 할 수 없을 것입니다. https://github.com/AlexeyFrolov/slt . 반면에 잘 테스트되었으며 프로덕션 프로젝트에서 반복적으로 사용하고 있습니다. 영리한 마음의 기여를 환영합니다.

안녕하세요 여러분,

우리 회사에서 반년 전에 이 제안으로 해결된 것과 동일한 문제에 직면했기 때문에 전에 이 스레드를 우연히 발견하지 않았다는 것이 재미있습니다.
우리는 대규모 프로젝트에 React를 사용하기 시작했습니다(매우 순환적인 데이터가 포함된 Microsoft Visio의 복잡성을 가진 편집기를 생각해 보세요). 바닐라 반응 수가 우리의 성능 요구 사항을 따라가지 못합니다.
그리고 플럭스는 많은 양의 상용구와 모든 구독의 오류 경향으로 인해 우리에게 약간의 실패였습니다. 그래서 우리는 관찰 가능한 데이터 구조도 필요하다는 것을 알아냈습니다.

사용할 준비가 된 사용 가능한 것을 찾을 수 없었기 때문에 녹아웃 옵저버블(특히: 자동 구독)의 원칙에 따라 자체 옵저버블 라이브러리를 구축했습니다.
이것은 실제로 React 구성 요소의 현재 수명 주기에 매우 깔끔하게 들어맞으며 이상한 해킹이나 자식 렌더링 콜백도 필요하지 않았습니다(아래에서 사용되는 ObserverMixin은 약 10loc임).
이것은 우리의 DX를 많이 향상시켰고 우리 팀을 위해 아주 잘 작동했기 때문에 우리는 그것을 오픈 소스 로 게시하기로 결정했습니다. 그 동안 이것은 전투에서 입증되었고(예를 들어 ES7 관찰 가능한 어레이 폴리필을 제공함) 고도로 최적화되었습니다.
다음은 짧은 타이머 예제입니다( JSFiddle 로도 사용 가능). IMHO DX는 이보다 더 좋을 수 없습니다... :안도:

var store = {};
// add observable properties to the store
mobservable.props(store, {
    timer: 0
});

// of course, this could be put flux-style in dispatchable actions, but this is just to demo Model -> View
function resetTimer() {
    store.timer = 0;
}

setInterval(function() {
    store.timer += 1;
}, 1000);

var TimerView = React.createClass({
    // This component is actually an observer of all store properties that are accessed during the last rendering
    // so there is no need to declare any data use, nor is there (seemingly) any state in this component
    // the combination of mobservable.props and ObserverMixin does all the magic for us.
    // UI updates are nowhere forced, but all views (un)subscribe to their data automatically
    mixins: [mobservable.ObserverMixin],

    render: function() {
        return (<span>Seconds passed: {this.props.store.timer}</span>);
    }
});

var TimerApp = React.createClass({
    render: function() {
        var now = new Date(); // just to demonstrate that TimerView updates independently of TimerApp
        return (<div>
            <div>Started rendering at: {now.toString()}</div>
            <TimerView {...this.props} />
            <br/><button onClick={resetTimer}>Reset timer</button>
        </div>);
    }
});

// pass in the store to the component tree (you could also access it directly through global vars, whatever suits your style)
React.render(<TimerApp store={store} />, document.body);

이 접근 방식에 대한 자세한 내용은 이 블로그 를 참조하십시오. BTW, ES6 클래스를 사용하는 사람들을 위해 데코레이터 및/또는 컨테이너가 lib 에 추가되는지 확인하겠습니다.

슬프게도 나는 react-europe 전에 이 스레드를 보지 못했습니다. 그러나 영감을 주는 이야기를 해주셔서 감사합니다! :+1: 저는 특히 GraphQL의 추상화와 Redux 이면의 사고 작업을 좋아했습니다. :)

@mweststrate 저는 커뮤니티가 궁극적으로 "Observable"과 "Immutable data" 솔루션 중에서 선택해야 할 필요가 있다고 생각합니다. 하나의 솔루션(https://github.com/AlexeyFrolov/slt/issues/4)에서 두 접근 방식의 장점을 모두 갖기 위해 어떤 식으로든 혼합해야 할 수도 있습니다. 내 솔루션에서는 어떤 시점에서든 상태의 일관성에 중점을 둔 "불변 데이터" 접근 방식을 구현했습니다. Observable과 Generator도 지원할 계획입니다. 이것은 "파생" 또는 "보충" 데이터(예: 페이지 본문, 자산, 추천, 댓글, 좋아요)를 가져오고 앱 상태의 일관성을 유지하기 위해 를 사용하는 규칙의 예입니다.

https://github.com/AlexeyFrolov/slt#rules -예제

위치 헤더로 API 리디렉션을 처리하는 방법을 보여주는 복잡한 실제(내 프로덕션 코드) 예제입니다.

import r from "superagent-bluebird-promise";
import router from "./router";

export default {
    "request": function (req)  {
        let route = router.match(req.url);
        let session = req.session;
        route.url = req.url;
        return this
            .set("route", route)
            .set("session", req.session);
    },
    "route": {
        deps: ["request"],
        set: function (route, request) {
            let {name, params: { id }} = route;
            if (name === "login") {
                return this;
            }
            let url = router.url({name, params: {id}});
            let method = request.method ? request.method.toLowerCase() : "get";
            let req = r[method]("http://example.com/api/" + url);
            if (~["post", "put"].indexOf(method)) {
                req.send(request.body);
            }
            return req.then((resp) => {
                let ctx = this.ctx;
                let path = url.substr(1).replace("/", ".");
                if (!resp.body) {
                    let location = resp.headers.location;
                    if (location) {
                        ctx.set("request", {
                            method: "GET",
                            url: location.replace('/api', '')
                        });
                    }
                } else {
                    ctx.set(path, resp.body);
                }
                return ctx.commit();
            });
        }
    }
}

나머지에서는 React에 직접 바인딩하지 않는다는 점을 제외하고는 귀하와 동일한 접근 방식입니다(제 경우에는 필요하지 않음). 공동의 목표를 달성하기 위해서는 어떻게든 힘을 모아야 한다고 생각합니다.

고려하기 어려운 많은 경우가 있기 때문에 나쁜 생각이라고 생각합니다.

위의 의견에서 최종 사용자가 "데이터가 있는" 구성 요소를 만들려고 할 때마다 생각해야 하는 가능한 범위를 나열할 수 있습니다.

• 서버 측 렌더링
• .state 및 .data 초기화
• .context , .props , .state 및 .observe 얽힘
• 비동기 렌더링

나는 이 제안이 오류가 발생하기 쉽고 불안정하며 디버그하기 어려운 구성 요소로 이어질 것이라고 생각합니다.

@glenjamin connect 및 disconnect 수명 주기 후크가 제안한 내용에 동의합니다.

주제에서 벗어난 것이라면 사과드립니다(정확히 말할 수 없음). 그러나 다음은 구성 요소 트리와 상호 작용하기 위해 API를 노출하는 것이 이 문제에 접근하는 흥미로운 방법이라고 생각하는 이유에 대한 예입니다. https://github.com/kevinrobinson/redux/blob/feature/loggit-todomvc/examples/loggit -todomvc/loggit/renderers/precompute_react_renderer.js#L72

이 방법은 트리를 걷는 저의 해커입니다. 따라서 제 질문은 이런 종류의 작업을 수행하기 위한 공개 API를 사용하는 것이 "가로 데이터 로드"에서 혁신을 가능하게 하는 방법입니다. 하향식으로 작업": https://github.com/kevinrobinson/redux/blob/feature/loggit-todomvc/examples/loggit-todomvc/loggit/react_interpreter.js#L8

그러나 여기에 구성 요소 트리와 상호 작용하기 위해 API를 노출하는 것이 이 문제에 접근하는 흥미로운 방법이 될 것이라고 생각하는 이유에 대한 예가 있습니다.

@swannodette가 ReactConf에서 이에 대해 이야기했다고 믿습니다. Om Next가 하는 건지 궁금합니다.

네, 첫 ReactConf에서 같은 것을 제안했습니다. 최신 Om.next를 보거나 EuroClojure 이야기를 들어본 적이 없지만 이전에는 Om이 사용자가 이를 수행하기 위해 구축해야 했던 자체 구조를 사용했습니다.

이 방법은 트리를 걷는 저의 해커입니다. 따라서 제 질문은 이런 종류의 작업을 수행하기 위한 공개 API를 사용하는 것이 "가로 데이터 로드"에서 혁신을 가능하게 하는 방법입니다. 하향식으로 작업"

이것은 테스트 유틸리티에서 볼 수 있는 얕은 렌더링과 대략 동일하다고 생각합니다. ReactEurope 에서 @sebmarkbage에 대한 DOM 및 String 렌더링의 피어로서 이것을 일급 API로 만드는 것에 대해 언급했습니다. 0.14 변경 사항은 이를 위한 길을 멋지게 포장하는 것 같습니다.

초기 반응은 약간 낮은 수준일 수 있다는 것입니다. 그러나 확장 가능한 웹 항목과 유사한 방식으로 사용자 공간에서 실험하기가 더 쉬울 것이라고 생각합니다.

동의합니다. 트리를 가져오기 위해 렌더링할 수 있는 방법이 있다면 트리를 탐색하고 필요한 모든 데이터를 찾아 전달할 수 있다는 점에 동의합니다.

전체 가상 DOM 트리에 액세스하는 것은 완전히 별개의 문제로 취급되더라도 액세스하고 싶은 놀랍도록 강력하고 유용한 기능입니다.
React가 0.14 이후로 나아가는 길을 고려할 때 그것이 의미가 있다고 생각합니다.

옵저버블의 복잡성을 감안할 때, 이 스레드의 훌륭한 여러분이 Meteor의 반응 데이터 구현을 살펴보기를 겸손하게 제안합니다: https://github.com/meteor/meteor/wiki/Tracker-Manual. React와 조정하려면 componentWillMount 메서드에서 다음과 같이 문자 그대로 3-5줄의 코드가 필요합니다.

  componentWillMount() {
    if (typeof this.getState === 'function') {
      Tracker.autorun(() => {
        // Assuming this.getState() calls some functions that return
        // reactive data sources
        this.setState(this.getState());
      });
    }
  }

Tracker(별도의 라이브러리로 쉽게 추출됨)가 React에서 관찰 가능한 지원의 필요성을 제거하는지 모르겠지만 확실히 그렇게 보입니다.

MOBservable은 관찰 가능한 값이 변경되면 구성 요소를 옆으로 새로 고치는 매우 유사한 패턴을 따르므로 현재 수명 주기 메서드 + 데코레이터는 타사 라이브러리가 이러한 종류의 패턴을 표현하고 타사 데이터 소스 개념을 표현하기에 충분한 유연성을 제공하는 것으로 보입니다. 복잡한 일만 할 것입니다.

    componentWillMount: function() {
        var baseRender = this.render;
        this.render = function() {
            if (this._watchDisposer)
                this._watchDisposer();
            var[rendering, disposer] = mobservableStatic.watch(() => baseRender.call(this), () => {
                    this.forceUpdate();
            });
            this._watchDisposer = disposer;
            return rendering;
        }
    },

@Mitranim 동의합니다. 정말 잘 읽었습니다. 찾아주셔서 감사합니다! 그것은 효과적으로 https://github.com/facebook/react/pull/3920 이 제안하는 것입니다.

우리는 어떤 제안이 더 나은지 결정하지 못했습니다. 둘 다 사용해 본 결과 반응형 프로그래밍(링크한 대로, https://github.com/meteor/meteor/wiki/Tracker-Manual)이 가야 할 길이라고 대부분 확신하지만 합의에 도달하지 못했고 우리는 여전히 무엇이 가장 합리적인지 알아내려고 노력하고 있으므로 피드백을 환영합니다.

@Mitranim @jimfb 저는 몇 년 동안 Meteor의 열렬한 팬이었습니다. Tracker는 정말 멋지고 매우 매력적입니다. 매우 간단한 버전의 트래커가 작동하는 방식을 보여주는 프레젠테이션을 만들었습니다.

https://github.com/ccorcos/meteor-track/blob/master/client/main.js

그리고 Tracker로 관찰 가능한 스트림 라이브러리도 만들었습니다.

https://github.com/ccorcos/meteor-tracker-streams

하지만 Blaze 대신 React를 사용하는 것으로 완전히 전환하면서 Tracker가 너무 복잡하고 때로는 간단한 publish/subsrcribe/onChange 메서드가 100배 더 쉽다는 것을 깨달았습니다.

또한, 모든 함수형 프로그래밍 팬을 위해 Tracker에는 99%의 경우에 이해가 가는 몇 가지 부작용이 있지만 때로는 문제가 발생합니다. 다음은 React 구성 요소에서 보이는 방법입니다.

componentWillMount: ->
  <strong i="15">@c</strong> = Tracker.autorun =>
    @setState({loading: true})
    Meteor.subscribe 'users', => @setState({loading: false})
    Tracker.autorun =>
      @setState({users: Users.find({}, {sort:{name:-1}}).fetch()})
componentWillUnmount: ->
  @c.stop()

부작용에 대한 제 요점은 c.stop() 구독과 내부 자동 실행도 중지된다는 것입니다.

@ccorcos 예, https://github.com/facebook/react/pull/3920에서 모든 부작용은 완전히 React 내부에 있습니다. 사실, React 코어는 돌연변이를 수행하지 않는 완전히 불변/기능적인 방식으로 그것들을 구현할 수 있습니다. 그러나 부작용은 외부에서 볼 수 없기 때문에 구현 세부 사항입니다.

흥미롭습니다... 그렇다면 그냥 onChange 콜백을 사용하지 않는 이유는 무엇입니까? 나는 그것들이 가장 호환되는 것을 발견했습니다. Meteor(Tracker), RxJS, Highland.js 등을 사용하든 상관없이 이벤트 콜백으로 항상 간단하게 통합할 수 있습니다. React 고차 구성 요소와 동일합니다.

Redux가 마음에 드는 점은 이 논리를 프레임워크에서 제외하고 React 구성 요소를 순수한 기능으로 유지한다는 것입니다.

@ccorcos 주요 문제는 구성 요소 인스턴스가 파괴될 때 모든 "구독"을 정리해야 한다는 것입니다. 구성 요소 작성자는 종종 이 정리를 잊어버려 메모리 누수가 발생합니다. 우리는 그것이 자동이기를 원하므로 쓰기가 더 쉽고(보일러 플레이트가 적음) 오류가 발생하기 쉽습니다(자동 정리).

@jimfb 맞습니다. 자동 구독 취소는 Tracker의 접근 방식에서 정말 멋진 기능 중 하나입니다. 반응 데이터 소스에 대한 각 호출은 구독을 다시 설정하고 구성 요소가 데이터 호출을 중지하면 정리할 것이 없습니다!

예, 하지만 실제로 "자동으로" 구독 취소되는 것은 아닙니다. 구성 요소가 마운트 해제될 때 c.stop() 를 호출해야 합니다. 그러나 mixin을 사용하여 추상화할 수 있습니다.

componentWillMount: ->
  <strong i="7">@autorun</strong> =>
    @setState({loading: true})
    Meteor.subscribe 'users', => @setState({loading: false})
    Tracker.autorun =>
      @setState({users: Users.find({}, {sort:{name:-1}}).fetch()})

그러나 이것은 실제로 다른 API와 다르지 않습니다. 마운트 해제 등의 경우 자동으로 구독을 취소하는 기본 제공 메서드를 만들 수 있습니다. 보세요. 저는 Meteor의 열렬한 팬입니다. 그래서 나는 당신에게 이것에 대해 이야기하고 싶지 않습니다. 그냥 가끔, 나는 그것에 익숙하지 않은 누군가에게 이 내용을 설명하는 것이 정말 어렵다는 것을 알게 됩니다. 한편, 간단한 리스너/이벤트 이미터를 사용하는 것은 이해하고 구현하기가 훨씬 더 간단하며 사용하려는 반응성 시스템과 매우 호환되는 경향이 있습니다...

@ccorcos 우리는 다른 메커니즘에 대해 이야기하고 있을지도 모릅니다. 마지막으로 확인해보니 Tracker에는 영구 구독이 없었습니다. 반응 데이터 소스에 대한 종속성을 설정하는 각 함수(액세스하여)는 변경될 때 _한 번_ 다시 실행되고 구독이 종료됩니다. 데이터 소스에 다시 액세스하면 한 번 더 변경하기 위해 "구독"이 다시 설정됩니다. 등등.

@Mitranim 은 정확하고 #3920의 의미는 Meteor보다 더 "자동"이며(구독 취소는 실제로 자동입니다) 일반적인 사용 사례에서 말 그대로 API 표면적이 0이기 때문에 훨씬 간단합니다.

@ccorcos @Mitranim 사용할 준비가 된 Tracker/Vue.js 영감 라이브러리의 경우 Mobservable 을 시도할 수 있으며 _render_ 동안 액세스되는 모든 데이터를 관찰하고 마운트 해제 시 모든 구독을 삭제합니다(그때까지 구독이 활성 상태로 유지됨). 지금까지 Mendix에서 꽤 큰 프로젝트에 성공적으로 적용했습니다. 자체 모델 개체를 제공하는 대신 기존 개체를 장식할 뿐만 아니라 데이터에 방해가 되지 않습니다.

마지막으로 확인해보니 Tracker에 영구 구독이 없었습니다.

@Mitranim 구독은 영구적일 수 있습니다. 이것 좀 봐.

sub = Meteor.subscribe('chatrooms')
# this subscription lasts until...
sub.stop()

이제 Tracker에 몇 가지 흥미로운 기능이 있습니다. 이것 좀 봐.

comp = Tracker.autorun ->
  Meteor.subscribe('chatrooms')
# this subscription lasts until...
comp.stop()

마지막 예제는 그다지 유용하지 않습니다. 우리가 이런 일을 할 때까지.

roomId = new ReactiveVar(1)
comp = Tracker.autorun ->
  Meteor.subscribe('messages', roomId.get())
# when I change the roomId, the autorun will re-run
roomId.set(2)
# the subscription to room 1 was stopped and now the subscription to room 2 has started
# the subscription is stopped when I call stop...
comp.stop()

반응 데이터 소스에 대한 종속성을 설정하는 각 함수(액세스하여)는 변경될 때 한 번 다시 실행되고 구독이 종료됩니다.

구독은 자동 실행이 다시 실행되거나(반응 종속성이 변경됨) 해당 구독이 있는 계산이 중지될 때까지 지속됩니다. 둘 다 compute.onInvalidate 후크를 호출합니다.

다음은 똑같은 일을 해낸 아주 기발한 버전입니다. Tracker가 어떻게 작동하는지 이해하는 데 도움이 되기를 바랍니다. 그리고 어쩌면 당신은 그것이 얼마나 지저분해질 수 있는지도 알게 될 것입니다.

comp = Tracker.autorun ->
  Meteor.subscribe('chatrooms')

# is the same as

comp = Tracker.autorun (c) ->
  sub = null
  Tracker.nonreactive ->
    # dont let comp.stop() stop the subscription using Tracker.nonreactive
    sub = Meteor.subscribe('chatrooms')
  c.onInvalidate ->
    # stop the subscription when the computation is invalidated (re-run)
    sub.stop()
# invalidate and stop the computation
comp.stop()

@ccorcos 이제 혼란의 원인이 보입니다. 내 사전이었다. 구독에 대해 이야기할 때 _Meteor 구독_을 의미하는 것은 아닙니다. 그들은 서버에서 클라이언트로 푸시되는 데이터를 결정하지만 이 토론의 주제인 보기 계층 업데이트와 관련이 없습니다. _subscription_을 말할 때 나는 전통적인 이벤트 리스너와 반응성 데이터 소스에 의존하는 기능을 재실행하는 Tracker의 능력 사이에 평행선을 그렸습니다. React 구성 요소의 경우 데이터를 가져온 다음 setState 또는 forceUpdate 를 호출하는 구성 요소 메서드입니다.

@mweststrate 예를 들어 주셔서 감사합니다. 흥미롭게 보입니다.

아 예. 그래서 그들은 그것을 하는 영리한 방법을 가지고 있습니다.

componentWillMount: function() {
  this.comp = Tracker.autorun(() => {
    let sub = Meteor.subscribe('messages')
    return {
      loading: !sub.ready(),
      messages: Messages.find().fetch()
    }
  })
componentWillUnmount: function() {
  this.comp.stop()
}

구독은 문제 없이 매번 다시 구독합니다. sub.ready 및 Messages.find.fetch는 모두 "반응적"이며 변경될 때마다 자동 실행이 다시 실행되도록 트리거합니다. Tracker의 멋진 점은 자동 실행을 숨기기 시작하고 문서에서 특정 기능이 "반응 컨텍스트" 내에 있다는 것을 문서에 포함할 때입니다.

이것을 mixin에 던질 수 있습니다.

componentWillMount: function() {
  this.comp = Tracker.autorun(() => {
    return this.getReactiveData()
  })
componentWillUnmount: function() {
  this.comp.stop()
}

그리고 나면 작동하는 마술처럼 반응하는 기능만 남게 됩니다!

getReactiveData: function() {
  let sub = Meteor.subscribe('messages')
  return {
    loading: !sub.ready(),
    messages: Messages.find().fetch()
  }
}

트래커가 이렇게 멋진데...

@ccorcos 추적기 스타일 이벤트를 사용할 때 자동 unsubs에 대해 다소 잘못된 것으로 나타났습니다. componentWillUnmount 에서 리스너를 중지해야 합니다. 그렇지 않으면 계속해서 데이터 소스에 도달하고 setState 를 호출합니다(현재 사용되지 않는 isMounted() 로 확인하지 않는 한).

참고로 우아한 데코레이터를 만들어 구성 요소 메서드를 반응형으로 만들 수 있습니다. 다음은 몇 가지 예입니다. [1] , [2] . 다음과 같이 보입니다.

export class Chat extends React.Component {
  <strong i="13">@reactive</strong>
  updateState () {
    this.setState({
      auth: auth.read(),
      messages: messages.read()
    })
  }

  /* ... */
}

@Mitranim 꽤 깔끔합니다 -- 그래도 고차원 기능을 선호합니다. ;)

@sebmarkbage @jimfb 저는 이 스레드와 alt 스레드(#3858)를 몇 달 동안 팔로우하고 있으며 핵심 팀이 이 문제에 대해 합의에 도달했는지 또는 적어도 일반적인 방향에 도달했는지 궁금합니다.

@oztune 업데이트 없음; 우리는 다른 우선순위에 집중했습니다. 이 주제에 대한 업데이트가 있을 때 스레드 중 하나에 게시할 것입니다.

여러분, 컨테이너를 구성하는 범용 API를 만들었습니다. 반응 구성기를 확인하십시오. 즉, 고차 기능을 가진 컨테이너를 만들 수 있습니다.

import { compose } from `react-komposer`;

// Create a component to display Time
const Time = ({time}) => (<div>{time}</div>);

// Create the composer function and tell how to fetch data
const composerFunction = (props, onData) => {
    const handler = setInterval(() => {
    const time = new Date().toString();
    onData(null, {time});
  }, 1000);

  const cleanup = () => clearInterval(handler);
  return cleanup;
};

// Compose the container
const Clock = compose(composerFunction)(Time);

// Render the container
ReactDOM.render(<Clock />, document.getElementById('react-root'));

여기 라이브 버전이 있습니다: https://jsfiddle.net/arunoda/jxse2yw8/

또한 Promises, Rx.js Observables 및 With Meteor's Tracker를 사용 하여 컨테이너를 구성하는 몇 가지 쉬운 방법이 있습니다.

또한 이에 대한 내 기사를 확인하십시오. Let's Compose Some React Containers

@arunoda 우리는 매우 비슷한 일을 하게 되었습니다. 한 가지 궁금한 점은 prop이 변경될 때마다 composerFunction 이 호출되지 않도록 하는 방법은 무엇입니까?

@oztune 실제로 이제 다시 실행됩니다. 우리는 이 Lokka 와 Meteor를 사용합니다. 둘 다 로컬 캐시가 있으며 우리가 composerFunction을 여러 번 호출하더라도 서버에 도달하지 않습니다.

하지만 다음과 같이 할 수 있다고 생각합니다.

const options =  {propsToWatch: ["postId"]};
const Clock = compose(composerFunction, options)(Time);

어떤 아이디어?

@arunoda 그것이 우리도 시도한 것이지만, 그것은 액션과 그 의존성 사이에 약간의 단절을 만듭니다. 이제 react-async와 유사한 작업을 수행합니다. 여기서 주어진 작업을 즉시 수행하는 대신 composerFunction이 함수와 키를 반환합니다. 키가 composerFunction에 의해 반환된 이전 키와 다른 경우 새 기능이 수행됩니다. 이것이 이 github 스레드의 접선인지 확실하지 않으므로 Twitter(동일한 사용자 이름)에서 계속해서 기쁩니다.

@oztune 나는 새로운 GH 이슈를 만들었고 거기서 우리의 채팅을 계속합시다. 트위터보다 훨씬 나은 것 같아요.

내가 Observable을 소품(예: this.props.todo$)으로 전달하고 JSX에 포함할 수 있도록 JSX가 Observable을 직접 이해하고 렌더링하도록 하면 안 됩니다. 그러면 API가 필요하지 않고 나머지는 React 외부에서 관리되고 HoC는 관찰 가능 항목을 채우는 데 사용됩니다. props에 일반 데이터 또는 관찰 가능 데이터가 포함되어 있는지 여부는 중요하지 않으므로 특별한 this.data가 필요하지 않습니다.

또한 React render는 추가 라이브러리 없이 링크에 설명된 디자인을 허용하는 Oservable[JSX]을 렌더링할 수 있습니다.

https://medium.com/@milankinen/containers -are-dead-long-live-observable-combinators-2cb0c1f06c96#.yxns1dqin

https://github.com/milankinen/react-combinators

안녕하세요,
현재로서는 rxjs 스트림과 함께 상태 비저장 구성 요소를 쉽게 사용할 수 있습니다.
다른 API의 필요성을 이해하지 못합니다.
나는 예제를 작성했습니다. 보드 위에 마우스를 올릴 수 있고 26에 도달하면 다시 시작하도록 변경됩니다.
이 방법에 대해 어떻게 생각하는지 듣고 싶습니다.
코드는 다음과 같습니다.
https://jsfiddle.net/a6ehwonv/74/

@giltig : 저도 최근에 이렇게 배우고 있는데 좋아요. Cycle.js와 함께합니다.

브리징을 위해 주제를 전달하지 않고도 구성 요소에 정의된 이벤트 핸들러를 어떻게든 쉽게 들을 수 있게 되어 감사합니다. 내가 올바르게 이해한다면 여기에 제안된 것과는 거의 반대입니다. 또는 합성 이벤트에 대해 React vdom을 관찰할 수 있는 경우 "ref"를 관찰용으로 사용하여 CSS 태그가 관찰되지 않도록 할 수 있습니다.

더 큰 구성 요소를 만들기 위해 React 기능 구성 요소를 직접 사용할 수 있도록 RxJ는 CombineLatest에서 개체를 지원할 수 있습니다.

const myFancyReactComponent = ({surface, number, gameover}) => (
        <div> 
          {gameover ? gameover : surface}
          {number}
        </div>
)

const LiveApp = Rx.Observable.combineLatest(
    LiveSurface, DynamicNumberView, DynamicGameOver,
    myFancyReactComponent
)

안녕,
우리가 Cycle이나 다른 프레임워크를 사용하지 않는 이유는 프레임워크보다 라이브러리를 선호하기 때문이며(개발자에게 더 많은 제어 권한이 있음) 또한 React가 가진 커뮤니티의 힘을 즐기고 싶기 때문입니다.
현재 React용으로 많은 렌더 엔진이 개발되었으며 사용하지 않는 것이 유감입니다(ReactNative, ReactDom, ReactThree 등). Rxjs만 사용하고 위에서 보여준 예와 같이 반응하는 것은 매우 간단합니다.

리액트 컴포넌트가 옵저버블이 props인 한 포조를 받아들일 수 있다면 생각이 더 쉬워졌을 것입니다. 지금으로서는 불가능하므로 위에서 설명한 것이 우리가 선택한 방식입니다.

BTW MyFancyReactComponent로 수행한 작업은 가능하며 jsx를 직접 작성할 수도 있지만 일부 경우에는 실제로 그렇게 했습니다.

주제와 관련하여 - 결국 React 구성 요소에서 무엇이든 될 수있는 처리기 기능을 사용하고 있기 때문에 유효한 방법이라고 생각합니다. 나는 이벤트를 수신하는 내부 주제를 사용하여 구현하기로 선택했지만 다른 사람이 선택할 수 있습니다. 유연합니다.

리액트 컴포넌트가 옵저버블이 props인 한 포조를 받아들일 수 있다면 생각이 더 쉬워졌을 것입니다. 지금으로서는 불가능하므로 위에서 설명한 것이 우리가 선택한 방식입니다.

관찰 가능한 소품은 장기적으로 의미가 없습니다. 사실 그런 맥락에서 전혀 의미가 없습니다..

Suspense(캐시 + 컨텍스트)가 있는 다른 모델로 끝난 것처럼 들립니다. 캐시 자체가 구독에 대한 지원을 받을 수 있습니다. https://github.com/facebook/react/issues/13206 에서 Suspense의 남은 작업을 추적할 수 있습니다

또한 더 격리된 사례를 위한 구독 패키지도 제공합니다.