[0.7] Large HTML trees can cause stack overflows in debug mode with no useful error message about leptos HOT 4 OPEN

Okay, so the stack overflow is just... a stack overflow. i.e., this page is very large, and it is all allocated on the stack because the whole thing is statically typed as a bunch of structs and tuples, not Boxes and Vecs. The elements and renderer types are all zero-sized, but even just the strings end up adding up. None of this is implicitly allocated on the heap (by putting it in a Vec<_> or something), and there are enough nested elements here that the stack is overflowing when you create the tree on that page.

There are several ways to fix this.

1. Add some heap allocation of pieces of it by using .into_any(). For example, I took one of the <table> elements, pulled it out separately as let table = view! { <table>/* a lot of rows */</table> }.into_any(), and then used {table} in its place in the view. Overflow solved.
2. Refactor some of the repeated, identical pieces to use, for example, a Vec<_> that you create with .collect_view(). This will also help your compile times FWIW. So for example, at least one of your tables can be

[("label", "label", "label"), ("other label", "something else", "something else")].into_iter().map(view! { <tr>/* etc */</tr>}).collect_view()`

(This will also save you from having to repeat all the Tailwind classes, etc.)

This did not cause an issue in 0.6 because all children were boxed, and then stored in a Vec, so there were never stack overflows -- but it ended up making a ton of individual heap allocations. A page like this should use much less memory and render much faster with the new system, you just need to break it up into a few pieces so the whole thing doesn't overflow the stack by pushing so much onto it.

from leptos.

Not a joke: It is possible a decent solution here is for us to impl<T> Render for Box<T> where T: Render, and then for the view macro to insert Boxes around groups of, say, 8 elements or something when they are all children. That's significantly less overhead than .into_any() in any case.

from leptos.

100% in favour of:

Not a joke: It is possible a decent solution here is for us to impl Render for Box where T: Render, and then for the view macro to insert Boxes around groups of, say, 8 elements or something when they are all children.

:D

from leptos.