While working on the docs site, I found it useful to have test IDs so certain elements could be identified at test time. While I think this is generally an anti-pattern to be avoided, sometimes it is useful. @rules_prerender in particular happens to be pretty good at this since the test IDs can be relatively trivially removed from the production build, as if they were never there. Should experiment to see if it's worth making this a real public API of @rules_prerender.
One other question: Is test ID the right primitive, or do we want more comprehensive "testonly logic" support built into the rendering process? Similar to how test IDs are kind of an anti-pattern, I would also argue that testonly logic in production code is an anti-pattern. Need to investigate more to see.
While working on the docs site, I found it useful to have test IDs so certain elements could be identified at test time. While I think this is generally an anti-pattern to be avoided, sometimes it is useful.
@rules_prerenderin particular happens to be pretty good at this since the test IDs can be relatively trivially removed from the production build, as if they were never there. Should experiment to see if it's worth making this a real public API of@rules_prerender.One other question: Is test ID the right primitive, or do we want more comprehensive "testonly logic" support built into the rendering process? Similar to how test IDs are kind of an anti-pattern, I would also argue that testonly logic in production code is an anti-pattern. Need to investigate more to see.