[FEAT] Upstream manager infrastructure #19267
Conversation
| @@ -41,37 +41,31 @@ export interface InternalComponentState { | |||
| } | |||
|
|
|||
| export class InternalComponentDefinition | |||
There was a problem hiding this comment.
Calling these interfaces "internal" now seems odd (since glimmer-vm also has a set of things it calls "internal"). Not sure what the best name here would be, but something like EmberInternal* seems better than the current confusion (at least my confusion 😜 ).
There was a problem hiding this comment.
This is something that I plan on addressing in the next set of PRs, which will upstream most of the component manager logic. Part of that will be unifying internal and public component managers so they can both be used with setComponentManager, and in general use the same infrastructure. This way for instance, curly components will be able to be used in strict mode, since their internal manager will be associated with setComponentTemplate.
As part of that work, this manager will likely be renamed InputComponentManager or something like that. I could rename it as part of this PR I suppose, it's just a bit weird since the resolver in Ember still has a notion of "internal", and I didn't want to get rid of that all at once either.
| @@ -197,7 +197,7 @@ class ClassicHelperManager implements HelperManager<ClassicHelperStateBucket> { | |||
| } | |||
| } | |||
|
|
|||
| setHelperManager((owner) => new ClassicHelperManager(owner), Helper); | |||
| setHelperManager((owner: Owner | undefined) => new ClassicHelperManager(owner!), Helper); | |||
There was a problem hiding this comment.
Seems very suspect to update the signature here to allow undefined and to use owner!.
| @@ -430,6 +415,8 @@ export function invokeHelper( | |||
| manager | |||
| ); | |||
|
|
|||
| assert('Invoke helper does not support internal helpers yet', !isInternalHelper(manager)); | |||
There was a problem hiding this comment.
This seems like a new addition? Should we consider backporting this?
There was a problem hiding this comment.
This is a new addition, it is to allow us to associate internal helpers directly with a function via setHelperManager. This way we can make all of the built-in helpers work in strict mode, when you import them.
Currently, those internal helpers get resolved above, and we don't even associate any internal helpers directly with setHelperManager, so this assertion should never be triggered. I added it to satisfy the type constraints.
| VMArguments, | ||
| } from '@glimmer/interfaces'; | ||
| import { isInvokableRef, updateRef, valueForRef } from '@glimmer/reference'; | ||
| import { registerDestructor } from '@glimmer/runtime'; | ||
| import { createUpdatableTag } from '@glimmer/validator'; | ||
| import { createUpdatableTag, UpdatableTag } from '@glimmer/validator'; |
There was a problem hiding this comment.
Not sure how you feel, but I'd love it if type only imports were done separately....
| import { createUpdatableTag, UpdatableTag } from '@glimmer/validator'; | |
| import { createUpdatableTag } from '@glimmer/validator'; | |
| import type { UpdatableTag } from '@glimmer/validator'; |
There was a problem hiding this comment.
I mainly add imports via autocomplete (Command + . in VSCode), so if we can set it up so that it does type imports for types, I'm happy with that
There was a problem hiding this comment.
We also get a linting error for this, so I'm going to leave it as is for now
| @@ -361,6 +370,11 @@ export default class RuntimeResolverImpl implements RuntimeResolver<Owner> { | |||
| manager === SIMPLE_CLASSIC_HELPER_MANAGER | |||
| ); | |||
|
|
|||
| assert( | |||
| 'internal helpers are not supported via `getHelperManager` yet', | |||
There was a problem hiding this comment.
should include more information here, for example it should include the debug render tree stack and the name of the helper they asked for
There was a problem hiding this comment.
The debug render tree stack will be included in general, because we throw an error. There's no reason to manually add the stack, it'll always be logged regardless. Will add the name.
packages/@ember/-internals/glimmer/tests/integration/custom-component-manager-test.js
Show resolved
Hide resolved
| @@ -21,9 +21,7 @@ export type DebugFunctionType = | |||
| | 'runInDebug' | |||
| | 'deprecateFunc'; | |||
|
|
|||
| export type AssertFunc = | |||
| | ((desc: string) => never) | |||
There was a problem hiding this comment.
| ((desc: string) => never)
What was this overload even for? Seems weird...
There was a problem hiding this comment.
I have no idea, but it was messing with the asserts from TS so I removed, and everything seems to work 🤷
pzuraq
force-pushed
the
upstream/manager-infrastructure
branch
from
4255b76
to
420fa9a
Compare
pzuraq
force-pushed
the
upstream/manager-infrastructure
branch
from
420fa9a
to
615f8e4
Compare
Release: https://github.com/glimmerjs/glimmer-vm/releases/tag/v0.65.0