search

CastawayLabs / ng2-skel

Angular2 front-end development skeleton/seed
0 stars 1 forks source link

Feedback #3

Open matejkramny opened 8 years ago

matejkramny commented 8 years ago

Remove ng2-component-loader

Limits to .component.ts files, which are a recommended standard in ng2, but some don't adhere to recommended standards (me! IMO, .component.ts is a bloated name extension).

The package also has a bug where if you have a component declaration like below:

@Component({ templateUrl: 'some.pug' })

it won't be recognised.

If you also have multiple @component declarations in the same file, you're doomed.

The package does a simple job, that is, transform templateUrl: 'string.pug' into template: 'pug template contents'. Writing the require is easier and more transparent than this loader (IMO).

webpack-dev-server

consider using this, it makes a file server from webpack and makes things easier.

polyfills

Browsers require zone.js and reflect-metadata polyfills, which should be another chunk. It can be a cached file since it doesn't change often.

es5 & ng2 compiler issues

If ng2 is transpiled to es5, you might need to use awesome-typescript-loader instead of the typescript loader. It is in angular quickstart, and solves some compiler issues with es5 compatibility.

This is mostly a debate, if you agree I can contribute the points above to the package.

zrhmn commented 8 years ago

The issue in itself is a valued contribution @matejkramny. ng2-skel is by no means complete or even stable. I need your help. Debate is good. Let's discuss these.

What do you propose should be used in place of ng2-component-loader? We need a loader that can do something similar, with better stability. Or perhaps another way to load component dependencies? We can maybe use file-loader but I initially thought compiling the style+template dependencies directly into the bundle is a plus (I can be convinced otherwise). There's also a possibility of doing something like @Component({ template: require('some.pug') }) but I don't wanna go there yet.

webpack-dev-server, yes! Although I initially thought it's unnecessary complication to the webpack config and its functionality can be easily replicated using any static file server (I used Caddy). But I'm open to using webpack-dev-server.

zone.js and reflect-metadata along with several other "constants" are part of src/vendor.ts which is compiled and passed through CommonsChunkPlugin which compiles them into a separate chunk: common.js. And it's cached too, since none of the imports in vendor.ts change, the file doesn't need to be compiled on each change.

The only reason I didn't use awesome-typescript-loader was that it wasn't the "official" TypeScript loader. But if there's problems with ts-loader I think awesome-typescript-loader is a good idea.

matejkramny commented 8 years ago

I used @Component({ template: require('some.pug') }) and its actually better. More flexibility, can include relative paths to the folder the component is in.

Sorry, I didn't see the use of polyfills (trying to merge webpack configs onto another project).