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

Need JitCompilerFactory in Angular 5 #20125

Closed
jackzard opened this Issue Nov 3, 2017 · 22 comments

Comments

Projects
None yet
@jackzard

jackzard commented Nov 3, 2017

I'm submitting a...


[ x] Feature request

Current behavior

no factory for JitCompilerFactory like Angular 4

Expected behavior

export JitCompilerFactory in Angular 5 or alternative

Example code in Angular 4


import {CommonModule} from '@angular/common'
import {Compiler, NgModule} from '@angular/core'
import {JitCompilerFactory} from '@angular/compiler'
import {DynamicComponent} from './dynamic.component'
import {DynamicComponentModule} from './dynamic.module'

export function compilerFactory() {
    return new JitCompilerFactory([{useDebug: false, useJit: true}]).createCompiler()
}

@NgModule({
    imports: [
        CommonModule,
    ],
    declarations: [
        DynamicComponent
    ],
    exports: [
        DynamicComponent
    ],
    providers: [
        DynamicComponentModule,
        {provide: Compiler, useFactory: compilerFactory}
    ],
})
export class DynamicModule {
}

Environment


Angular version: 5.0.0
 
For Tooling issues:
- Node version: 8.4.0
- Platform:  Windows

@jackzard jackzard changed the title from Need JitCompilerFactory to Need JitCompilerFactory in Angular 5 Nov 3, 2017

@p3x-robot

This comment has been minimized.

Show comment
Hide comment
@p3x-robot

p3x-robot Nov 3, 2017

they are using it like this, this is bullshit:

import { ɵa } from '@angular/platform-browser-dynamic';

p3x-robot commented Nov 3, 2017

they are using it like this, this is bullshit:

import { ɵa } from '@angular/platform-browser-dynamic';
@sarunint

This comment has been minimized.

Show comment
Hide comment
@sarunint

sarunint Nov 3, 2017

Contributor

Everything in @angular/compiler is not part of the public API and changes are subjected to happen.

Contributor

sarunint commented Nov 3, 2017

Everything in @angular/compiler is not part of the public API and changes are subjected to happen.

@maximusk

This comment has been minimized.

Show comment
Hide comment
@maximusk

maximusk Nov 3, 2017

I'd add that we need either JIT compiler that uses decorator or AOT compiler that uses static analysis, but in runtime

maximusk commented Nov 3, 2017

I'd add that we need either JIT compiler that uses decorator or AOT compiler that uses static analysis, but in runtime

@trotyl

This comment has been minimized.

Show comment
Hide comment
@trotyl

trotyl Nov 3, 2017

Contributor

@maximusk That's being discussed at #15510 & #15275, we don't need duplicate issue for tracking.

Contributor

trotyl commented Nov 3, 2017

@maximusk That's being discussed at #15510 & #15275, we don't need duplicate issue for tracking.

@maximusk

This comment has been minimized.

Show comment
Hide comment
@maximusk

maximusk Nov 3, 2017

@trotyl , I didn't create the issue. So do you know what Angular team plans to do with the compiler? I saw a doc once that stated that there were plans to move to AOT runtime

maximusk commented Nov 3, 2017

@trotyl , I didn't create the issue. So do you know what Angular team plans to do with the compiler? I saw a doc once that stated that there were plans to move to AOT runtime

@trotyl

This comment has been minimized.

Show comment
Hide comment
@trotyl

trotyl Nov 3, 2017

Contributor

@maximusk AFAIK there's no plan for runtime AOT (if you mean AOT editor, that's already in progress at edit.ng), but most of it solves could be covered by @angular/elements, which is based on the dynamic template solution used in angular.io.

Contributor

trotyl commented Nov 3, 2017

@maximusk AFAIK there's no plan for runtime AOT (if you mean AOT editor, that's already in progress at edit.ng), but most of it solves could be covered by @angular/elements, which is based on the dynamic template solution used in angular.io.

@maximusk

This comment has been minimized.

Show comment
Hide comment
@maximusk

maximusk Nov 3, 2017

@trotyl , just checked the sources:

import {NowCardFeedNgFactory} from '../../ngfactory/src/demos/now-cards/now-card-feed.ngfactory'
nge.define(NowCardFeedNgFactory);

it imports pre-compiled factory. No runtime compilation. Can you maybe clarify what approach exactly from @angular/elements can be used?

maximusk commented Nov 3, 2017

@trotyl , just checked the sources:

import {NowCardFeedNgFactory} from '../../ngfactory/src/demos/now-cards/now-card-feed.ngfactory'
nge.define(NowCardFeedNgFactory);

it imports pre-compiled factory. No runtime compilation. Can you maybe clarify what approach exactly from @angular/elements can be used?

@trotyl

This comment has been minimized.

Show comment
Hide comment
@trotyl

trotyl Nov 3, 2017

Contributor

@maximusk Angular Elements will wrap your Angular component into a web component, possibility you can have a look of the introduction in Angular MIX, which can demonstrate it clearly.

Contributor

trotyl commented Nov 3, 2017

@maximusk Angular Elements will wrap your Angular component into a web component, possibility you can have a look of the introduction in Angular MIX, which can demonstrate it clearly.

@maximusk

This comment has been minimized.

Show comment
Hide comment
@maximusk

maximusk Nov 3, 2017

@trotyl, thanks, I've watched the talk and get the idea behind the @angular/elements, however, I haven't found anything related to the runtime compilation in the sources. As I understand it's still a concept that's why it imports compiled factory instead of compiling the component.

maximusk commented Nov 3, 2017

@trotyl, thanks, I've watched the talk and get the idea behind the @angular/elements, however, I haven't found anything related to the runtime compilation in the sources. As I understand it's still a concept that's why it imports compiled factory instead of compiling the component.

@gkalpak

This comment has been minimized.

Show comment
Hide comment
@gkalpak

gkalpak Nov 3, 2017

Member

I think there is some confusion here. Neither angular.io nor @angular/elements deal with aot-vs-jit compilation. (Both can work with either and prefer aot for the known reasons 😁)

Member

gkalpak commented Nov 3, 2017

I think there is some confusion here. Neither angular.io nor @angular/elements deal with aot-vs-jit compilation. (Both can work with either and prefer aot for the known reasons 😁)

@trotyl

This comment has been minimized.

Show comment
Hide comment
@trotyl

trotyl Nov 3, 2017

Contributor

Sorry for not make it clear, I'm just talking about using dynamic HTML with Angular components in runtime, not runtime AOT.

Contributor

trotyl commented Nov 3, 2017

Sorry for not make it clear, I'm just talking about using dynamic HTML with Angular components in runtime, not runtime AOT.

@maximusk

This comment has been minimized.

Show comment
Hide comment
@maximusk

maximusk Nov 3, 2017

@gkalpak , @trotyl

Let's clarify what we're talking about here. You can have a string like this:

@Component({
   template: `<span>generated on the fly: {{name}}</span>`
});
class MyComp {}

and we want to generate compiled component factory (mycom.ngfactory) to work with dynamic components as explained in this article.

This factory can be generated by Angular View Compiler which takes component metadata (template etc) as an input. This metadata can be obtained using either JIT or AOT compiler. JIT compiler requires evaluation of the code so that Component decorator gets executed and attaches metadata to a class which is then retrieved by JIT compiler. AOT compiler doesn't need evaluation and works with AST produced by TypeScript (through transforms as I understand in the v5). So when I said:

I'd add that we need either JIT compiler that uses decorator or AOT compiler that uses static analysis, but in runtime, not build time

I meant that we need any of the two to be able to produce factory in runtime (not build time) on demand if the component template is unknown during build.

maximusk commented Nov 3, 2017

@gkalpak , @trotyl

Let's clarify what we're talking about here. You can have a string like this:

@Component({
   template: `<span>generated on the fly: {{name}}</span>`
});
class MyComp {}

and we want to generate compiled component factory (mycom.ngfactory) to work with dynamic components as explained in this article.

This factory can be generated by Angular View Compiler which takes component metadata (template etc) as an input. This metadata can be obtained using either JIT or AOT compiler. JIT compiler requires evaluation of the code so that Component decorator gets executed and attaches metadata to a class which is then retrieved by JIT compiler. AOT compiler doesn't need evaluation and works with AST produced by TypeScript (through transforms as I understand in the v5). So when I said:

I'd add that we need either JIT compiler that uses decorator or AOT compiler that uses static analysis, but in runtime, not build time

I meant that we need any of the two to be able to produce factory in runtime (not build time) on demand if the component template is unknown during build.

@trotyl

This comment has been minimized.

Show comment
Hide comment
@trotyl

trotyl Nov 3, 2017

Contributor

@maximusk I guess it's clear now, but still seems a duplication to me.

Contributor

trotyl commented Nov 3, 2017

@maximusk I guess it's clear now, but still seems a duplication to me.

@mlc-mlapis

This comment has been minimized.

Show comment
Hide comment
@mlc-mlapis

mlc-mlapis Nov 3, 2017

@trotyl ... you are right ... but the main problem here is that for R5 there is just minimum or none info about that thing ... and I mean not only the exact code but also no conceptual idea for today or the nearest future. We all know that AOT mode is the right way but today there are still real edge cases where it is really the only way to compile some part of template on-demand in run-time ... and it could be fine ... why not in fact ... if you accept all factors that limit you from performance or sizing point of view.

mlc-mlapis commented Nov 3, 2017

@trotyl ... you are right ... but the main problem here is that for R5 there is just minimum or none info about that thing ... and I mean not only the exact code but also no conceptual idea for today or the nearest future. We all know that AOT mode is the right way but today there are still real edge cases where it is really the only way to compile some part of template on-demand in run-time ... and it could be fine ... why not in fact ... if you accept all factors that limit you from performance or sizing point of view.

@trotyl

This comment has been minimized.

Show comment
Hide comment
@trotyl

trotyl Nov 3, 2017

Contributor

@mlc-mlapis I didn't mean the request itself is wrong, but just the content is duplicate.

Actually there're many problem about the expansibility of Angular view layer. For example: https://github.com/angular/angular/blob/master/packages/core/src/view/refs.ts#L196-L197, the signature is said to be ViewRef while the real requirement being ViewRef_, so user cannot simply make its own ViewRef by what the type definition is.

There could be several requests like: Open compiler API, open view engine API, make Angular's view layer really expansible by not hacking any more... All of them could be valid, but should still follow the way of working (fill the template, no dup, ...)

Contributor

trotyl commented Nov 3, 2017

@mlc-mlapis I didn't mean the request itself is wrong, but just the content is duplicate.

Actually there're many problem about the expansibility of Angular view layer. For example: https://github.com/angular/angular/blob/master/packages/core/src/view/refs.ts#L196-L197, the signature is said to be ViewRef while the real requirement being ViewRef_, so user cannot simply make its own ViewRef by what the type definition is.

There could be several requests like: Open compiler API, open view engine API, make Angular's view layer really expansible by not hacking any more... All of them could be valid, but should still follow the way of working (fill the template, no dup, ...)

@mlc-mlapis

This comment has been minimized.

Show comment
Hide comment
@mlc-mlapis

mlc-mlapis Nov 3, 2017

@trotyl ... yeap, so many open areas ... but especially ViewRef_ / ViewRef story is not a new thing, if I remember ... would be interesting to review the whole evolution path maybe to understand all factors.

mlc-mlapis commented Nov 3, 2017

@trotyl ... yeap, so many open areas ... but especially ViewRef_ / ViewRef story is not a new thing, if I remember ... would be interesting to review the whole evolution path maybe to understand all factors.

@claygifford

This comment has been minimized.

Show comment
Hide comment
@claygifford

claygifford Nov 6, 2017

how about you just add it... and move on.
Cannot upgrade to angular 5 until you add this feature

claygifford commented Nov 6, 2017

how about you just add it... and move on.
Cannot upgrade to angular 5 until you add this feature

@ocombe ocombe self-assigned this Nov 15, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 16, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 16, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 16, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 16, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 16, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 16, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 17, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 17, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 17, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 17, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 17, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 17, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 17, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 21, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 21, 2017

ocombe added a commit to ocombe/angular that referenced this issue Nov 21, 2017

@mhevery mhevery closed this in d7a727c Nov 22, 2017

@Sky4CE

This comment has been minimized.

Show comment
Hide comment
@Sky4CE

Sky4CE Nov 27, 2017

After upgrading to Angular 5.1.0-beta.2 I still have error:
image

Sky4CE commented Nov 27, 2017

After upgrading to Angular 5.1.0-beta.2 I still have error:
image

@ocombe

This comment has been minimized.

Show comment
Hide comment
@ocombe

ocombe Nov 27, 2017

Contributor

You should not use it as a constructor, use the injector instead. See my comment here: #20639 (comment)

Contributor

ocombe commented Nov 27, 2017

You should not use it as a constructor, use the injector instead. See my comment here: #20639 (comment)

@VSmirnov17

This comment has been minimized.

Show comment
Hide comment
@VSmirnov17

VSmirnov17 Nov 28, 2017

I have 2 errors:
selection_153
selection_154

Errors occur when I build project with --aot (ng serve --aot)
If not --aot - all good

VSmirnov17 commented Nov 28, 2017

I have 2 errors:
selection_153
selection_154

Errors occur when I build project with --aot (ng serve --aot)
If not --aot - all good

@ocombe

This comment has been minimized.

Show comment
Hide comment
@ocombe

ocombe Nov 28, 2017

Contributor

If you have a problem post the comments in the issue #20639, thanks.

Contributor

ocombe commented Nov 28, 2017

If you have a problem post the comments in the issue #20639, thanks.

@claygifford

This comment has been minimized.

Show comment
Hide comment
@claygifford

claygifford Nov 28, 2017

ocombe your code does not work...

core.js:1427 ERROR Error: StaticInjectorError[JitCompiler]:
StaticInjectorError[JitCompiler]:
NullInjectorError: No provider for JitCompiler!

claygifford commented Nov 28, 2017

ocombe your code does not work...

core.js:1427 ERROR Error: StaticInjectorError[JitCompiler]:
StaticInjectorError[JitCompiler]:
NullInjectorError: No provider for JitCompiler!

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