Clarification on nested Live rendering behavior and recommended usage

[Darshanjajoria18]

Hi maintainers,

I opened this discussion following PR #4106 to clarify the behavior of nested Live instances.

From my current understanding:

• When a Live instance is created inside another Live context, the inner display is rendered below the outer display.
• Each Live instance runs its own refresh cycle independently.
• This can make nested usage slightly confusing when both instances update frequently.

Based on this, the current documentation suggests that in most cases it is preferable to use a single Live instance and update its renderable instead of nesting multiple ones.

I wanted to confirm:

• Is the rendering order (inner below outer) guaranteed behavior?
• Are there any edge cases where this behavior may differ?
• Is it acceptable to recommend single Live usage as the preferred pattern in documentation?

Thanks for your time 🙏

[apoorva-01]

Your read is right, and it's guaranteed by construction rather than luck. The console keeps a _live_stack and appends each Live as it enters. Only the bottom one (_live_stack[0]) actually draws. Its renderable property builds Group(*[live.get_renderable() for live in live_stack]) in stack order, so first-entered ends up on top and each nested one is appended below it. "Inner below outer" falls straight out of that list order.

Nested instances don't run their own independent paint. Their refresh() sets their renderable and then delegates up to _live_stack[0].refresh(), so there's one real refresh loop no matter how deep you go.

Two edge cases worth knowing:

• The stacking only happens when the instances share the same Console. Two Live on two different Console objects each keep their own stack and won't coordinate.
• Exit is a strict LIFO pop, so leave the inner one before the outer (a normal nested with does this for you). Stopping the outer while an inner is still active pops the stack out of order.

And yes, recommending a single Live + update() as the default is the right call. Nesting works, but since every nested refresh funnels through the bottom instance anyway, you aren't buying independent refresh cycles by nesting. One Live updating a composed renderable (a Group, a Table, whatever) is simpler to reason about.