discourse/app/assets/javascripts/discourse-common/addon/lib
Godfrey Chan 2ae913f45e
Consistently import escape from discourse-common (#23790)
`escape` from `pretty-text/sanitizer` is a re-export of the same
function defined in `discourse-common`. Updating the import paths
across the codebase to use the `discourse-common` import path.

`escape` is a rather simple function that can be accomplished with
a regular expression in `discourse-common`.

On the other hand, the remaining parts in `pretty-text/sanitizer`
has a lot of code, PLUS it depend on the rather heavy "xss" NPM
library.

Currently, most of the consumers of `pretty-text/sanitizer` are of
the `{ escape }` varient. This is resolved by this PR.

The remaining usages are either:

1. via/through `PrettyText` which is essentially gated behind
   loading the markdown-it bundle, OR

2. via `sanitize` from `discourse/lib/text`

I believe we may ultimately be able to move all the usages to behind
the markdown-it bundle (or, equivilantly, set up another lazy bundle
for `sanitize`) and be able to shed the sanitization code and the
"xss" library from the initial page load.

`discourse/lib/text` also defines a `sanitizeAsync` which is gated
behind loading the markdown-it bundle.

Looking through the usages of `sanitize`, I believe most of these
can be safely switched to use `sanitizeAsync`, in that they are
already in an asynchrnous path that handles a server response. Most
of them are actually rendering a piece of server-generated HTML
message as flash message, so I am not sure there really is value in
sanitizing (we should be able to trust our own server?), but in any
case, code-wise, they should already be able to absorb the async
just fine.

I am not sure if `sanitize` and `sanitizeAsync` are actually API
compatible – they both take `options` but I think those `options` do
pretty different things. This is somethign for another person to
investigate down the road in another PR.

According to `all-the-plugins`, `discourse-graphviz` also import
from this location, so perhaps we should PR to update. That being
said, it doesn't really hurt anything to keep the alias around for
a while.
2023-10-11 22:21:01 +01:00
..
attribute-hook.js DEV: Replace deprecated String.prototype.substr() (#16233) 2022-04-01 17:35:17 +02:00
avatar-utils.js Consistently import escape from discourse-common (#23790) 2023-10-11 22:21:01 +01:00
debounce.js FIX: reimplements chat audio into a service (#18983) 2022-11-11 13:11:41 +01:00
deprecated.js DEV: Fail core JS test runs if deprecations are triggered (#20614) 2023-03-10 10:39:42 +00:00
discourse-template-map.js DEV: Remove Ember.TEMPLATES and centralize template resolution rules (#19220) 2022-11-29 10:24:35 +00:00
dom-from-string.js DEV: Allow utility class domFromString to take in strings with multiple top level elements (#15548) 2022-01-12 19:49:24 +08:00
escape.js FIX: Escape Font Awesome icons (#12421) 2021-03-17 16:11:40 +03:00
get-owner.js DEV: Rename custom getOwner to getOwnerWithFallback (#23437) 2023-09-26 14:30:52 +01:00
get-url.js FIX: Validate asset url before replacing base url (#16438) 2023-01-30 07:32:48 +08:00
helpers.js DEV: Sort imports 2023-10-10 21:46:54 +01:00
icon-library.js DEV: Sort imports 2023-10-10 21:46:54 +01:00
later.js DEV: Introduce discourseLater (#17532) 2022-07-17 00:50:49 +02:00
loader-shim.js DEV: add loader.js shims for packages used across bundles (#22703) 2023-08-09 12:04:41 +01:00
object.js DEV: Resolve and prevent user fixture changes leaking between tests (#23898) 2023-10-11 13:46:06 +01:00
popular-themes.js UX: update admin popular theme list (#23134) 2023-08-18 09:07:25 -04:00
raw-handlebars-helpers.js DEV: Extensively use startsWith() (#17540) 2022-07-17 20:16:39 +02:00
raw-handlebars.js DEV: Use DiscourseJsProcessor for theme template compilation (#18135) 2022-09-01 11:50:46 +01:00
raw-templates.js DEV: Sort imports 2023-10-10 21:46:54 +01:00
suffix-trie.js PERF: Improve JS app boot speed by optimizing customResolve() (#14990) 2021-11-18 16:38:00 +00:00