a data (in the data cascade) and filter have the same name.
and we are in a in a webc file
=> we cannot access the data value directly in webc.
Note : This works as expected in njk files.
I have investigated in the source code and found a work around that seems fine but not documented anywhere. Maybe the fix to this problem is to simply document it somewhere but why it happens it also interesting.
PS: English not my native langage :sweat_smile:, sorry for the mistakes i make.
TL;DR :
In njk the syntax is unambiguous eleventyNavigation is clearly a data while here collections.all | eleventyNavigation it is cleary a filter function. In webc the syntax is eleventyNavigation for the data and eleventyNavigation(collections.all) and it it resolve via a node vm. This is ambiguous because in both case this is considered the same identifier. In the context given to the vm eleventyNavigation filter function have overridden the data from cascade so it always resolve to the filter.
Workaround: Inspecting the context we can see that it has a $data property with the data not overridden. We can use $data.eleventyNavigation instead of eleventyNavigation when we want to access eleventyNavigation data.
Contexte : what is not working
For context, I was trying to debug eleventyNavigation value for a page, I was succeeding reading it in a njk template but when converting it to webc it was not working anymore.
This is because eleventyNavigation can be resolved to the data from the cascade or the filter with the same name. In njk it is able to make the difference while in webc it is not. This is because in webc expression are resolved using a node vm and a context object. Context is a proxy object that proxy to the data cascade. However in the data cascade filters overrides data with the same name.
That said, I've found that a copy of the data is kept in a $data property of the data object before filters and other things are applied. So we can work around this using this non standard, non documented $data property, like this :
I was not able to find a way to get the same behavior as in the njk files due to the vm proxy usage. Maybe documenting and making the $data property part of the public spec is a correct way of addressing this issue but I don't know the implications.
Reproduce to test
Let me give you a simple project to reproduce and test this : i will use the @11ty/eleventy-navigation example since that is how I found the problem.
What is the problem
When :
=> we cannot access the data value directly in webc.
Note : This works as expected in njk files.
I have investigated in the source code and found a work around that seems fine but not documented anywhere. Maybe the fix to this problem is to simply document it somewhere but why it happens it also interesting.
PS: English not my native langage :sweat_smile:, sorry for the mistakes i make.
TL;DR :
In njk the syntax is unambiguous
eleventyNavigation
is clearly a data while herecollections.all | eleventyNavigation
it is cleary a filter function. In webc the syntax iseleventyNavigation
for the data andeleventyNavigation(collections.all)
and it it resolve via a node vm. This is ambiguous because in both case this is considered the same identifier. In the context given to the vmeleventyNavigation
filter function have overridden the data from cascade so it always resolve to the filter.Workaround: Inspecting the context we can see that it has a
$data
property with the data not overridden. We can use$data.eleventyNavigation
instead ofeleventyNavigation
when we want to accesseleventyNavigation
data.Contexte : what is not working
For context, I was trying to debug
eleventyNavigation
value for a page, I was succeeding reading it in a njk template but when converting it to webc it was not working anymore.In njk the following was working :
but translating it to webc was not working (with a custom dump filter since it does not exist by default in webc) :
This is because
eleventyNavigation
can be resolved to the data from the cascade or the filter with the same name. In njk it is able to make the difference while in webc it is not. This is because in webc expression are resolved using a node vm and a context object. Context is a proxy object that proxy to the data cascade. However in the data cascade filters overrides data with the same name.That said, I've found that a copy of the data is kept in a
$data
property of the data object before filters and other things are applied. So we can work around this using this non standard, non documented$data
property, like this :Resolving this ?
I was not able to find a way to get the same behavior as in the njk files due to the vm proxy usage. Maybe documenting and making the
$data
property part of the public spec is a correct way of addressing this issue but I don't know the implications.Reproduce to test
Let me give you a simple project to reproduce and test this : i will use the
@11ty/eleventy-navigation
example since that is how I found the problem.So first step is to init project :
Here is a config with a dump filter (~same as default nunjucks "dump" filter because it does not exist for webc) :
Create a page those pages:
index.njk :
```html --- tags: ["tag1", "tag2"] eleventyNavigation: key: njk ---NKJ
```
webc.webc :
```html --- tags: ["tag1", "tag2"] eleventyNavigation: key: webc ---WEBC
```
webc_fix.webc :
```html --- tags: ["tag1", "tag2"] eleventyNavigation: key: webc ---WEBC
```
Start the project :