-
Notifications
You must be signed in to change notification settings - Fork 190
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[BREAKING] All internals now support serialization
This is the initial pass of making the program serializable. In general, previous work has made the program itself serializable, because the program itself is an array of opcodes, and an opcode is an array of numbers (128 bits). However, the program often has references into the constant pool. Some of the constant pool is already serializable (for example, strings). However, before this series of commits, the constant pool also contained a number of direct references to live objects that could not be trivially serialized. The purpose of these commits is to make all constants serializable. To make more objects supplied by the user serializable, we introduced a Resolver (similar but not identical to the interface in @glimmer/di) to indirect any lookup of user objects. The lookup specifier is required to be serializable. As part of this work, we added a few new features, because certain important functionality was previously implemented in userland, and the API for implementing them was excessively dynamic. - Implemented `{{component}}` and `(component)` (from Glimmer.js and Ember) natively in glimmer-vm. - Support for first-class argument currying in `(component)`. --- Previously, blocks were always compiled "in-place", taking advantage of the fact that nested blocks were never compiled during the compilation of their parent. Now, eager compilation requires us to compile nested blocks ahead of time, so the naive strategy of compiling into the "current" position doesn't work anymore. Instead, we compile into a temporary buffer, and commit into the main program once a particular block is finished. In practice, this means that nested blocks always appear *before* their parent in the program. Also added initial support for a component capability mask, which allowed us to build static component invocation. The most important consequence is that the system is no longer architected around the quirk of Ember's late-bound layouts. If a component definition is able to specify its layout ahead of time, we can generate a specialized invocation for the component we're invoking, rather than a bunch of dynamic checks that require us to keep static information around at runtime. Similarly, instead of modelling dynamic blocks as a special kind of runtime object, we now push the symbol table and Handle onto the stack. Because the symbol table is serializable (and Handle is an integer), this means that the constants used by dynamic invocation are always, themselves, serializable. [BREAKING] Remove all of the cases where Glimmer was sticking functions in the constant pool (which aren't serializable). The breaking change is that dynamic attributes should be installed by the didCreateElement manager hook (note: this is *not* the place where user code is invoked) rather than using the wrapping DSL. Similarly, dynamic tag name is now modelled by using a getTagName hook on the component manager. These hooks should be run in SSR mode.
- Loading branch information
1 parent
0730db8
commit 79f2b45
Showing
61 changed files
with
3,041 additions
and
2,543 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
import { TemplateMeta } from '@glimmer/wire-format'; | ||
import { Opaque, Option, Unique } from './core'; | ||
|
||
export interface Resolver<Specifier, T extends TemplateMeta = TemplateMeta> { | ||
lookupHelper(name: string, meta: T): Option<Specifier>; | ||
lookupModifier(name: string, meta: T): Option<Specifier>; | ||
lookupComponent(name: string, meta: T): Option<Specifier>; | ||
lookupPartial(name: string, meta: T): Option<Specifier>; | ||
|
||
resolve<U>(specifier: Specifier): U; | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.