Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

template compilation improvements #1010

Merged
merged 13 commits into from Apr 7, 2022
Merged

template compilation improvements #1010

merged 13 commits into from Apr 7, 2022

Conversation

ef4
Copy link
Contributor

@ef4 ef4 commented Oct 23, 2021

First, I'm refactoring so that we standardize all template compilation as inline template compilation, within Javascript, because that is the more fully-featured case. Specifically, a standalone HBS file can go through a trivial transformation to make it into a Javascript file:

<Hello />
import { hbs } from 'ember-cli-htmlbars';
export default hbs("<Hello />");

After which point we can share all the same standard machinery for compiling forward from there.

Second, I'm going to take advantage of template lexical scope in non-strict mode which we just successfully landed in ember-source 3.28.4. That will significantly streamline the build output when using staticComponents, etc, because we can pass the statically-resolved things directly into the template and completely sidestep the runtime resolver.

The first commit here is just testing out the basic idea, it needs further cleanup refactoring.

That is, instead of having different code paths for standalone hbs files vs templates embedded inside Javascript, we do a small transportation to the standalone hbs files to make them into JS first, and then share all the template compilation machinery.

This is also setting us up to take advantage of lexical scope in non-strict-mode which landed in ember-source 3.28.4.
@ef4
Copy link
Contributor Author

ef4 commented Oct 31, 2021

Reminder to self: template-compiler-broccoli-plugin.ts can drop its stage3 support, it will only need to handle stage1. Since stage one never needs the build time resolver, this may result in a much simpler setup that doesn't need our whole NodeTemplateCompiler at all.

@ef4
Copy link
Contributor Author

ef4 commented Oct 31, 2021

These changes can also address a cache-safety hole we currently have: the stage1 TemplateCompilerBroccoliPlugin uses broccoli-persistent-filter but only caches off:

  • hashDeps of @embroider/compat
  • the checksum of ember-template-compiler.js

It doesn't incorporate a checksum over the set of plugins.

@ef4 ef4 marked this pull request as ready for review April 7, 2022 13:54
@ef4
Copy link
Contributor Author

ef4 commented Apr 7, 2022

I'm going to land this long-running branch, it has a good refactor and all tests are passing.

The actual feature work on top to use lexical scope can be a followup.

@ef4 ef4 merged commit 810b4bb into main Apr 7, 2022
@ef4 ef4 deleted the template-compilation branch April 7, 2022 13:55
@rwjblue rwjblue added the enhancement New feature or request label Apr 7, 2022
ef4 added a commit to ember-cli/ember-cli-htmlbars that referenced this pull request Jun 30, 2022
Classically, standalone templates got a dedicated preprocessor that had nothing to do with Javascript transpilation.

Later came inline templates that appear inside Javascript. Those were handled as a totally separate code path from the standalone templates. To this day, there are two different code paths for handling these two cases.

But at this point, templates-inside-javascript are the foundational primitive that is aligned with [where Ember is heading](emberjs/rfcs#779), because they have access to Javascript scope and this solves a lot of problems.

We can treat standalone HBS as just a degenerate kind of JS that is easily up-compiled via a pure function, allowing them to go down the Javascript code path and allowing us to drop all the old code path.

This also makes it easier to support new features like [AST transforms that can manipulate Javascript scope](emberjs/babel-plugin-ember-template-compilation#5).

Embroider already [implemented this same pattern](embroider-build/embroider#1010).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants