React : React가 렌더링 한 DOM을 얼마나 조작 할 수 있습니까?

React : React가 렌더링 한 DOM을 얼마나 조작 할 수 있습니까?

---

이것이 내가하는 일입니다 : jsfiddle

중요한 섹션은 다음과 같습니다.

position: function() {
  var container = $(this.getDOMNode());
  this._menu = $(this.refs.menu.getDOMNode());
  this._menu.appendTo(document.body).
      offset({
          top: container.offset().top + 
              container.outerHeight(),
          left: container.offset().left
      });
},
restore: function() {
  this._menu.appendTo(this.getDOMNode());      
},
componentWillUpdate: function() {
  this.restore();
},
componentDidUpdate: function() {
  this.position();
},
componentDidMount: function() {
  this.position();
},

이것은 지금 잘 작동합니다. React는 업데이트 사이에 DOM 만 남겨두고 놓치지 않을 것이라는 가정하에 컴포넌트 업데이트 전에 콘텐츠를 다시 넣었습니다. 사실, React는 콘텐츠를 이동해도 괜찮은 것 같습니다 ( componentWillUpdate및 제거해도 componentDidUpdate위치 지정 요소가 여전히 업데이트됩니다!)

내 질문은 결과 가정 중 얼마나 많은 것이 안전한지입니다 (즉, 이러한 가정을 가정하면 향후 React 버전에서 내 코드가 손상됩니까?).

• React는 DOM을 componentWillUpdate.
• React 이벤트 핸들러는 이동 된 요소에서 계속 작동합니다.
• React는 요청한 모든 인라인 스타일을 요소에 이미있는 스타일과 병합합니다 (설정하지 않았더라도).
• React는 문서의 다른 곳으로 해당 DOM을 이동하더라도 렌더링 한 DOM을 업데이트합니다!

마지막 것은 나에게 다소 극단적이고 마술적인 것처럼 보이지만 그것이 유지된다면 큰 의미가 있습니다.

---

저는 React 개발자입니다. 각 질문에 답해 드리겠습니다.

---

React는 DOM을 componentWillUpdate에 다시 넣는 한 업데이트 사이에 DOM이 이동하는지 상관하지 않습니다.

True-React는 이벤트 핸들러를 제외하고 업데이트 할 때를 제외하고는 DOM을 보지 않습니다.

React 이벤트 핸들러는 이동 된 요소에서 계속 작동합니다.

나는 이것에 의존하지 않을 것이며 지금도 그것이 사실인지 확신하지 못합니다.

React는 요청한 모든 인라인 스타일을 요소에 이미있는 스타일과 병합합니다 (설정하지 않았더라도).

나는 또한 이것에 의존하지 않을 것입니다. 지금 React는 개별 속성을 설정하지만 그것이 el.style.cssText더 빠르면 설정을 쉽게 상상할 수 있습니다 . 그러면 개별 변경 사항이 날아갈 것입니다.

React는 문서의 다른 곳으로 해당 DOM을 이동하더라도 렌더링 한 DOM을 업데이트합니다!

나는 이것이 현재 사실이라고 믿지 않으며 당신도 이것에 의존해서는 안됩니다.

---

일반적으로 React가 만든 DOM을 손으로 조작해서는 안됩니다. <div>React 에서 빈 공간을 만들고 손으로 채우는 것은 100 % 정결합니다 . 나중에 React에서 속성을 변경하지 않는 한 React에서 렌더링 한 요소의 속성을 수정하는 것도 괜찮습니다 (React가 DOM 업데이트를 수행하도록 함).하지만 요소를 이동하면 React가 해당 요소를 찾고 찾을 수 없을 때 혼란스러워집니다.

도움이되기를 바랍니다.

---

한편으로는 구현 세부 사항에 대한 결정을 내리지 말아야한다는 Sophie의 의견에 동의합니다. 그러나 React가 실제로 어떻게 작동하는지 보는 것은 여전히 ​​흥미 롭다고 말하고 싶습니다.

어떤 것들은 약간 변경되었을 수 있지만 일반적으로 이것이 일어나는 일과 발생하는 방식입니다.

1. React가 생성하는 모든 DOM 요소에 고유 한 ID (이제 데이터 속성)가 있다는 사실을 고려하십시오. 이 ID는 현재 매우 간단한 시스템을 기반으로합니다. 이것은 시스템을 설명해야합니다-루트 노드는 항상 '.0'입니다.

              .0
       .0.0        .0.1
   .0.0.0     .0.1.0 .0.1.1
   

'키'속성을 제공 할 때마다 제공 한 값이 목록의 색인이 아닌 ID에 사용되지만 시스템은 동일하게 유지됩니다.

2. React에서 만든 Virtual DOM에는 동일한 ID를 가진 경량 객체도 있습니다. 이것은 가상 DOM과 실제 DOM 간의 간단한 매핑 시스템입니다.

3. This is also why the elements in a list are overwritten if you don't provide the 'key' attribute as the id of the elements would change if an element is added or removed in the middle of the list.

Keeping that in mind:

React does not care if DOM is moved around between updates as long as you put it back in componentWillUpdate.

Yes. I think it's possible that things will work even if you don't put the element back before updates, since React works using ids. But that would be a very tricky and unreliable to work with as elements may be added or removed and things may break.

React event handlers will still work on elements that have been moved.

Yes... to an extent. The way the event handlers in react work is that all events are synthetic. This means that there is only ever one event listener at the React root DOM node. All events caught there are matched against the event listeners in React. I think this also uses IDs to match elements. However, React may do some minimal checking of it's parent elements. I think this should work as long as the element is kept within the same root node rendered by React. That said, React could update the id system in the future and do more checking of parent nodes in the future and this may then break.

React will merge any inline styles you ask it with styles already on the element (even if it did not set them.)

This has already been answered. Works for now, may not work in the future. I don't it will change in the short term though, as there are some animation systems that depend on this implementation detail.

React will update DOM it has rendered, even if you move that DOM somewhere else in the document!

Yes, if you keep the same DOM element with the same react-id, react will not know it has moved in the document and will just update it as if it was in the same position where it rendered it. As you already noticed it needs to be in the same React Root. This is important, as React only binds to the React root DOM node for synthetic events etc. This way React plays well with other libraries, and doesn't need access to the document root.

Word of Caution: just because you can do somethings doesn't mean you should. Generally speaking you should only add additional DOM nodes and add properties on DOM nodes that are not being managed by React (style : transform values are common for animations). When you do other things, understand that things may work, but usually there is a much better way to do things.

---

As for your problem:

So how would you solve my problem? e.g., a dropdown menu inside a scroll area getting cut off by the overflow... I've always moved the element to the body, but it seems that is not the React way.

I think the ideal situation here is to put the dropdown in the body to begin with. Then you can pass messages between the click event and the drop down. Either you can use callbacks to go high enough on the virtual DOM and then update props all the way down to the dropdown to manage it's state. OR just use a good ol' Event System.

참고URL : https://stackoverflow.com/questions/23530716/react-how-much-can-i-manipulate-the-dom-react-has-rendered