embed views and load them using templateCache

[andreafdaf]

this is where I proposed to embed views and load them using templateCache

[mleanos]

@andreafdaf Are the tests running successfully on your local dev? It appears that the client-side tests are failing.

[mleanos]

Why was this changed?

[andreafdaf]

this is to make it a little more flexible, for example... if I have something like "...moduleName/client/directives" and I put templates and js files under the "directives" folder with the old rule they would not be found

of course one can put js from directives under js and html under views, but it makes or doesn't make sense based on just a programmer point of view... so that's why it was changed

[mleanos]

I'm not sure what the best practice in the cases of where to put the html templates for directives.. but I usually put them in my views folder. Perhaps, someone else has some insight into that. But generally, I'd be weary of making changes to a core feature like the assets locations.

[andreafdaf]

I guess you're right... maybe 'modules//client/**/.html' like is done for 'modules//client/**/.js' would be the most flexible one (and wouldn't break compatibility with code coming from an earlier version)

just to explain my point a little bit more:

• if a file is under a "client" folder and under a "views" folder why do we have to call it "viewName.client.view.html" while it could be simply "/client//views/viewName.html"
• if I create a folder "templates" to put html templates, should I call them "fileName.client.template.html"?

cannot I simply call all my views "viewName.client.view.html" and put them in the folder I want, since with templateCache IDs I know that no matter what this view is going to be "viewName"?

[mleanos]

@andreafdaf I don't know how this implementation of template cache is working. Could you explain it a bit?

Also, could the client-side tests be failing because the route configurations have changed? Also, the change of the assets client views definition might be related.

[andreafdaf]

hi @mleanos sorry but I didn't tested (hehe ._.) since it was working on browser and is a mod taken from a project already running in production so... I guess that the tests must be rewritten in some small part, tests fail in all browsers but views are correctly loaded and cached so it's just a test inner thing (template IDs probably), I guess I found a solution but have no time to work on it right now

anyway it works like that:

• suppose we have an application that grows and grows so we start having a lot of small html files here and there, some really small, and maybe we need lots of them to load a single page and the page might start loading like a puzzle (noticeable on old PCs and slow connections)
• the complex way: one might say "convert all views to JS templates, blob everything together upon build and add it as a module". If you're working with someone that lives on the HTML/CSS side of the world it gets really difficult to make them understand this and wait for a task runner to do all this work before they can see if the new text color is nice (just an example but if I can take something out from grunt/gulp, I take it out)
• so there is an easy way: we simply get all views and embed them inside the main HTML page inside script type="text/ng-template" tags and give each one an ID (this ID what is causing the test to fail btw)
• now we can continue to write down our HTML templates as normal HTML files and worry about nothing because when a user makes a request to index all HTML templates are going to be bundled as written above and will all be available to the angular app without having to make a request to the server

some performance gain and nothing changes in development (just calling templates by ID instead of by URL, that's it)

[andreafdaf]

ok tests now pass, it was a simple mod (memo to myself: read contributing guidelines more carefully)
I can try to make a couple of things more straightforward (like making the view pattern match every HTML file, or using the whole filename as ID)

anyway... this PR is just a starting point to discuss about this feature, this same result can be achieved in multiple ways so now it's up to the community to decide if it fits or not, must be changed or what ✌️

btw, I'm sorry to see that "Coverage decreased (-0.4%) to 51.842%"... how can I improve it?

[mleanos]

@andreafdaf I'm not exactly sure about the code coverage.

We could use some more eyes on this one. @codydaig @ilanbiala @lirantal @rhutchison @trainerbill @simison

[codydaig]

why do we need to concat the files if they are being loaded in individually?

[andreafdaf]

you've got your point 👍

[codydaig]

@andreafdaf Im not completely familiar with ng-template so i out a couple inline questions above. Ill have some time later today to test and play. I'll touch base afterwards and give you more through feedback.

[codydaig]

@andreafdaf So what's the difference between your approach and an approach using a gulp task like this: https://www.npmjs.com/package/gulp-templatecache?

That gulp task is currently implemented in our gulp file so I was wondering what the difference was, and what the benefits of one over the other are?

[codydaig]

@andreafdaf So the issue with putting everything inside the index.html page is that the index.html page cannot be cached because it injects the user object directly into the page. But compiling the templates into a file that get's put into the /public folder allows for production environments to cache the html files, as well as allow nginx (or similar) to server the files instead of relying on express, which is usually he preferred method in production versus relying on express.

[andreafdaf]

@codydaig I was writing something else but then you comment popped up! so what about also using https://www.npmjs.com/package/grunt-angular-templates , so that developers can have this same functionality no matter which task runner they choose to use?

[codydaig]

@andreafdaf Currently we're switching over to gulp so, I think it's fine leaving support for this on the gulp side. I apologize for the initial link, the this is the one we're actually using. I forgot we did a name swap in the plugins.
https://github.com/miickel/gulp-angular-templatecache

[andreafdaf]

@codydaig dropping grunt? good news! I thought that (in this project) gulp was behind grunt, but you are clearly showing me that there are some tasks that are used only in gulp

so I guess we can close this!

[codydaig]

@andreafdaf Gulp isn't fully ahead of grunt yet. But in the near future it will be.

[rhutchison]

Ref: #853

[simison]

(just calling templates by ID instead of by URL, that's it)

@andreafdaf I've felt it's okay to use the file path as an ID even with templateCache, perhaps just without .html at the end to indicate it's an inline template. Makes it easier to find them.

[andreafdaf]

@simison since templateCache is only used in production you were totally right (imho), if development needs the path to find the views (so we put the whole path when we call a templateUrl) then in production the IDs from templateCache should be the same as the path if we don't want to write more code to make this distinction happen (when in production call this ID, when in development call this path)