Skip to content

feat(core): add DomRef API in developer preview#56544

Closed
devknoll wants to merge 1 commit intoangular:mainfrom
devknoll:x-add-dom-ref
Closed

feat(core): add DomRef API in developer preview#56544
devknoll wants to merge 1 commit intoangular:mainfrom
devknoll:x-add-dom-ref

Conversation

@devknoll
Copy link
Copy Markdown
Contributor

Add DomRef as a safer and more ergonomic API compared to ElementRef.

A DomRef is accessed by calling it, similar to a signal. Additionally, it ties result availability to rendering: it does not allow a reference to be unwrapped until after it has had an opportunity to render.

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

Add DomRef as a safer and more ergonomic API compared to ElementRef.

A DomRef is accessed by calling it, similar to a signal. Additionally, it ties result availability to rendering: it does not allow a reference to be unwrapped until after it has had an opportunity to render.
@angular-robot angular-robot bot added detected: feature PR contains a feature commit area: core Issues related to the framework runtime labels Jun 21, 2024
@ngbot ngbot bot added this to the Backlog milestone Jun 21, 2024
@devknoll devknoll changed the title feat(core): add experimental DomRef API feat(core): add DomRef API in developer preview Jun 21, 2024
// This class acts as a DI token for DomRef.
export class DomRef<T> {
/** @internal */
constructor() {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we make the constructor private instead of throwing ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we would still want to throw anyway, since you could still do new (DomRef as any)() to bypass the private constructor.

I think we'd really just want to declare DomRef as a function that throws:

export function DomRef<T>(): DomRef<T> {
  throw new RuntimeError(
    RuntimeErrorCode.DOMREF_CONSTRUCTOR,
    ngDevMode && 'DomRef cannot be called or constructed',
  );
}

But I think this might have some other issues.

@devknoll devknoll closed this Aug 22, 2024
@angular-automatic-lock-bot
Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area: core Issues related to the framework runtime detected: feature PR contains a feature commit

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants