Skip to content

fix(core): correctly fallback ng-content with projectable nodes. - #57480

Closed
chintankavathia wants to merge 1 commit into
angular:mainfrom
chintankavathia:projectable-nodes-with-fallback
Closed

fix(core): correctly fallback ng-content with projectable nodes.#57480
chintankavathia wants to merge 1 commit into
angular:mainfrom
chintankavathia:projectable-nodes-with-fallback

Conversation

@chintankavathia

@chintankavathia chintankavathia commented Aug 22, 2024 •
edited by crisbeto
Loading

Copy link
Copy Markdown
Contributor

projectableNodes should allow to pass empty nodes to fallback to default ng-content for that placeholder without affecting rendering of remaining nodes.

Fixes #57471

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?

Currently default ng-content fallback fails when projectableNodes are passed as empty in between of nodes.
e.g for below component template

<ng-content>One Fallback</ng-content>
<ng-content>Two Fallback</ng-content>
<ng-content>Three Fallback</ng-content>

if the projectableNodes are passed like this [[customContentElement], [], [anotherContentElement]];
it will render

<customContentElement/>
<anotherContentElement/>

Issue Number: 57471

What is the new behavior?

It should render default fallback for empty nodes like below.

<customContentElement/>
Two Fallback
<anotherContentElement/>

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

@pullapprove
pullapprove Bot requested a review from devversion August 22, 2024 05:58
@angular-robot angular-robot Bot added the area: core Issues related to the framework runtime label Aug 22, 2024
@ngbot ngbot Bot added this to the Backlog milestone Aug 22, 2024
@devversion
devversion requested review from crisbeto and removed request for devversion August 22, 2024 07:02
crisbeto
crisbeto reviewed Aug 22, 2024
View reviewed changes
Comment thread packages/core/src/render3/component_ref.ts Outdated
Comment thread packages/core/test/acceptance/content_spec.ts Outdated
@chintankavathia
chintankavathia force-pushed the projectable-nodes-with-fallback branch from d7be1bc to fa8b2b3 Compare August 22, 2024 07:42
@devversion

devversion commented Aug 22, 2024 •
edited
Loading

Copy link
Copy Markdown
Member

I might miss something from a quick glance. What would happen if someone wants to explicitly avoid the ng-content default and project zero nodes? Should null be used for explicitness to fall back

@chintankavathia

chintankavathia commented Aug 22, 2024

Copy link
Copy Markdown
Contributor Author

I might miss something from a quick glance. What would happen if someone wants to explicitly avoid the ng-content default and project zero nodes? Should null be used for explicitness to fall back

in that case they can pass document.createTextNode('')

@devversion

devversion commented Aug 22, 2024

Copy link
Copy Markdown
Member

It does sound like this would be a breaking change though?

@chintankavathia

chintankavathia commented Aug 22, 2024

Copy link
Copy Markdown
Contributor Author

It does sound like this would be a breaking change though?

You are right 💯 . so now the question is should we do this as breaking change or do you prefer to change projectableNodes type to (Node[] | null)[].

@diesieben07

diesieben07 commented Aug 22, 2024

Copy link
Copy Markdown

It does sound like this would be a breaking change though?

I might be missing something, but right now null is not a valid entry in the nodes array. So if null is introduced as a way to say "do not project anything here" instead of "project zero nodes here", would that not be backwards compatible?

@devversion

devversion commented Aug 22, 2024

Copy link
Copy Markdown
Member

I will defer to @crisbeto on how to treat this, as he is the expert on projection and its APIs.

@diesieben07 I think it wouldn't be a breaking change, if null is introduced as a way to say: "do not project anything, but use the default ng-content". That way this PR is basically an opt-in feature.

@chintankavathia
fix(core): fallback to default ng-content with empty projectable nodes.
a232f94 
BREAKING CHANGE: Render default fallback with empty `projectableNodes`.

When passing an empty array to `projectableNodes` in the `createComponent` API, the default fallback content of the `ng-content` will be rendered if present. To prevent rendering the default content, pass `document.createTextNode('')` as a `projectableNode`.

For example:

```ts
// The first ng-content will render the default fallback content if present
createComponent(MyComponent. { projectableNodes: [[], [secondNode]] });

// To prevent projecting the default fallback content:
createComponent(MyComponent. { projectableNodes: [[document.createTextNode('')], [secondNode]] });

```

Fixes angular#57471
@chintankavathia
chintankavathia force-pushed the projectable-nodes-with-fallback branch from fa8b2b3 to a232f94 Compare August 25, 2024 13:55
@angular-robot angular-robot Bot added the detected: breaking change PR contains a commit with a breaking change label Aug 25, 2024
crisbeto
crisbeto approved these changes Aug 26, 2024
View reviewed changes

@crisbeto crisbeto left a comment

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.

I think this logic makes sense, but will run a global presubmit just in case.

@diesieben07

diesieben07 commented Aug 26, 2024

Copy link
Copy Markdown

I just tried this out in current Angular and the behavior I described above (null means show the fallback) already exists in Angular today without any changes. The only problem is the type of projectableNodes, which does not allow null. The change introduced with this PR (as it is at the moment) alters behavior, because an empty array now means something different.

In my opinion the behavior should not be altered and instead the type of projectableNodes should be changed to correctly represent the current functionality: Array<Node[] | null>.

@devversion

devversion commented Aug 26, 2024 •
edited
Loading

Copy link
Copy Markdown
Member

I'm agreeing with @diesieben07. I've explained that in: #57480 (comment). Right now this is a breaking change. I think @crisbeto might be verifying if that is actually breaking a lot? In either case, I'd personally prefer null.

@chintankavathia

chintankavathia commented Aug 26, 2024

Copy link
Copy Markdown
Contributor Author

In what situations might a user want to skip the projection and avoid falling back to the default value? Generally, when directly using a component in a template, falling back to the default is the more common approach. Therefore, I prefer to break from this pattern rather than introducing a null value.

@crisbeto

crisbeto commented Aug 27, 2024

Copy link
Copy Markdown
Member

Passing TGP

@crisbeto crisbeto added action: merge The PR is ready for merge by the caretaker target: major This PR is targeted for the next major release labels Aug 27, 2024
@alxhub

alxhub commented Aug 27, 2024

Copy link
Copy Markdown
Member

This PR was merged into the repository by commit 7b1e5be.

The changes were merged into the following branches: main

@alxhub alxhub closed this in 7b1e5be Aug 27, 2024
@angular-automatic-lock-bot

angular-automatic-lock-bot Bot commented Sep 27, 2024

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 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@crisbeto crisbeto crisbeto approved these changes

Assignees

No one assigned

Labels

action: merge The PR is ready for merge by the caretaker area: core Issues related to the framework runtime detected: breaking change PR contains a commit with a breaking change target: major This PR is targeted for the next major release

Projects

None yet

Milestone

Backlog

Development

Successfully merging this pull request may close these issues.

Default ng-content fallback doesn't work with custom elements or dynamic components using projectableNodes

5 participants

@chintankavathia @devversion @diesieben07 @crisbeto @alxhub