Markbind: Nunjucks variables not resolved

Created on 1 May 2019  路  8Comments  路  Source: MarkBind/markbind

  • MarkBind Version:
    2.4.0

What did you do? Please include the actual source code causing the issue.
Built CS3281 student website with MarkBind 2.4.0. Travis Log

What did you expect to happen?
Expected the site to build as per normal.

What actually happened? Please include the actual, raw output.
It appears that the {{students[1]}} variable was not resolved.

Forced npm to use [email protected], and the site built successfully. Travis log

I'm not sure if it's an intentional change, but it appears that some variables are not resolved at all...

c.Bug 馃悰 p.High

Most helpful comment

Sure I'll take a look over the weekend

All 8 comments

@jamos-tay can take a look?

Nunjucks rendering was deferred to a later stage since #751, which explains the error. We need the render to happen before _preprocess() gets called again here:

https://github.com/MarkBind/markbind/blob/4d1101243781742448475993b43b6da2921836ab/src/lib/markbind/src/parser.js#L422

Since MarkBind's user guide is also affected by this (see https://markbind.org/userGuide/formattingContents.html), setting the priority of this to High.

Sure I'll take a look over the weekend

How's this coming? Need to fix soon as it makes the current MarkBind version unusable :-(

I was looking at the code to see if we can avoid deferring Nunjucks rendering to such a late stage, but I realise that there's going to be a potential clash between supporting this use case and supporting import variables.

Consider this case:

index.md

<import src="{{ file }}#var" />
{{ var }}

If we do the Nunjucks rendering first before parsing, {{ var }} will not be rendered correctly.

If we do the Nunjucks rendering later after parsing, {{ file }}#var will not be a valid source path.

Selective Nunjucks rendering could be explored, but it seems that edge cases are going to be quite problematic (e.g. the src being entirely a Nunjucks variable could throw off the detection of which variables to render first, and which to render later).

Yeah I don't have much ideas either...

@yamgent One thing we could do is render source urls separately before loading, so like actualFilePath = nunjucks.renderString(filePath, userDefinedVariables);, however this doesn't really play well with variables in the same page (like set) because they have to be loaded earlier.

What if the students were defined in variables.md? That way they should be available to be rendered. I'm not sure how we will handle arrays though

@yamgent One thing we could do is render source urls separately before loading, so like actualFilePath = nunjucks.renderString(filePath, userDefinedVariables);, however this doesn't really play well with variables in the same page (like set) because they have to be loaded earlier.

Yes, you have identified another edge case pertaining to the feature. I think the importing variables might need a rework then, since I don't see how we can support it with our current algorithm without breaking a few existing use cases and features.

If this cannot be solved soon, we have to consider rolling back the 'variables import' feature 馃

Was this page helpful?
0 / 5 - 0 ratings