[DRAFT] Redesign API for trusted (unsafe) strings#20358
Closed
chriskrycho wants to merge 2 commits intomainfrom
Closed
[DRAFT] Redesign API for trusted (unsafe) strings#20358chriskrycho wants to merge 2 commits intomainfrom
chriskrycho wants to merge 2 commits intomainfrom
Conversation
chriskrycho
force-pushed
the
htmlSafe-improvements
branch
from
fba0e0c to
81f2d03
Compare
This is unused elsewhere in the framework itself and is not public API, so it should be safe to remove. Additionally, since this is just a copy of the API from within Handlebars itself, users who want to use it should directly use Handlebars' (or some other library's) escaping library instead. See [the discussion at #16817][16817] for background. [16817]: #16817
chriskrycho
force-pushed
the
htmlSafe-improvements
branch
from
81f2d03 to
1127654
Compare
- 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 the `SafeString` contract from Glimmer, i.e. it provides only a `toHTML(): string` method. - Deprecate `htmlSafe` and `isHTMLSafe` and introduce new names which indicate what they actually do/are: `unsafelyTrustString` and `isTrustedString`.
chriskrycho
force-pushed
the
htmlSafe-improvements
branch
from
1127654 to
7d12deb
Compare
Member
|
See also emberjs/rfcs#443 |
Member
|
Is this still relevant? It is a draft PR |
Contributor
Author
|
Still worth doing, and this approach is probably roughly right, but obviously I am not going to land it. I will close this, but/and feel free to point people here as useful prior art, and folks should feel very free to |
Contributor
Author
|
…also it needs an RFC. Which is why we did not land it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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 theSafeStringcontract from Glimmer, i.e. it provides only atoHTML(): stringmethod.Deprecate
htmlSafeandisHTMLSafeand introduce new names which indicate what they actually do/are:unsafelyTrustStringandisTrustedString.