allow components to render abstract elements(feature request) #2449
Comments
|
This is simply a limitation of React's current "DOM implementation" and will certainly be dropped in the future. You can return However, I'm not entirely sure what you're asking for, if you intend to render "dummy components" which never have any DOM themselves then while it will probably be supported in the future, it will probably not be considered good practice. |
|
@syranide I should post some example. Suppose such a component: React.createClass
render: ->
React.createAbstractElement 'group-a', data: {},
React.createElement 'div', data: {}, 'something'
React.createElement 'div', data: {}, 'something too'It renders: <div></div>
<div></div>But shows this in React devtool <group-a>
<div></div>
<div></div>
<group-b>So |
|
@jiyinyiyong Ah now I see, same answer though, it's a limitation of the current "DOM implementation" in React. There's nothing wrong with your example, but |
|
glad to here that
|
|
@syranide Do you know what is the actual limitation for allowing components to return arrays as a render result? I'm curious to know and investigate deeper. |
|
@leoasis I haven't really investigated the exact obstacles, but broadly speaking, the problem is the current implementation expects all components to correspond to exactly one DOM node (can be shared) which is a very simple case to handle (in-terms of lazily associating node and component, and also mutating the root components). To be able to handle 0 or 2+ is a lot more complex and none of that "infrastructure" currently exists in React (components would need to be aware of sibling components, etc, etc). |
|
@syranide I see, yeah, that seems to be something hard to tackle, since other libraries have the same limitation, so it is definitely not a trivial problem to solve. Will check the source for this and try to understand a bit better how that assumption of one component to one DOM element makes the code easier. Thanks! |
|
@leoasis If you're looking to contribute in general I would recommend looking to other areas of React. I would expect this to affect the internal API considerably in quite non-trivial ways and even if you managed to get it working, that it may just be too much friction to realistically get it approved. That being said, figuring out what needs to be done and pushing bite-sized PRs is always a possibility, or do you have any objections @sebmarkbage ? |
|
@syranide I'll do that as an exercise to get to know the internals of React. Honestly, especially given that you guys are awesome and couldn't figure it out yet, I don't think I will come out with something to change. It was only curiosity. Anyway, if there is already some research on this, and the pain points have already been identified, I'd be more than helpful to read through that and try to contribute! |
|
Closing this as a dupe of #2127. |
Every component we create we have to return an actiaul element. But in some cases we just don't actually need that. For example, when we attempt to transitions like what Famo.us does, we would calculate every position by hand, and such a wrapper becomes unnesseccery. So how about introducing something like "abstract elements" to do that?
The text was updated successfully, but these errors were encountered: