You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Can height auto-size from artboard (responsive text) without hardcoding? #375
In an Expo React Native app using rive-react-native, I want the animation to fill the available width and have its height determined by the Rive artboard’s responsive layout. The artboard grows based on a bound text value (via data binding).
####Problem:
With fit={Fit.Layout}, if I don’t set an explicit height on the Rive view/container, nothing renders. Adding a fixed height works, but I need the height to adapt to the artboard’s content (which changes with text).
Questions:
Does rive-react-native provide an intrinsic size (e.g., artboard bounds) that RN can use so height can be measured automatically?
With Fit.Layout, is an explicit height always required in RN? If yes, what’s the recommended pattern to derive height from the artboard at runtime (e.g., read bounds on load and set container height, compute aspectRatio, etc.)?
Any best practices for dynamic, text-driven Rive layouts on RN so the view height reflects artboard changes after data binding?
What I tried
style={{ width: '100%' }} alone → nothing renders. Adding a fixed height makes it render, but it defeats the goal of dynamic sizing from the artboard’s responsive layout.
I tried applying the same data-binding approach in React Native and ran into an issue.
To be explicit, the width/height values I’m referring to were manually authored data bindings inside the .rive file (for example, binding artboard size to custom numeric inputs). From what I observed, these values are not an inherent or automatically exposed property of the artboard.
Because Rive does not have an intrinsic size in React Native with Fit.layout, these manually databound artboard size values only resolve to a value greater than 0 if the host container is initially large enough for the artboard content to fully expand to its desired size.
If the Rive element is first rendered at a reasonable or constrained size, the databound width/height values coming from the Rive file resolve to 0. However, if I:
1. Render the Rive component with a very large width/height
2. Allow the artboard to complete its initial layout
3. Read the databound width/height values
4. Then update the host container to match those values
…the databound values behave as expected after that initial render.
This led me to consider a workaround where the Rive element is first rendered with opacity: 0, placed in an oversized container purely for measurement, and then re-rendered normally once the databound artboard size is known. This works, but feels brittle and unintuitive.
In our case, since we had control over the inputs and layout constraints, we ultimately hardcoded a fixed height instead.
Note: this testing was done roughly 1–2 months ago, so it’s possible behavior has changed since then.
Activity
jeroenkampinga commentedon Dec 11, 2025
I also want this behaviour. Is there any progress on this or did you find a solution @rhinck
rhinck commentedon Dec 14, 2025
@jeroenkampinga
I asked a related question on the Rive community forum here:
https://community.rive.app/c/support/can-height-auto-size-from-artboard-responsive-text-without-hardcoding
One of the developer advocates pointed me to this Flutter-specific thread about hug sizing and reading artboard dimensions via data binding:
https://community.rive.app/c/support/how-to-get-width-height-of-artboard-with-hug
I tried applying the same data-binding approach in React Native and ran into an issue.
To be explicit, the width/height values I’m referring to were manually authored data bindings inside the .rive file (for example, binding artboard size to custom numeric inputs). From what I observed, these values are not an inherent or automatically exposed property of the artboard.
Because Rive does not have an intrinsic size in React Native with
Fit.layout, these manually databound artboard size values only resolve to a value greater than 0 if the host container is initially large enough for the artboard content to fully expand to its desired size.If the Rive element is first rendered at a reasonable or constrained size, the databound width/height values coming from the Rive file resolve to 0. However, if I:
1. Render the Rive component with a very large width/height
2. Allow the artboard to complete its initial layout
3. Read the databound width/height values
4. Then update the host container to match those values
…the databound values behave as expected after that initial render.
This led me to consider a workaround where the Rive element is first rendered with opacity: 0, placed in an oversized container purely for measurement, and then re-rendered normally once the databound artboard size is known. This works, but feels brittle and unintuitive.
In our case, since we had control over the inputs and layout constraints, we ultimately hardcoded a fixed height instead.
Note: this testing was done roughly 1–2 months ago, so it’s possible behavior has changed since then.