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
The prerender_component() macro compiles a user prerender library with additional deps. Users should be able to test this library and verify that it does what they expect it to do.
I think testing the library itself is pretty straightforward. Since it is just a ts_library() which exports some functions that return templated HTML, this can be tested with a simple jasmine_node_test(). The actual tests could be done by parsing the output as HTML and asserting that its structure matches expectations. If you are using a templating library like lit-html, getting assertable HTML content might be a little trickier, but that's more of a templating problem than a prerendering problem that we need to be concerned with.
In general, we don't want users to be able to depend directly on the ts_library(), because doing so could drop all the related targets that are required for it to run (like scripts, styles, and resources). Testing is a edge case where we just generally don't care about most of those resources.
We should consider documenting and exposing the prerender ts_library(), at least for testing purposes, in order to support this use case.
Alternatively, we could consider a more comprehensive implementation which allows users to test the prerendered HTML, scripts, styles, and resources all at once, but that seems like a much larger problem to handle.
The text was updated successfully, but these errors were encountered:
The
prerender_component()
macro compiles a user prerender library with additional deps. Users should be able to test this library and verify that it does what they expect it to do.I think testing the library itself is pretty straightforward. Since it is just a
ts_library()
which exports some functions that return templated HTML, this can be tested with a simplejasmine_node_test()
. The actual tests could be done by parsing the output as HTML and asserting that its structure matches expectations. If you are using a templating library likelit-html
, getting assertable HTML content might be a little trickier, but that's more of a templating problem than a prerendering problem that we need to be concerned with.We actually have a few examples of this in the
site
example. I think this works well enough, although it requires a dependency on%{component}_prerender
which is a little weird. That target is intended to be a private implementation detail.In general, we don't want users to be able to depend directly on the
ts_library()
, because doing so could drop all the related targets that are required for it to run (like scripts, styles, and resources). Testing is a edge case where we just generally don't care about most of those resources.We should consider documenting and exposing the prerender
ts_library()
, at least for testing purposes, in order to support this use case.Alternatively, we could consider a more comprehensive implementation which allows users to test the prerendered HTML, scripts, styles, and resources all at once, but that seems like a much larger problem to handle.
The text was updated successfully, but these errors were encountered: