No infinite nesting - #183
Conversation
Since `testThrows()` used `test()` under the hood, and the latter tests for the results, the former would incorrectly pass tests whose results did not match `""`. Tests that rendered anything other than `""` would throw solely based on the resulting render rather than the test itself. Here I split off the shared functionality from `testThrows()` and `test()` into its own `getTest()` function, which returns a function that runs the test. This function can then be tested using `assertRejects()` or its result can be tested with `assertEquals()`.
This is mostly intended to prevent infinite nesting, but it also detects
simultaneously running templates in general. However, the latter is
extremely unlikely unless the user is specifically rendering templates
in parallel, since `{{ include }}` and `{{ layout }}` tags always
`await` their run before continuing to render the rest of the template.
|
I wasn't sure about how to properly detect infinite loops, because sometimes you want a template to include itself, directly or indirectly. But your approach of detecting simulataneous renderings is simple and good enough. |
That's much better, actually, yes. Do you have any suggestions for better names than |
|
Maybe |
|
Oh, that one's pretty good! I made a slight adjustment to that suggestion, making it I've also reworked it to be an option. Much nicer, thanks for pointing that out 😊 |
|
it's perfect. Thank you! |
2 participants
This is mostly intended to prevent infinite nesting, but really detects simultaneously running templates in general. However, the latter is extremely unlikely unless the user is specifically rendering templates in parallel, since
{{ include }}and{{ layout }}tags alwaysawaittheir run before continuing to render the rest of the template.Suggestions for other names are welcome, personally I'm not a huge fan of
MAX_SIMULTANEOUS_TEMPLATESbut this is more accurate than something likeMAX_NESTINGsince it can hypothetically trigger from concurrent non-nested templates.As a sidenote, this PR also includes a fix for
testThrows(), which wouldn't fail a test if it ran without error but rendered something other than""(because then the underlyingtest()call would throw an error since it failed to matchexpected: "").Resolves #180.