You can clone with
HTTPS or Subversion.
Just wanted to point out that include does not work on the client-side jade.js
My fix was to check if fs exists in the include parser, if not load the template via ajax and cache it on the page. All future includes or template loads will be loaded from the page for obvious reasons.
Is there a better way to do this? If not I'm going to write a client-side fs module that uses ajax and a page caching system so it functions the same as if it were on a server. If you like the sound of that I'll send in a pull request, just let me know.
personally i dont really want IO in client-side templates, the solution for this sort of thing is pretty opinionated too, many ways to go about it
Alrighty then I guess I will continue to hack on this fs adapter
@visionmedia - IMHO, there needs to be a "standard" way to include views on client-side templates. I understand that the 'include' keyword is for "static" file includes, and I/O is not appropriate. But, consider this... if you use the same include file for nearly every page, then you can waste significant bandwidth when client-side templates are compiled and delivered to the browser.
What about a 'dynamic include(filename)' directive? At runtime, not compile time, the view is loaded either from a cache or from the disk, then it is included.
- var filename = "bar.jade"
This can also solve the problem of including views on the client-side. Rather than including the file at compile-time, you can include it at runtime using the 'dynamic' keyword. The Jade runtime can be configured to download views from a particular location (i.e. /views/foo.jade). Of course, the Jade runtime would also cache dynamically included views to avoid re-downloading them.
This is especially useful if you frequently include a file that contains only mixins. :)
Similarly, what about things like dynamic extends("parent.jade")? Suppose parent.jade was extended for nearly every page? For client-side templates, shouldn't this be dynamically loaded?
they could be preloaded into the jade runtime, something like jade.templates[filename] = stuff, so they could work more or less the same, once you get into dynamic loading etc it's a slippery slope though, next thing you know you're maintaining requirejs inside your template engine
jade.templates[filename] = stuff
I see what you mean... wouldn't hurt to implement dynamic includes in Jade and include a "dynamicInclude()" function in the runtime.js lib that simply threw an exception. Then, it would be up to the developer to create a function that loaded the template from the server and override the dynamicInclude() function in the Jade runtime.
I'd really like to see an Express middleware (I might even develop one) that would load Jade templates into the client. Let me think about it over the weekend and come back to you.
The main problem right now is with the Jade compiler.... the 'include' keyword statically includes dependent templates at compile-time, which is the culprit of the "wasted bandwidth" issue. Imagine you had a large file that defined a bunch of mixins. Then, you had a Jade snippet that simply used one of those mixins; nevertheless, the entire mixin file would be included in the compiled template. No problem, except that you might have lots of snippets like that... each one with the same copy of the large mixin definition file. No good.
yeah that would be nice! you could definitely expose an end-point in the middleware and wrap up all the templates.
that's true also, it's not important until you get the client-side. Personally I have pretty small jade templates on the client-side, I dont tend to use extends or includes on that end
It would be nice for me b/c I have GUI components that are mixins (i.e. custom designed buttons, form fields, etc.). A good example is an auto-complete form field. I'd really like to use those same components on the client-side. :)
I see that this issue is closed, but it seems like compile still duplicates includes on the client. Dynamic loading isn't really as much an issue for me as code duplication (which is a problem for client parsing and memory, as well as for file size). I'd really like to work toward a way to resolve this, if there's not already a known solution. Thanks!
@michaek you could try looking into jade-amd-middleware or jade-browser, you could also use grunt to compile everything to a dist folder which you serve with express.static and then have a watch script in place to rebuild on changes.
@niftylettuce I should have been clearer that I wasn't responding to the original issue, but primarily @bminer's comment after the issue was closed. I'll open a new issue to avoid further confusion.