我正在使用Django的一个大型社交网络应用程序，我希望在这里多次使用某些前端组件，并且通常采用以自定义组件包含其他其他方式设计的功能性自定义组件，可能包含较小的子组件（AD Infinitum）。所有这些组件通常都是动态生成的。我正在尝试找出在Django框架中构建此任务的最佳方法，以便我的组件易于维护并具有清晰的编程接口。但是，严重依赖全球环境似乎与此相反，但是，我可以在视图中立即进行所有操作来避免冗余查询。
自定义包含模板标签似乎非常适合实现组件，但是我想知道，高度嵌套的模板标签是否可以造成性能问题，或者解析体系结构阻止了这种情况？在视图级别上进行自我记录的最佳方法是什么来渲染主页模板，自定义标签和所有上下文？我想象它是一场小噩梦，试图正确维护代码以设置模板上下文。最后，维护这些组件的CSS的最佳方法是什么？
随意建议创建嵌套组件设计的其他推荐方法。
到目前为止我决定的解决方案是继续使用包含标签库作为我的可重复使用组件集。我尽可能地粘贴在视图代码中设置所有查询，并在我的上下文中以预设置的方式传递它们 - 没有在模板或标签库代码中生成新查询的函数。包含模板包含该项目的所有标记，并且样式进入了主站点样式表，按照SMACSS的指南，使我的课程尽可能通用和可重复使用。我仅根据干燥的需要将组件重构为包含标签。
我最初使我的包含标签函数明确地采用标签模板使用的参数，因此：
页面模板
<div>{% my_tag param1 param2 %}</div>
标签库
@register.inclusion_tag('myapp/tagtemplates/my_tag.html')
def my_tag(param1, param2):
return {'param1': param1, 'param2': param2}
my_tag.html
<div>Blah: {{ param1 }}</div>
<div>Blip: {{ param2 }}</div>
...显然，视图设置了上下文。
但我决定使用takes_context参数，以避免明确定义标签库中的参数。重复过多，无法在文档中获得足够的回报。到目前为止，我的组件非常简单，从检查模板的检查中可以清楚地看出依赖项。我担心复杂的嵌套组件可能无法接受，但是我总是可以使我的标签库功能冗长，需要在哪里。
从维护的角度来看，我对此设置并不完全满意。我不喜欢我必须手动跟踪不再需要哪些上下文数据。我不喜欢我的CSS课程必须仔细命名以避免冲突的事实。
我仍然对新解决方案开放，因为我不确定我决定的是最好的做法。
这是一个有趣的问题。理想情况下，您应该在渲染之前从数据库中提取所有组件。但是看层次结构，制作模板标签是有道理的。这些模板标签将提取适当的数据。假设出于此问题的目的，数据库查询由于搜索位置而被缓存。