class Program {
static void Main(string[] args) {
SyntaxTree tree = SyntaxTree.ParseText(
@"using System;
namespace HelloWorld {
class Program {
static void Main(string[] args) {
var i = 10 * 20;
String s = t.ToString();
}
}
}");
var comp = Compilation.Create("HelloWorld")
.AddReferences(MetadataReference.CreateAssemblyReference("mscorlib"))
.AddSyntaxTrees(tree);
var model = comp.GetSemanticModel(tree);
new Walker(model).Visit(tree.GetRoot());
Console.ReadKey();
}
class Walker : SyntaxWalker {
private readonly SemanticModel model;
public Walker(SemanticModel model) : base() {
this.model = model;
}
public override void VisitVariableDeclarator(VariableDeclaratorSyntax node) {
var declaredSymbol = (LocalSymbol) model.GetDeclaredSymbol(node);
Console.WriteLine("{0} {1} {2}", declaredSymbol.Type, declaredSymbol.Name, node.Initializer.GetText());
}
}
Разработчики linkedIn как-то публиковали описание подходов по оптимизации бесконечных скролов, которые они у себя применяли:
http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5
а фэйсбук не самый хороший пример оптимизации фронтэнда.
p.s. по поводу ангуляра и делигированных событий, у меня в некоторых частях проекта используется всплытие ивентов вместо непосредственной привязки к элементу. Делается это у меня через 2 директивы (fsDelegate, и далее всякие обработчики ивентов аля fsTap и т.д). Причем fsDelegate вешает обработчики на элемент списка, fsTap регистрируется у fsDelegate (если конечно оно там будет, связь между ними через контроллер fsDelegate и параметр require: '^?fsDelegate'). Опять же при отлове события определяется какой именно элемент отработал, берется его скоуп и выполняется выражение заключенное в fsTap.
Браузер однозначно что-то оптимизирует при выходе элементов за viewport, но на это сильно расчитывать не стоит.
а) Делал горизонтальную прокрутку viewport`а, анимация идет намного плавнее, если по бокам элементов намного меньше и те что не в области видимости прятать через display:none; Визуально разницу можно наблюдать. Можно проверить.
б) Делал бесконечную вертикальную прокрутку вниз, подобие стены в соцсети, где доходя до низа приходит новая пачка с медиа контнетном. В js все обработчики отвязывались своевременно, профайлил все долго и упорно, пытаясь ускорить сей процесс. Но после 1000-2000 элементов контента на странице, браузер начинал на ПК тупить и кушал все больше памяти. Хотя оптимизация самими браузером определенно есть. Но удалять элементы из DOM оказалось намного эффективнее.
2) Тут вопрос не в прокрутке, а в том, что когда ты удалишь вышерасположенные элементы, то представление схлопнется, элементы перепозиционируются. Вставлять пустую элементы такой же высоты вместо прежних это костыльно.
Посмотреть можно примеры отсюда - http://masonry.desandro.com/
Уверен что кто-то выгружает тоже элементы, чтобы GUI был более отзывчивым.