env = jinja2.Environment()
ast = env.parse(...)
vars = jinja2.meta.find_undeclared_variables(ast)
Now you've got a list of every part of the data model referenced by this template. Unfortunately this doesn't give you byte ranges for each reference, but that could be changed.
Angular propagates changes to your data model to only the parts of the DOM that depend on it, which is cool. Imagine if you could do the same against a nunjucks template. Given the above kind of dependency analysis, I don't see why not.
Maybe rendering snippets of a jinja template at runtime is problematic?
Aside: yikes on the string-based codegen here...I bet you wish you were still writing scheme ;)
Oh, yes, nunjucks features a full AST and parser like jinja2. The compiler calls `parse` and then `compiler`, so we can analyze the tree between those two stages as well. I'm thinking of hacking around on this, it is interesting!
Angular propagates changes to your data model to only the parts of the DOM that depend on it, which is cool. Imagine if you could do the same against a nunjucks template. Given the above kind of dependency analysis, I don't see why not.
Maybe rendering snippets of a jinja template at runtime is problematic?
Aside: yikes on the string-based codegen here...I bet you wish you were still writing scheme ;)
https://github.com/jlongster/nunjucks/blob/master/src/compil...