[DRAFT] Redesign API for trusted (unsafe) strings #20358
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft PR to accompany a forthcoming proposal to improve this API along lines folks have talked about for years; I drafted the change to make it easier to discuss concretely with the accompanying RFC. This should not be taken as indicating we are doing this, only that I am proposing we do it and making it easy if we decide to do so!
Introduce an opaque public type for the result of marking a string as trusted,
TrustedString
. Make all the mechanical details of the class private, accessible only within the internal module. Define the type as an opaque type that other users can neither instantiate nor subclass, which implements theSafeString
contract from Glimmer, i.e. it provides only atoHTML(): string
method.Deprecate
htmlSafe
andisHTMLSafe
and introduce new names which indicate what they actually do/are:unsafelyTrustString
andisTrustedString
.