Deprecate <import> and <variable>

[ang-zeyu]

Is your request related to a problem?

Opening an issue to track: #751 (comment)

Describe the solution you'd like

• allow <include><variable>...</variable></include> to override {% set / import %}
• re-implement external json variables using a custom nunjucks tag
• add deprecation warnings after the above for <import> and <variable>
• add live preview for nunjucks sources (anytime)
• finally, remove <import> and <variable> (v3.0)

Additional context

See discussion here #751 (comment)

[ang-zeyu]

(1) and (4) have been merged in

for (2), I noticed that the current requirement of allowing variables in json to also reference other variables makes the re-implementation considerably more complex, but not impossible

I'm thinking that external variables should not be allowed to do so, since

• the use case for sourcing external variables usually is some dataset that is independent of the markbind project in the first place
• having nunjucks syntax in such standard files may not be rather user friendly - it requires the user to consider the placement of tag that sets the external variable carefully; any other variables declared before it in the page; any {% import %}s made, ..., which could all affect the result of the variables extracted from the file

Since its a new feature / replacement of an existing feature, we could do away with this (existing <variable type="json">s would still work till we deprecate that as well)

What do you think? @damithc
Are there worthwhile cases where we want nunjucks syntax to appear in such external files? (.json, .csv, .xlsx)

[damithc]

What do you think? @damithc
Are there worthwhile cases where we want nunjucks syntax to appear in such external files? (.json, .csv, .xlsx)

I guess we can live without it. So, go ahead. 👍

[ang-zeyu]

will be getting a new release out tonight tomorrow with a few hotfixes (hopefully that's stable =P)

since that's all on the deprecation plate, I will be fast tracking the code to v3.0 from now on as well since full deprecation of this is necessary for the aims.

It'll mostly be backend changes requiring / including deprecation of some frontend user facing features:

• Much simpler architecture
• Much improved performance ~2x
• Deprecate and change some things about plugins to facilitate the above
• Deprecate old syntatic features (<modal title> -> <modal header>)
• ...