Open antpaw opened 7 years ago
I've found this answer https://github.com/pugjs/pug-loader/issues/47 I strongly disagree with this idea.
This is a important template feature and using locals
is not documented in any way in pug/jade documentation. Setting something on a global object locals
will always lead to side effects that might cause unexpected behaviour. It might be not a big deal for client side, but in a isomorphic app where partials have to work on node as well you might be modifying unintentionally object references for different requests.
The best fix for this would be if pug had two different syntaxes for include that let programmers decide to inline or to require the template. Or a syntax that provides a way to define variables that should be passed down to the include along with already set variables.
Chances for this to happen are almost zero i would say, so I suggest that the library should inline every "include".
I guess @sokra (who initially implemented template inlining) didn't realize this incompatibility. I agree with your evaluation, and I'm okay with the idea of adding a require
plugin in pug-loader. But until such a keyword is implemented, I'm inclined to keep the status quo as it is, so that existing Jade (and jade-loader) users can more easily upgrade to Pug.
any update?
@RyoIkarashi you can use my fork for now https://github.com/antpaw/pug-loader
Hello everyone. I don't know why this happen, but if in included file we call any mixin variables that we passed returned their value. For example:
//- empty.pug
mixin empty()
if false
p nothing here
//- template1.pug
include empty.pug
for myScopedVar in [1, 2, 3]
include low_level_template
//- low_level_template.pug
+empty()
p= myScopedVar
And this work. But if we just delete line with +empty()
mixin call, myScopedVar
return undefined
.
Maybe this can help someone.
@TimothyGu - Any tips as to how to go about implementing this would be appreciated. This issue just put a hard stop on our large webpack refactor
@damassi this is the fork i have used to transfer my ezel based setup to webpack. The only downside I can see is that the bundle size will get bigger (extremely bigger, in extrem cases), but it uses the same convention as the browserify compiler ect, so coming from other compilers should not cause noticeable size difference. But it could be done more efficient if you would somehow "collect" all the variable form the closer scope and pass them to the included template function instead of inlining it. I think this will require a major change in the internal workings of pug, and am not even sure if the "collecting" part is possible.
Thanks @antpaw - will look into it!
@antpaw - Can confirm your fork fixed the issue. Thanks again 👍
Any movement on getting this fixed?
For those of you who seek a hack for the for loop - the solution in #47 works if you define the var in the locals
:
- locals namesArray = ['Amir', 'Tugi']
- each element in locals.namesArray
- locals.element = element
include path/to/file // <-- The file will now be able to access the variable via #{element}
With that said, any progress on the real official solution yet?
Any progress on this?
For now I will use @antpaw 's fork which seems to work great.
It would be great if the docs could be updated to relfect this. Took me a while to figure out what was happening here. @AmirTugi's fix worked perfectly for me.
Following simple example work with the pug-loader:
- var items = ['Hello', 'pug!']
each str in items
include ./include-var-str
file include-var-str.pug
:
i= str
The local variable str
defined in each in
cycle is available in included template.
Output:
<i>Hello</i><i>pug!</i>
In this example you would expect that
myScopedVar
is available inlow_level_template.pug
.But it's not. That's a huge deal for me because that's how it works in your node module used for expressjs. That's also how most people assume it should work 1 2. Also that's how jadeify does it.
Here is a testcase example (please follow the steps from readme.md) and watch the browser console output. The problem that the isomorphic_template gets compiled with this line:
it's clear to see that
myScopedVar
is set but not provided to the module 9 (which is thelow_level_template.pug
file). Jadeify would "inline" this template so the var scope is still present.