Pull to refresh
78
0
Panya @Panya

User

Send message
Нужно просто вести курсор с зажатым кликом вверх или вниз. А затем можно кликать на другие письма, чтобы их добавить или исключить из выборки.
Ссылки нужны, например для того, чтобы их копировать. Или для того, чтобы через ctrl/cmd + клик открывать отдельные письма в новом окне (это не актуально в трехпанельном интерфейсе, но актуально в старом). Или для того, чтобы работала история и можно было восстановить состояние интерфейса по url. Да, веб-приложение != сайт, но полностью убивать из-за этого все привычки пользователя — плохо.
Как и в FF, но зачем с этим что-то делать? Вы можете одновременно наводить на ссылку и на иконки внизу?
Мне не совсем понятно, зачем вы выбрали xml-синтаксис, если оперируете внутри шаблонизатора с JSON-данными? То есть, есть конечно аргументы про поддержку в редакторах и экранирование всех данных по-умолчанию. Но получается такая гремучая смесь, что мне лично это даже сложно читать, не говоря уже про написание и поддержку.
Fest — императивный шалонизатор, с конечно более продвинутыми возможностями, чем в handlebars, но семантика одинаковая.
Почти все — незначимые мелочи (микрооптимизации, которые не дают ничего, но при этом сильно ухудшают читабельность кода). Из действительно значимого — меньше обращаться к ДОМ + использование DocumentFragment, и использование setTimeout при выполнении долгих операций частями.
В JS тоже все просто, хочешь строгое сравнение используй ===, хочешь нестрогое (с приведением типов по правилам, описанным в спецификации) используй ==. Где wtf? На приведенном сайте есть совсем запредельные по своей тупости примеры, типа:
var a = {};
a == {} // false

var a = [];
a == [] // false

А что, простите, автор хотел получить сравнивая два разных объекта?
Ага, тоже советую посмотреть на SC. Он, на мой взгляд, имеет самую лучшую реализацию подходов, описанных в посте.
Да, это работает потому, что для каждой итерации цикла создается самовызываемая функция, которая имеет свою область видимости, в которой i — имеет нужное нам значение (мы получаем его внутри setTimeout). В вашем же коде, для всех i область видимости одинаковая и на момент вызова функции в setTimeout, i в этой области видимости будет уже равно 5 (цикл уже отработал). Подробнее почитать например тут: javascript.ru/basic/closure
Ваша проблема решается без эвала, это классическая проблема, решаемая с помощью замыканий. Например так:
for (var i = 0; i < count; i++)
{
  (function(i) {
    return window.setTimeout(function()
    {
      asyncFunc(i);
    }, 10000 * i);
  })(i);
}
Слишком слабая связанность и большое количество абстракций — тоже плохо. На мой взгляд, в вашем примере дескрипторы только мешают. Если поменялся один модуль, или поменялось отношение одного модуля от другого нужно руками править дескрипторы. Где гибкость? Большое количество событий только запутывает. Про проблемы с дебагом уже говорили. Нет ничего смертельного в том, что какой-то модуль системы знает о существовании другого и вызывает его методы. Эта та же зависимость, которую вы скрываете с помощью событий и дескрипторов.
Ваш подход в целом подходит для обычных сайтов (пусть даже и с большим количеством JS), а не веб-приложений. VK — не веб-приложение.
JFYI: через innerHTML тоже за одно.
Почему в ядре завязка на DOM?
Правда, видны кое-какие незначительные артефакты :)
Немного ручной работы + собственный shell-скрипт, который просто использует несоклько утилит и прогоняет по несколько раз:
image
(85 540 байт)
Я не говорю, что реклама не нужна. Я говорю, что имея посредственный продукт невозможно сделать так, чтобы все начали им пользоваться при наличии более подходящих альтернатив. Вы же мне говорите, что требования пользователей неважны (они все бараны) и, имея кучу денег, втюхать можно все что угодно.
Это к чему? Все перечисленное решает задачу пользователя лучше, чем все то, что было до их изобретения.
Знают все, реально могут пользоваться (установка != постоянное использование) — десятки.

Information

Rating
Does not participate
Works in
Registered
Activity