Alex Rickabaugh alxhub

This design is a thought experiment of mine, which has its origins in the ongoing discussion of the ECS (Entity Component System) design in Rust. The basic idea behind ECS is:

Entities are owned at the top level, usually by a Vec<T>.
Indices into the Vec are used to reference a given entity within complex data structures.

This design works really well with Rust's borrow checker, because of the single ownership structure. Since indices alone don't allow read or write access to the data, Rust's borrow checker doesn't consider them aliases. It does have a couple drawbacks:

If an entity is removed from the Vec without cleaning up all existing index references, then those indices are now stale, and may end up pointing at a different object, breaking application logic (but not causing any UB).
It's difficult to assert that all index references to a given entity have been removed from nested data structures.
Slots in the Vec now need to be managed to avoid fragmentation and unbounded growth.

Introduction

Angular templates are complex structures which both utilize and produce type information, similarly to classes or functions in TypeScript code. Historically, the type structures of templates were not well checked by previous versions of ngc. A flag fullTemplateTypecheck did engage a type checking mechanism for template code (on which this work is based), but it was never fully implemented and still failed to catch some common cases of errors.

This document describes the design of an Ivy-based type checking mechanism for templates, based on the previous design but augmented to support catching more error cases and restricted to operating under Ivy's assumption of locality.

Goals and non-goals

The goals of the new checker are as follows:

Esteemed Guest List

Crystal Riley
Sanjoy Som
Alex Rickabaugh (duh)
Maria Piszcz
Dinç Arslan
Lacey Engelke
Bryan & Laura Crowley
Alice Karsevar

I'm a core team member on Angular and am leading the effort to build the Ivy version of our compiler.

This talk is designed as a high level tour of Angular's architecture, and how we've achieved significant gains by redesigning our framework with a few rules in mind. It has two main goals:

to present the techniques that we've developed for our new architecture
to illustrate the application of these techniques through examples

The audience will walk away with a greater understanding of the capabilities of ES6 tools, Javascript runtime performance, and the tradeoffs required when architecting applications.

For example, one of Ivy's central tenants is "pay for what you use" - that any code or feature not immediately required for rendering the page should either be lazy loaded (if used later) by the bundler, or removed entirely by the tree-shaker. Achieving this for ancillary components is easy, but doing this for core pieces of the framework required a change in architecture. I will show how Angular is

Implementation plan for Inheritance in Ivy

In View Engine code, components and directives can inherit from base classes which also have Angular decorators. Data passed to annotations for the decorators will inherit properly between base and derived classes. This works as the metadata/summary system retains enough global information to resolve inheritance structures at compile time.

Consider the following structure:

@Directive({...})
export class Base {
 constructor(readonly dep: Dep) {}

	function ToDoAppComponent_TypeCheckBlock(ctx: ToDoAppComponent) { if (true) {
	var _t1 = document.createElement("section");
	var _t2 = document.createElement("header");
	var _t3 = document.createElement("h1");
	var _t4 = document.createElement("input");
	_t4.value = ctx.newTodoText;
	var _t5: any = (null!);
	var _t6 = _i0.NgIf.ngTypeCtor({ ngIf: ctx.todoStore.todos.length > 0 });
	_t6.ngIf = ctx.todoStore.todos.length > 0;
	if (_i0.NgIf.ngTemplateGuard_ngIf(_t6, ctx.todoStore.todos.length > 0)) {

	// @Component({...})
	declare class Child<T> {
	// @Input
	value: T;

	static ngTypeCheck<T>(inputs: { value?: T }): { $instance: Child<T> };
	}

	// @Component({selector: '...', template: '{{child.value.name}}'})
	declare class Container<T extends { name: string }> {

	declare class NgForOfContext<T> {
	$implicit: T;
	ngForOf: Array<T>;
	index: number;
	count: number;
	}

	declare class NgForOf<T> {
	ngForOf: Array<T>;
	ngForTrackBy: (item: T, index: number) => any;

	# ngtsc last week

	## Landed
	* `inputs` and `outputs` support in directive/component metadata
	* fix for `inject()` default value issue
	* `ReflectionHost` abstraction for ngtsc

	## PRs
	* 24632: ngInjectorDef compilation of @NgModule decorator

	@Injectable({providedIn: ServiceModule})
	export class Service {}

	@NgModule({}) export class ServiceModule {}

	@NgModule({
	imports: [ServiceModule]
	})
	export class AppModule {}