feat(content projection): component inputs accepting arrow functions returning ng-templates about angular HOT 5 CLOSED

Hey! Thnx for the suggestion - we absolutely feel the pain of working with the current content projection and dynamic template instantiation - especially for more complex cases. We do think of a project proposal / roadmap entry that would significantly improve the situation.

I'm going to close this issue as it prescribes a particular solution to one of the use-cases. But we are aware of other pain points so we should look at those more holistically. Also, should not constraint the solution space before we understand all the use-cases that need attention.

We do appreciate your input, though - this is one more indicator that we need to dig deeper into those areas.

from angular.

Just a stackblitz to summarise the current possibilities https://stackblitz.com/edit/stackblitz-starters-uoy6sf

Note: you might say that the example could be changed by introducing structural directives. This way consumer.tree would look better.

But as I see it, it's just a way to rebrande complexity and write more code: tree.component will be packed with directives and consumer.tree will use more advance concepts.

IMHO making a closer in tree.component over consumer.tree arrow func inputs is the most natural / easy / elegant way to solve the problem.

My 2 cents!

from angular.

Umh... I wonder if the "content projection and content queries unification" (see #37319) could be partially rephrased using this proposal: use inputs to pass content to project (in the form of input:template or input:arrowFunc_returning_template).

It seems to work for some common problems:

• Was the content provided at all? => Was the input provided?
• How many items were provided? => Define inputs in a way that fulfils the need.

Maybe I'm missing something very important / obvious (ng-content is more performant, CD would be a mess, ...). But the new (typed) signal inputs are pretty powerful / flexible. And reducing complex projection scenarios to "variables to pass as inputs", seems to simplify problems. Anyway, the syntax should be beautified (it's a bit ugly with <ng-template>).

Ok... just a comment (hopefully useful) for the future! 😅

from angular.

Sure np! Perfectly aware that it was a partial solution.

Just last personal suggestion considering I often work with "react" guys: do not underestimate the power of changing ng content projection in a way that results familiar for the react community (on top of making it better for the ng one 😃). IMO it can increase the rate of react devs giving angular another successful try... and of course make the creation of "component libs" easier.

I'm perfectly aware you're busy with several big tracks... and the ng community is often focus on SFC / classes / decorators while comparing frameworks (myself included 😅). But I think this might be a less mainstream point with a potentially high ROI for angular adoption!

Just my 2 cents! And as usual, thanks a lot for your work!

from angular.

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.}

from angular.