Angular and web components

[sijakret]

Hi Everyone,

first of all - I am a big fan of the lit ecosystem. It is by far my favorite way to create components and applications for the web platform!

I am opening this thread because I am a bit desperate about the following issue:

In our organization we created a lit-based web component library. The main driver to use lit was to make the library translate across different tech stacks.
Now, it turns out that most projects in the organization are built using Angular. Unfortunately angular is kind of a hostile environment for web components.

If you want to use web components in angular, you need to enable a CUSTOM_ELEMENTS_SCHEMA that essentially opts out of all type checks for components with dash-style-names (including angular components). This is a big drawback during development since you lose quite some static checks there.

There are really no technical reason for this but its mainly due to the fact that the angular compiler has a hardcoded (kid you not) dictionary of known html tags and their props that is not extensible. I have been trying to keep a discussion alive and also sketched out solutions to fix it in angular with limited success.

In my organization people are now resorting to writing angular wrappers that host the web components which somehow feels really wrong. It adds an additional indirection, is just one more thing to maintain and kind of defeats the purpose of web components.

The point I am trying to get to is:

My understanding is that both lit and angular are technologies driven by google. My understanding is also that web components are seen as kind of a future-proof way to create reusable modules on the web. The reality is, however that many enterprise applications use Angular and currently it is really impractical to use a web component library in angular.
Web components are pretty much a prefect fit for design systems for organizations but as long as angular does not provide a viable path to use them there will always be people arguing against them for that very reason.
You cannot imagine the amount of discussions we are having on this topic. If it wasn't for a handful of people my org would have dropped web components already.

So, since everyone here works at google, is there anything you guys can do to help push this integration? It would get a lot of discussions out of the way and would likely also give web component adoption a boost. :)

What are your thoughts?
How can we generate some traction here?

[damsalem]

Someone sent me to read this discussion, it seems valid according to the Angular docs.

After some digging, I'm thinking this implementation should solve that https://manuel-rauber.com/2021/02/23/youre-using-custom_elements_schema-wrong/

[sijakret]

This is a workaround and not a real solution. To write a wrapper you need to

• redeclare the component API in angular
• accept an additional layer in angular that does unnecessary stuff at runtime
• deal with angular which should not be necessary in the first place when publishing a design system built as web components

Of course this approach can be handled to a large extent using code generation. But why? It is pure overhead. This issue should be solved on the angular side and not on the WC side! I have made several arguments in the thread over at angular on why I think so and why I think it should not be hard.

[drk-mtr]

I would also like to understand how to get proper type checking, such that the compiler will tell me if I try to set a value for a property that does not exist on the web component. I find it rather bizarre that there's a way to generate custom elements from Angular components, but seemingly no way to import them that results in a nice developer experience.

One thing I've just found out: if the tsconfig.json for the Angular project has "moduleResolution": "node" under compilerOptions then I was not getting intellisense when importing web components from the web component library. When I set this to "moduleResolution": "bundler", things start working as expected.

I'm still not sure exactly why this is the case, and whether this would be more appropriate in the Angular docs or in some Lit "integrating with other frameworks" guide.

[withinsight]

I similarly have product teams saying they'll be missing things like dependency injection and directives when adopting Web Components. Its mind-boggling the Angular team hasn't worked on an interface to allow custom Angular things to work with Web Components built in Lit. Custom Elements was kind of the reverse (i.e. start with Angular and convert them to WC's, but you have to take the larger footprint of Angular in this scenario. The reverse, enabling Lit components to be used in an Angular app, and engineers being able to use their existing directives or dependencies seems like it would be helpful. Although, I'm not sure if its just overkill.

[irfanullahjan]

The wrapper approach doesn't sound right to me. In my opinion, the web components should be consumed in the frameworks directly. The type-safety should be the job of Angular/Vue/React compiler.

With JSX, the situation is a bit better. Angular doesn't work with JSX unfortunately. So in Angular templates, things like autocompletion should be provided by the Angular Language service extension, in VSCode for example.