Split out template engine into “x-template.js”. #227
Conversation
| "./etc/ready.js" | ||
| ], | ||
| "compilerOptions": { | ||
| "target": "ES2023", | ||
| // Beyond just organization, a “bug” in how JSDocs works causes a cyclic |
There was a problem hiding this comment.
This was a cute one. It’s not really a bug from the perspective of the maintainers. Not terribly hard to workaround though — we just throw things into a /ts directory. Maybe we should have just done that from the start 🤷
Without this… you could build the types exactly once. Repeat builds would confuse TypeScript since the filename prefixes are the same. I.e., it would think we were trying to import our export 🤖
| } | ||
|
|
||
| // Long-term interface. | ||
| export const render = TemplateEngine.interface.render.bind(TemplateEngine); |
There was a problem hiding this comment.
Rather than export the class (which would lend itself to potential extension / misuse)… we export the exact functions in the interface (many of which are soon to be deleted!).
Conceptually “XElement” and “XTemplate” do very different things. The former is all about defining _element interfaces_ and the latter is all about turning interpolated markup into dom. Over time, even our PR diffs have highlited this separation of concerns. Often a PR _either_ changes XElement _or_ XTemplate — rarely both.
theengineear
force-pushed
the
split-out-template-engine
branch
from
2213dfc to
3aa78b3
Compare
|
FYI @klebba — Just working through some of the decisions we’ve been chatting about. In this case, we agreed that splitting this into two files is probably the right move. I went ahead and bumped some dev dependencies as well. |
Conceptually “XElement” and “XTemplate” do very different things. The former is all about defining element interfaces and the latter is all about turning interpolated markup into dom.
Over time, even our PR diffs have highlited this separation of concerns. Often a PR either changes XElement or XTemplate — rarely both.