New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Angular Elements - status + roadmap #20891

Closed
MickL opened this Issue Dec 8, 2017 · 64 comments

Comments

@MickL

MickL commented Dec 8, 2017

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Feature request
[X] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Description

Angular Elements sounds pretty awesome. I would love to know what the status is, what the roadmap looks like and when to expect a pre-release and a release candidate.

Latest news we(the community) got was from november 2017 on Angular Connect by @robwormald

bildschirmfoto 2017-12-08 um 14 43 53

Also what about browser support?

Other

In addition it would be awesome to let the community know about the status and roadmap of other upcoming stuff, too. For example i know from Angular Connect that @ocombe is working full time on improved i18n. Also @filipesilva (?) is working on Angular libraries which seem to be highly requested, too. It would be awesome for the community to have a page on angular.io(or GitHub) where to see the current backlog/roadmap of new features, the status, the effort put in, and maybe some vague dates when to expect a release candidate.

@jenniferfell

This comment has been minimized.

Contributor

jenniferfell commented Dec 19, 2017

@robwormald Per our DM, assigned to you to consider. Thanks.

@lijumathews

This comment has been minimized.

lijumathews commented Jan 9, 2018

Waiting to use this feature too

@pstrh

This comment has been minimized.

pstrh commented Jan 9, 2018

We hope to implement a micro frontend architecture with Angular Elements, e.g. combine several Angular-based elements/application in one page. Therefore the question: will it be possible to combine several Angular versions on one page with Angular elements? It would be great if this question and the possible impact are addressed in the documenation.

@skreborn

This comment has been minimized.

Contributor

skreborn commented Jan 9, 2018

@pstrh I would assume that since Angular Elements creates a sandbox for itself and is bound to its host element, you would be able to use different Angular versions just like you could use any other framework for the other elements on your page. Different elements shouldn't need to know what code controls the others.

@baldwindc

This comment has been minimized.

baldwindc commented Jan 17, 2018

+1 that a general release date / roadmap would be helpful.

@mlc-mlapis

This comment has been minimized.

mlc-mlapis commented Jan 17, 2018

@skreborn ... can you describe your idea how it would be possible to mix different versions and keep also a reasonable size of the whole?

@baldwindc

This comment has been minimized.

baldwindc commented Jan 17, 2018

For a playground to learn Angualr Elements, how up to date is https://github.com/robwormald/angular-elements?

I'm having trouble finding many articles or resources about angular-elements other than "Here's what we want it to do." It's intended purpose is exactly what my organization is in the beginning phases of doing at the moment. I'm currently attempting to convert our existing angular 1.6 app over to use https://github.com/CanopyTax/single-spa.

  • Is angular-elements being developed internally (or is there an open-source alpha build somewhere I can examine)?
  • (expounding from my previous comment): When can we expect to see a beta release?
  • Will this allow older versions of angular to be built incorporated into the angular-elements "microframwork"?
@skreborn

This comment has been minimized.

Contributor

skreborn commented Jan 17, 2018

@mlc-mlapis I have been thinking about the size implications myself, and I have honestly no idea how this could be done while also keeping reasonable constraints on bundle sizes. With each version that you use, you'll have to load the entire bundle separately. I didn't say that it would be a good idea to mix different angular versions, only that I suppose that they could theoretically work side-by-side without interfering with one another.

@mlc-mlapis

This comment has been minimized.

mlc-mlapis commented Jan 17, 2018

@skreborn ... ok, I just wanted to confirm if you have any background idea that would change the game. 😄 My seeing is that it is a general limitation ... and I would be surprised a lot if any extra solution appears. Actually I think that if you want to use several components with a minimum footprint you have to do a similar step as CLI tree-shaking elimination does today ... to generate a minimal shared lib which would contain only the absolutely necessary parts from standard Angular libs ... so it is logical that using of the same Angular version is a must.

@robwormald

This comment has been minimized.

Member

robwormald commented Jan 19, 2018

Updates on this: we're targeting v6 for an initial, experimental release of elements. We'll be validating it with Angular.io, and aim to solve that use case first.

We'll get more into details as we get closer to release. Feel free to ask questions in here - can't promise I'll answer them all, but we are watching and capturing use cases.

Conceptually, Elements (or at least, the initial implementation) is pretty straightforward, and doesn't really change too much about Angular. In parallel, there's major work happening on the view engine, and our early numbers are extremely promising in terms of code size. Again, v6 is mainly foundational work - post v6 will see some very interesting things happen that we'll talk more about soon.

Please keep in mind this is a Labs project, and as such we make no guarantees on ship dates, functionality, etc. We know plenty of people are excited about this (as are we!), and our aim is to get something useable into devs hands sooner than later, so we can learn and iterate - but understand that things may not be as batteries-included as stable angular APIs. Support in CLI and such will come, but you may have to roll your own webpack config (or similar) in the short term.

Stay tuned!

We hope to implement a micro frontend architecture with Angular Elements, e.g. combine several Angular-based elements/application in one page. Therefore the question: will it be possible to combine several Angular versions on one page with Angular elements? It would be great if this question and the possible impact are addressed in the documenation.

In theory, yes, but this is not ideal. This is part of the experimental process, but (along with upcoming view engine changes) I would hope that running multiple versions would be unnecessary.

@pstrh I would assume that since Angular Elements creates a sandbox for itself and is bound to its host element, you would be able to use different Angular versions just like you could use any other framework for the other elements on your page. Different elements shouldn't need to know what code controls the others.

This is conceptually correct indeed, but again, not ideal.

For a playground to learn Angualr Elements, how up to date is https://github.com/robwormald/angular-elements?

It's not - it was purely a proof of concept. It's a reasonably similar approach - the thing to understand about it is that it's not anything magical - it would be possible for any developer to write a similar layer (so if you need something like this RIGHT NOW, it would be worth reading and understanding...) - it doesn't require any support from angular's compiler.

The current codebase is on the labs/elements branch - https://github.com/angular/angular/tree/labs/elements/packages/elements/ but we expect to merge it to master shortly, pending initial docs.

m having trouble finding many articles or resources about angular-elements other than "Here's what we want it to do." It's intended purpose is exactly what my organization is in the beginning phases of doing at the moment. I'm currently attempting to convert our existing angular 1.6 app over to use https://github.com/CanopyTax/single-spa.

This is why this falls under Angular Labs - we want to be open about what we're doing, but set the expectation this is not production ready yet. We'll have some basic docs for the initial release, and full documentation and integration when it graduates from Labs status.

Is angular-elements being developed internally (or is there an open-source alpha build somewhere I can examine)?
(expounding from my previous comment): When can we expect to see a beta release?

See above

Will this allow older versions of angular to be built incorporated into the angular-elements "microframwork"?

I'm not sure I understand this question - it's unlikely we'll do any backwards facing work on Elements, but again, there's nothing "special" about elements, so if it's something you'd require, it would likely be possible to do yourself. Hint: Angular Elements and NgUpgrade (specifically, downgrade) are basically doing the same thing - bridging Angular's API to the Custom Elements spec and AngularJS APIs, respectively.

@mlc-mlapis I have been thinking about the size implications myself, and I have honestly no idea how this could be done while also keeping reasonable constraints on bundle sizes. With each version that you use, you'll have to load the entire bundle separately. I didn't say that it would be a good idea to mix different angular versions, only that I suppose that they could theoretically work side-by-side without interfering with one another.

I'm not going to quote any numbers, but suffice to say, we're reasonably confident that within the next couple major versions of Angular, bundle size should be the least of your concerns. More on that later :)

@ngbot ngbot bot added this to the Backlog milestone Jan 23, 2018

@alshdavid

This comment has been minimized.

alshdavid commented Jan 24, 2018

Holding my breath for this. Looking for updates on the progress every second day.

My team want to move to Vue from Angular 1.6. My hope is that the ability to integrate Angular Elements into the existing codebase (easing the transition to Angular) will shift the decision in favour of Angular over Vue.

If the release of v6 is reported to be around March/April and you're planning a progress report on Elements around that time, I know how much time I need to buy. 😄

@MickL

This comment has been minimized.

MickL commented Jan 24, 2018

I think Elements could really really push Angular alot. But we also need the ability to create libraries easy as soon as possible. Anyway the main problem is that the community is not getting updated. We dont know what you guys are working on and when to expect something but it really is import for our projects to plan. @robwormald @filipesilva @ocombe

@ocombe

This comment has been minimized.

Contributor

ocombe commented Jan 24, 2018

If you look into the milestone for Angular v6: https://github.com/angular/angular/milestone/81
There's a task for Angular Elements MVP: #21573 that you can follow.

@MickL

This comment has been minimized.

MickL commented Jan 24, 2018

Ok thank you. I am just saying that NOW we got informations on Elements and i18n but we had to ask for it for long time. And also they are in the middle of long issues. It would be great to have a place where to see what to expect from Angular in the future, what is currently in work, what has priority, what is experimental etc etc. E.g. a summarization of your presentation on Angular Connect + the updates in the issue. Same goes for Elements and libraries. And this are only the three things i know i bet there is much more going on.

So e.g. @robwormald said something about that bundle size will not be a concern for us in the future. If thats actually the case why dont you make it already public? So for example if someone says "Vis only got x KB and Angular got 4*x. Lets prefer Vis since bundle size is our highest priority" we could respond "Yes but the Angular team is doing so much incredible work, look at this schedule they even plan to half the size with the next release. And also they are working on ... and ..."

@ocombe

This comment has been minimized.

Contributor

ocombe commented Jan 24, 2018

I understand your concern, and I've asked the same question last week to the team. The reply was that when you make announcements, even if you're being cautious, people will take what you say for a fact. If it works out as you said, it's nice and everyone is happy, but that's rarely the case in development, things get postponed because other things take the priority, or things get canceled because it didn't work or issues arise that you didn't anticipate, etc...
The point is that even if you say that it's an estimation, if it changes some people will get angry because they took what you said for granted and planed accordingly (for a project, for a business, etc...).
Let's say that we announce "Angular Elements will be released in March", and you had convinced your boss to use this for the next project instead of Vue (like @alshdavid wants to do), and it turns out that in March it's not ready, it's buggy, or we had to postpone because we need to finish something else first. Then your boss comes to you and blames you, and in return you'll blame the Angular team.

At Angular Connect, I was so sure that we would get runtime i18n and code translations done for 5.3 that I said that during my talk. We were making good progress, we had design docs and we were working on it already so I had high hopes.
It turns out that some core changes (new Renderer) will make our work much easier, but also obsolete if we had finished that part before. So we decided to wait a little and work on runtime i18n with the new renderer. It postponed that to v6 instead of 5.3, but it's for the best.
Now apparently no one has blamed me for the delay this time, but it could have happened and I would have felt terrible (even if it was not really my fault and it was for the best).

That's why we cannot make announcements like that. From what I've heard, we will try our best in the future to share our roadmap and we work on, and probably that hiring a new devrel will also help for the communication (Rob & Stephen already have a lot of ground to cover).

I hope that you understand our position as well. As a developer I really really want to share some of the new and exciting stuff that we have planned, and to give you actual numbers for the new bundle size, but I cannot in good conscience do that for now. Not because you wouldn't understand if it turns out differently, but because someone else might. Someone who would then write a blog post telling the world how Angular sucks and how xxx is much better because at least they actually have done yyy instead of telling people that it would happen and not make it in the end. It would hurt Angular as a whole, and our community and that's not what we want.

@johnfabian

This comment has been minimized.

johnfabian commented Mar 8, 2018

Will Angular Elements even the experimental release version work with SharePoint 2016 and SPFX, with multiple instances on the page? This is the most important feature my team needs!

@sandangel

This comment has been minimized.

sandangel commented Mar 9, 2018

@johnfabian does it work with vanilla js and html? if it does, angular element will work too

@jared-christensen

This comment has been minimized.

jared-christensen commented Mar 9, 2018

This might be a crazy question, but could I use an angular element inside of another angular app? I tried it but I get an error. "Uncaught Error: Zone already loaded."

@sandangel

This comment has been minimized.

sandangel commented Mar 9, 2018

@jared-christensen could you share your demo?

@manfredsteyer

This comment has been minimized.

manfredsteyer commented Mar 12, 2018

@jared-christensen It's possible. But you have to make sure to load the polyfills including zone.js only once into the browser. For sth like this, I'm using a webpack build excluding the polyfills: https://www.softwarearchitekt.at/post/2018/01/14/microservice-clients-with-web-components-using-angular-elements-dreams-of-the-near-future.aspx

@DaSchTour

This comment has been minimized.

DaSchTour commented Apr 17, 2018

@robwormald I think it's important to create comprehensive documentation for all this topic. The current documentation about angular elements is very basic and doesn't tell about any of this restrictions. I think there is a great danger, that angular elements will raise high expectations and will disappoint people because of bad documentation. There are many people that will not that didn't dive that deep into this topic and read more than just the documentation.

@idibidiart

This comment has been minimized.

idibidiart commented Apr 24, 2018

Does anyone have any feedback on this demo and its limitations if any?

https://github.com/wishtack/wt-angular-elements-demo

I'm looking to use this pattern for a complex Angular component that will be shared as a Custom Element and used in React, Ember and other places. Whether it'll be 200K or 300K in size it doesn't matter to me because that component takes up most of the page anyway, and is almost an app in itself.

To make things more challenging, I am completely new to Angular, a refugee/convert from React land.

Cc: @robwormald

@jenniferfell

This comment has been minimized.

Contributor

jenniferfell commented May 3, 2018

@jbogarthyde As we assess our backlog, would you please review this and work with @robwormald and @andrewseguin to write up an elements doc backlog? We can talk more offline. Thanks!

@pkerblaze

This comment has been minimized.

pkerblaze commented May 16, 2018

To inform, I had the same problem with Uncaught Error: Zone already loaded. but the custom element was working. When I removed the polyfill.ts from the build process (see: https://angularfirebase.com/lessons/angular-elements-quick-start-guide/ and #23732 (comment)) I got a new error Uncaught Error: In this configuration Angular requires Zone.js and the custom element was no more working.

This use case is when you load the script inside the DOM

<body>
  <app-root></app-root>
  <script src="assets/custom-element.js"></script>
</body>

But if you remove the script from the DOM and insert it into the consumer building time (angular.json) without polyfills.ts during the build process of the custom element, it work without error (didn't try for multiple custom elements) :

"projects": {
    "custom-element-consumer": {
      // ..
      "architect": {
        "build": {
            // ...
            "scripts": [
               "src/assets/custom-element.js"
            ]
            // ...

So you can use a Custom element inside another angular app, but you need to add it at build time and not at runtime for the moment, hope it'll help people who want to try it or if someone find a way to add it at runtime without error !

@DaSchTour

This comment has been minimized.

DaSchTour commented Jun 27, 2018

I'm really more interested in the other way. How to get a small JS for a webcomponent out of angular.
I really miss some more documentation and support from @angular/cli.
I made a proposal how I would expect it to work on angular/cli repo angular/angular-cli#8988

@MickL

This comment has been minimized.

MickL commented Jun 27, 2018

I guess this will be possible and documentated not before Angular 7 and the Ivy renderer.

@DaSchTour

This comment has been minimized.

DaSchTour commented Jun 27, 2018

That's really bad and frustrating as I'm losing traction on this. Angular has so many great features but I can't sell the internally because they are documented very poorly. And recently I also heard the argument, that projects like to use Vue over Angular because Vue has better documentation. I really hope to get additional arguments why we should use Angular over Vue but it get's harder and harder with this kind of incomplete documentation.

@MickL

This comment has been minimized.

MickL commented Jun 27, 2018

We are talking about future proposals. Personally i would prefer them to work on the new features instead of on documentation for something thats not even finished.

I agree that we need more informations on what they are working on and planning and maybe when to expect something. But all things that do exist are documentated or do have tons of blog posts.

There are tons of arguments for Angular and TypeScript but you should discuss this somewhere else.

@MickL

This comment has been minimized.

MickL commented Jun 27, 2018

Im closing this issue since it is no todo that can be completed. Discussions and status updates from rob are welcome!

@MickL MickL closed this Jun 27, 2018

@SimmeNilsson

This comment has been minimized.

SimmeNilsson commented Jul 16, 2018

What would be the recommended way to listen for attribute or property changes on an angular element from a non-angular outside world? Should mutation observer work?

@MickL

This comment has been minimized.

MickL commented Jul 16, 2018

Shouldnt .addEventListener('myOutput', fn) work? Or jQuery .on() or RxJs fromEvent()?

@SimmeNilsson

This comment has been minimized.

SimmeNilsson commented Jul 16, 2018

If so then I must be doing something wrong (or missed something). Should that event trigger as soon as I change a property or attribute?
Looking for something like Vue's $watch. For example, if element has a dirty flag I would like to subscribe to state change of that one.

@DaSchTour

This comment has been minimized.

DaSchTour commented Jul 16, 2018

The question is how angular is doing the attribute changes internally. If they use setAttribute then MutationObserver should work. Inside the Component you have the onChanges hook that works somehow similar to MutationObserver but from the inside of the component.

@emilio-martinez

This comment has been minimized.

Contributor

emilio-martinez commented Jul 31, 2018

Angular does what any standard built-in or custom element would do.

If the literal goal is to listen to attribute changes, then yes, you can observe DOM mutations—it's the DOM, after all! There's no Angular black magic at play—see the DOM Render implmentation, for example. However, perhaps it's best to stick with standard DOM patterns such as events. Similarly, is this regard Angular does what you'd expect from a DOM perspective—emit CustomEvents for every Output emit. Feel free to check out that implementation as well.

@playground

This comment has been minimized.

playground commented Aug 10, 2018

When I turn an existing Angular app into custom element with Angular Elements, it throws the following errors and nothing gets rendered.

Uncaught TypeError: Failed to construct 'HTMLElement': Please use the 'new' operator, this DOM object constructor cannot be called as a function.
    at NgElementImpl.NgElement [as constructor] (elements.js:391)
    at new NgElementImpl (elements.js:427)
    at new AppModule (app.module.ts:42)
    at _createClass (core.js:8213)
    at _createProviderInstance$1 (core.js:8185)
    at initNgModule (core.js:8118)
    at new NgModuleRef_ (core.js:8844)
    at createNgModuleRef (core.js:8833)
    at Object.debugCreateNgModuleRef [as createNgModuleRef] (core.js:10658)
    at NgModuleFactory_.push.../../node_modules/@angular/core/fesm5/core.js.NgModuleFactory_.create (core.js:11360)

However, if I include both props entryComponents and bootstrap in app.module.ts, everything works fine but still throws the same errors

entryComponents: [MyComponent],
bootstrap: [MyComponent]

export class AppModule {
  constructor(private injector: Injector) {
    const el = createCustomElement(MyComponent, { injector });
    customElements.define('my-custom-element', el);
  }  
  ngDoBootstrap() {}
}

The other issue I have with a different app I think it is more of an issue with jwplayer. I will post a link here at stackoverflow hope someone here will have some insights as why it fails?

@emilio-martinez

This comment has been minimized.

Contributor

emilio-martinez commented Aug 10, 2018

@playground not quite sure what you mean by "everything works fine but throws the same errors", but otherwise the error you got is a fairly common custom elements error:

As a bit of background, the custom element spec (https://html.spec.whatwg.org/multipage/scripting.html#custom-element-conformance) outlines that only ES2015 classes may be passed to customElements.define. Of course, it's still very common to serve ES5 due to browser support, so most people will ship ES5-style custom element classes, as is likely your case.

The thing to be aware of here is that browsers that natively support customElements.define still expect ES2015 classes and will not take ES5-style classes because they don't properly extend classes like HTMLElement. To work around this, you will want to use the ES5 custom elements adapter (https://github.com/webcomponents/webcomponentsjs/blob/master/README.md#custom-elements-es5-adapterjs) that the webcompoments org ships when you're compiling to ES5. That will monkey-patch the native implementation to allow for ES5-style classes in your custom elements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment