Open atao60 opened 6 years ago
ardatan
commented
6 years ago This is not expected behaviour, because angular compilers only processes TypeScript files, but HTML and SCSS compilers can work in same way, so you can use same syntax with the modification that is done by TypeScript compiler in angular-compilers.
Could you try to add vanillajs version of the code below;
@Component({
moduleId: module.id,
...
})
atao60
commented
6 years ago @ardatan Thank you! It works fine now.
I had to add it on any component where a short path is used. Same thing with the pathes to scss files.
PS. I updated my previous post with error messages displayed on the browser console after a very long time.
ardatan
commented
6 years ago I think there is a wrong path in a source file, because when there is one, it sends index.html as default for 404. After that, this causes recursion by bootstrapping app again and again ( we couldn't find a proper way to handle this ). So you need to check the path of html and scss files.
atao60
commented
6 years ago I checked all of the 5 pathes of html and scss files existing in the code of atao60/meteor-angular-ionic: there are all fine.
AFAIU, no needs to search for a wrong path. Even if it seems Angular doesn't promote anymore the usage of 'moduleId', it's well documented, see e.g. Component-Relative Paths in Angular which among others states:
We might expect that ./header.component.html is a path relative to the header.component.ts file and that component-relative paths should work, right?
Instead, we get another 404 - Not found - Exception.
that is exactly the observed behavior.
As I'm happy with the moduleId workaround, do we need to keep the present issue open?
ardatan
commented
6 years ago Thank you for your collaboration!
Angular CLI was firstly designed to use with SystemJS. SystemJS loads modules by their path properly, but Angular couldn't have recognized those path in order to load template and style files by their path via XHR like SystemJS. To solve this, moduleId has been used a while. However, this property is still available and not deprecated.
After Angular CLI switched to Webpack, Webpack loaders started to replace templateUrl and styleUrls syntax with CommonJS's require or ES2015's import syntax, and that method is tricky.
All these are from Angular CLI strategy, but we are not using Angular CLI. We don't have to use Angular CLI's way to compile TS or JS files. We are using moduleId instead of making Meteor's bundler(which was really slow because of that) busy by dealing with asset files like Webpack.
I cannot see any official promotion level of Angular in the unofficial post you added your comment.
That's why, html-compiler and scss-compiler work independently from typescript-compiler in development mode to make them asyncronized and faster. html-compiler and scss-compiler adds html and scss files for Angular to be accessed via XHR, but here is the known issue; if Angular couldn't find them, it gets bootstrap/home page by Meteor's default page fallback(this is my thought about the reason of infinite loop).
Finally, we haven't designed the compiler to work with plain-JS. We need to work on this to give support for plain JS.
Stay tuned!
When reporting a bug, please be sure to include the following:
angular-meteoryou're using, and the platform(s) you're running it onbug?
A working demo is available on atao60/meteor-angular-ionic. This demo is based on Angular Meteor bare. All the code (but the tests) is in plain JS, even the annotations (Component, NgModule,...)
As soon as a path such as:
is replaced by:
the associated part of the view isn't correctly displayed.
Is this the expected behavior with vanilla JS w/o "@" annotations, ie full pathes required?
Should it be possible to keep the same behavior than with TS and "@" annotations, ie short pathes accepted?
dev config
UPDATE
After a very long time, error messages are displayed on the browser console: