feat: Add support for Views with children
Closes #873 This PR adds ability for Nitro views to render React children on Android.
By default, Nitro Views uses SimpleViewManager to handle views. To support children, this PR introduces a new ViewConfig prop to the HybridView type, which extends HybridViewConfig. The ViewConfig currently supports an allowChildren flag. When allowChildren is set to true, it switches the underlying view manager to a ReactViewManager on Android, enabling child view rendering.
Screenshots
| iOS | Android |
|---|---|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| nitro-docs | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Jun 16, 2025 9:19am |
@mrousavy PR is ready for review
To make it work properly on iOS, (un)mountChildComponentView should be passed thru to contentView:
- (void)mountChildComponentView:(UIView<RCTComponentViewProtocol>*)childComponentView
index:(NSInteger)index {
[self.contentView mountChildComponentView:childComponentView index:index];
}
- (void)unmountChildComponentView:(UIView<RCTComponentViewProtocol>*)childComponentView
index:(NSInteger)index {
[self.contentView unmountChildComponentView:childComponentView index:index];
}
In current implementation children views is rendering as subviews of parent RCTViewComponentView, under module's view. Because of this we can't control the rendering of children in the module's swift code.
This could be tested by adding background color to UIView:
override public init() {
view.backgroundColor = .red
}
It will overlay all of its children.
To make it work properly on iOS,
(un)mountChildComponentViewshould be passed thru to contentView:- (void)mountChildComponentView:(UIView<RCTComponentViewProtocol>*)childComponentView index:(NSInteger)index { [self.contentView mountChildComponentView:childComponentView index:index]; } - (void)unmountChildComponentView:(UIView<RCTComponentViewProtocol>*)childComponentView index:(NSInteger)index { [self.contentView unmountChildComponentView:childComponentView index:index]; }In current implementation children views is rendering as subviews of parent RCTViewComponentView, under module's view. Because of this we can't control the rendering of children in the module's swift code.
This could be tested by adding background color to UIView:
override public init() { view.backgroundColor = .red }It will overlay all of its children.
Thanks for sharing i will take a look at this.
Hi @mrousavy and @patrickkabwe
Thanks for the work on adding child view support, @patrickkabwe . This feature would be really helpful for my project. I wanted to kindly check if there are any updates on this PR or if there’s another recommended way to enable child support in Nitro in the meantime?
Appreciate your time!
if there’s another recommended way to enable child support in Nitro in the meantime?
You can just edit your nitro-generated *ViewManager.kt file and change SimpleViewManager -> ViewGroupManager, and View -> ViewGroup. Then it automatically works.
We will add this to nitrogen in the future, but for now this is your safe workaround. :)
On iOS it already works.
@patrickkabwe is attempting to deploy a commit to the Margelo Team on Vercel.
A member of the Team first needs to authorize it.
@mrousavy PR is ready for review. please take a look once you get some time
I found some code structure changes. The idea is good, but execution could be improved
Thanks for the feedback. I’ve addressed the concerns you raised please take another look.
@mrousavy Is there anything outstanding on this PR aside from the recent merge conflicts? I’m currently developing a library that relies on this functionality, maintaining local patches has been workable but isn’t sustainable long-term. Please let me know if there are any remaining issues so I can allocate time to address them.
hey - yea sorry I want this feature but there's a ton of conflicts.
I think I will move this to a separate PR and start the work there, I have some minor code organization changes that will probably just be quicker if I do the refactors myself - is that cool with you?
hey - yea sorry I want this feature but there's a ton of conflicts.
I think I will move this to a separate PR and start the work there, I have some minor code organization changes that will probably just be quicker if I do the refactors myself - is that cool with you?
Yes this sounds good