Factor out Forgiving parser from template engine. #234
Conversation
| /** Internal implementation details for template engine. */ | ||
| class TemplateEngine { | ||
| /** Forgiving HTML parser which leverages innerHTML. */ | ||
| class Forgiving { |
There was a problem hiding this comment.
Just moving some things around to form a new conceptual boundary between our “parser” and our “dom manager”.
| const onContent = TemplateEngine.#storeContentLookup.bind(null, lookups); | ||
| const onText = TemplateEngine.#storeTextLookup.bind(null, lookups); | ||
| const forgivingLanguage = language === TemplateEngine.#SVG ? Forgiving.svg : Forgiving.html; | ||
| const fragment = Forgiving.parse(strings, onBoolean, onDefined, onAttribute, onProperty, onContent, onText, forgivingLanguage); |
There was a problem hiding this comment.
This isn’t an interface we will ever make public. But — the idea is that it’s more like a visitor pattern. The parser just tells the integrator when something interesting happens and where it happened. This was one of the untangling changes we made for Unforgiving anyway, just back-porting it, really.
theengineear
force-pushed
the
factor-out-forgiving-parser
branch
from
8f73306 to
710bb86
Compare
|
FYI @klebba — Thanks for the motivation to improve our ability to do side-by-side comparison here in the future. Now that there is a one-line coupling between |
We want to experiment with an Unforgiving parser which our template engine can leverage. To enable better side-by-side comparison, we can factor out the current parser from our template engine and give it the same `parse` interface.
theengineear
force-pushed
the
factor-out-forgiving-parser
branch
from
710bb86 to
90b81ab
Compare
We want to experiment with an Unforgiving parser which our template engine can leverage. To enable better side-by-side comparison, we can factor out the current parser from our template engine and give it the same
parseinterface.