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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: