blocks|key|2956587|text|我是React开发人员。我将回答你的每一个问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2956588|2956589|只要您将DOM放回componentWillUpdate中，|2956590|+React就不会关心DOM是否在更新之间移动。|blockquote|2956591|2956592|2956593|True+--+React不会查看DOM，除非是在更新时，事件处理程序除外：|2956594|2956595|+React事件处理程序仍将对已移动的元素起作用。|2956596|2956597|2956598|我不会依赖这一点，我甚至不确定这是不是真的。|2956599|2956600|+React会将您要求的任何内联样式与元素上已有的样式合并(即使它没有设置它们)。|2956601|2956602|2956603|我也不会依赖这个--现在React设置了单独的属性，但是我可以很容易地想象它会设置el.style.cssText，如果这样做的速度更快的话，这将使您所做的单个更改付之东流。|offset|length|style|CODE|2956604|即使您将DOM移动到文档中的其他位置，|2956605|+React也会更新它所呈现的DOM！|2956606|2956607|2956608|我现在不相信这是真的，你也不应该依赖它。|2956609|2956610|一般而言，您不应该手动操作React创建的DOM。在React中创建一个空的<div>并手动填充它是100%25合乎规范的；甚至可以修改React呈现的元素的属性，只要您稍后不尝试在React中更改它的属性(导致React执行DOM更新)，但是如果您移动一个元素，React可能会查找它并在找不到它时感到困惑。|2956611|希望这能有所帮助。|2956612|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|15|G|0|0|0|0|0|0|0|12|5|0|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|1K|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|1L|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1O|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|M|3|N|5|G|7|1Q|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1T|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|T|3|U|5|G|7|1V|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Y|8|@$Z|1Z|10|20|11|12]]|9|@]|A|$]]|$1|13|3|14|5|6|7|21|8|@]|9|@]|A|$]]|$1|15|3|16|5|G|7|22|8|@]|9|@]|A|$]]|$1|17|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|25|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|27|8|@$Z|28|10|29|11|12]]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]]|1H|$]]

I'm a React dev. I'll answer each of your questions:

<hr>

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

True -- React doesn't look at the DOM except when updating, with the exception of event handlers:

<blockquote>
 React event handlers will still work on elements that have been moved.
</blockquote>

I wouldn't rely on this, and I'm not sure that it's even true now.

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

I also wouldn't rely on this -- right now React sets individual properties but I could easily imagine it setting <code>el.style.cssText</code> if that were faster, which would blow away individual changes that you've made.

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

I don't believe this is true currently and you also shouldn't rely on this.

<hr>

Broadly speaking, you shouldn't manipulate by hand the DOM that React has created. It's 100% kosher to create an empty <code>&lt;div&gt;</code> in React and populate it by hand; it's even okay to modify the properties of a React-rendered element as long as you don't later try to change its properties in React (causing React to perform DOM updates), but if you move an element, React may look for it and get confused when it can't find it.

Hope that helps.

blocks|key|2744108|text|一方面，我同意索菲的观点，即你不应该根据实现细节做出决定。然而，我想说的是，看看React实际是如何工作的仍然很有趣：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2744109|有些事情可能会有一点变化，但通常这就是发生的事情和它是如何发生的。|2744110|2744111|考虑到React将唯一的it+(现在的数据属性)放在它创建的每个DOM元素上。这些ID目前基于一个非常简单的系统。这应该可以解释系统--根节点总是'.0‘|ordered-list-item|2744112|2744113|.0.0.0+.0.1+.0.0.0+.0.1.0+.0.1.1|2744114|当你提供一个'key‘属性时，你提供的值将被用于id，而不是列表中的索引，但是系统保持不变。|2744115|React创建的虚拟DOM+|2744116|也有具有相同ids的轻量级对象。这是虚拟DOM和真实DOM之间的简单映射系统。|2744117|这也是为什么如果不提供'key‘属性，列表中的元素就会被覆盖，因为如果在列表中间添加或删除元素，元素的id就会改变。|2744118|2744119|记住这一点：|2744120|只要您将DOM放回componentWillUpdate中，|2744121|+React就不会关心DOM是否在更新之间移动。|blockquote|2744122|2744123|2744124|是。我认为即使在更新之前不把元素放回原处，事情也是可能的，因为React使用的是ids。但这将是一个非常棘手和不可靠的工作，因为元素可能会被添加或删除，事情可能会崩溃。|2744125|2744126|+React事件处理程序仍将对已移动的元素起作用。|2744127|2744128|2744129|是的..。在某种程度上。react中的事件处理程序的工作方式是所有事件都是合成的。这意味着在React根DOM节点上只有一个事件侦听器。在那里捕获的所有事件都与React中的事件侦听器进行匹配。我认为这也使用了ID来匹配元素。但是，React可能会对其父元素进行一些最小限度的检查。我认为只要元素保持在React呈现的同一根节点内，就应该可以工作。也就是说，React可能会在未来更新id系统，并在未来对父节点进行更多检查，然后这可能会崩溃。|2744130|2744131|+React会将您要求的任何内联样式与元素上已有的样式合并(即使它没有设置它们)。|2744132|2744133|2744134|这个问题已经得到了回答。目前有效，将来可能不起作用。我不认为它会在短期内改变，因为有一些动画系统依赖于这个实现细节。|2744135|即使您将DOM移动到文档中的其他位置，|2744136|+React也会更新它所呈现的DOM！|2744137|2744138|2744139|是的，如果您使用相同的react-id保留相同的DOM元素，react将不会知道它已经在文档中移动，而只是更新它，就像它在呈现它的位置一样。正如你已经注意到的，它需要在相同的React+Root中。这一点很重要，因为React只绑定到React根DOM节点用于合成事件等。这种方式React可以很好地与其他库配合使用，并且不需要访问文档根目录。|2744140|警告:你可以做一些事情并不意味着你应该去做。一般来说，您应该只添加额外的DOM节点，并在不受React管理的DOM节点上添加属性(样式:转换值对于动画是常见的)。当你做其他事情的时候，要明白事情可能行得通，但通常有更好的方法来做事情。|2744141|2744142|至于你的问题：|2744143|2744144|，那么你会如何解决我的问题呢？例如，滚动区域内的下拉菜单被溢出...我总是将元素移到正文中，但这似乎不是反应的方式。|2744145|2744146|2744147|我认为理想的情况是首先将dropdown放在body中。然后，您可以在click事件和down之间传递消息。您可以使用回调在虚拟DOM上达到足够高的级别，然后一直更新道具直到下拉列表，以管理它的状态。或者只是使用一个好的旧事件系统。|2744148|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|24|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|25|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|27|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|28|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|29|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|2A|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|2B|8|@]|9|@]|A|$]]|$1|O|3|P|5|G|7|2C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|G|7|2D|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|2F|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|2G|8|@]|9|@]|A|$]]|$1|X|3|Y|5|Z|7|2H|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|2I|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2K|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]|$1|15|3|16|5|Z|7|2M|8|@]|9|@]|A|$]]|$1|17|3|-4|5|6|7|2N|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|2O|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2P|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|Z|7|2R|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2S|8|@]|9|@]|A|$]]|$1|1F|3|-4|5|6|7|2T|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2U|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|2V|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|Z|7|2W|8|@]|9|@]|A|$]]|$1|1M|3|-4|5|6|7|2X|8|@]|9|@]|A|$]]|$1|1N|3|-4|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|6|7|30|8|@]|9|@]|A|$]]|$1|1S|3|-4|5|6|7|31|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|6|7|32|8|@]|9|@]|A|$]]|$1|1V|3|-4|5|6|7|33|8|@]|9|@]|A|$]]|$1|1W|3|1X|5|Z|7|34|8|@]|9|@]|A|$]]|$1|1Y|3|-4|5|6|7|35|8|@]|9|@]|A|$]]|$1|1Z|3|-4|5|6|7|36|8|@]|9|@]|A|$]]|$1|20|3|21|5|6|7|37|8|@]|9|@]|A|$]]|$1|22|3|-4|5|6|7|38|8|@]|9|@]|A|$]]]|23|$]]

On the one hand I agree with Sophie that you should not base decisions on implementation details. However, I would say it is still interesting to see how React actually works:

Some things may have changed a little bit, but generally this is what happes and how it happens.

<ol>
<li>Consider the fact that React puts unique ids (now data- attributes) on every DOM element it creates. These IDs are currently based on a very simple system. This should explain the system - The root node is always '.0'

<pre><code> .0
 .0.0 .0.1
.0.0.0 .0.1.0 .0.1.1
</code></pre></li>
</ol>

Whenever you provide a 'key' attribute the value you provide is used for the id rather than it's index in a list, but the system remains the same.

<ol start="2">
<li>The Virtual DOM created by React also has lightweight objects with the same ids. This is the simple mapping system between the virtual DOM and the real DOM.</li>
<li>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.</li>
</ol>

Keeping that in mind:

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

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.

<blockquote>
 React event handlers will still work on elements that have been moved.
</blockquote>

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.

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

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.

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

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.

<hr>

As for your problem:

<blockquote>
 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. 
</blockquote>

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.

This is what I am doing: <a href="http://jsfiddle.net/iamnoah/pTrrw/" rel="nofollow noreferrer">jsfiddle</a> 

The critical section is:

<pre><code>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();
},
</code></pre>

This works great right now. I put the content back before the component updates on the assumption that React leaves the DOM alone between updates and won't miss it. In fact, React seems to be fine with moving content (if I remove <code>componentWillUpdate</code> and <code>componentDidUpdate</code>, the positioned element still updates!)

My question is how many of the resulting assumptions are safe (i.e., if I assume these things, will my code break in a future version of React?):

<ul>
<li>React does not care if DOM is moved around between updates as long as you put it back in <code>componentWillUpdate</code>.</li>
<li>React event handlers will still work on elements that have been moved.</li>
<li>React will merge any inline styles you ask it with styles already on the element (even if it did not set them.)</li>
<li>React will update DOM it has rendered, even if you move that DOM somewhere else in the document!</li>
</ul>

The last one seems somewhat extreme and magical to me, but has some great implications if it holds.

React: How much can I manipulate the DOM React has rendered?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这就是我正在做的：关键部分是：position: function() {  var container = $(this.getDOMNode());  this._menu = $(this.refs.menu.getDOMNode());  this._menu.appendTo(document.body). ...

问React:我可以在多大程度上操纵React呈现的DOM？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问React:我可以在多大程度上操纵React呈现的DOM？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问React:我可以在多大程度上操纵React呈现的DOM？
EN