Move more parsing of strings and html server-side #575
Conversation
hawkrives
left a comment
hawkrives
left a comment
There was a problem hiding this comment.
When possible, I'd like to use the JSDom functions instead of htmlparser2
| return str.replace(/<[^>]*>/gu, ' ') | ||
| } | ||
|
|
||
| export function fastGetTrimmedText(str) { |
There was a problem hiding this comment.
Since we have JSDOM here and aren't resource constrained, I'd like to remove this fn in favor of a JSDOM-based solution
There was a problem hiding this comment.
Thanks for mentioning this. We will go with the textContent solution.
| import _jsdom from 'jsdom' | ||
| const {JSDOM} = _jsdom | ||
|
|
||
| export {encode, decode} from 'html-entities' |
There was a problem hiding this comment.
How did we handle these here before adding this module? Does JSDOM handle this for us automatically when we call textContent?
There was a problem hiding this comment.
Great point. Looks like JSDOM handles decoding the entities properly for us. I've created a Repl to show the differences between fastGetTrimmedText and JSDOM's textContent.
* Replace JSDOM.fragment calls with ccc-lib's html helper * Add wrapped cleaning calls to jobs and calendar * Remove uses of encode/decode
|
Thinking more on this. With this refactoring, I find myself trying to move as much parsing for html, strings, and now data grouping to the backend as possible to lighten the renderer's job. Would it make sense to create a v2 of ccc-server's calendar and menus APIs to handle the conversion and grouping of events and menus to the client apps? I'm wondering if a v2 of the calendar and menu APIs should be tackled now or later. |
|
I'd be happy with a v2, I suppose. Let's do that in a separate MR, though |
Impacted endpoints
titlecase)Todo