Как стать автором
Обновить
58
0
Олег Калистратов @malroc

Пользователь

Отправить сообщение
Отправил. Ник: oleg.kalistratov
Поменяюсь соткой: oleg.kalistratov
> В новой версии JavaScript
В какой?
Ну на Хабре была уже серия туториалов по Дерби, может из-за этого минусуют.
Вопросы (я понимаю, что можно в документации прочитать, но раз уж вы вызвались отвечать).
1) В примере нет моделей, шаблон отрисовывает данные по plain js объекту, взятому напрямую из Mongo. Я так понимаю, нормальные модели всё-таки есть? Бизнес-логику в них реализовывать можно?
2) Какой механизм «реактивного» взаимодействия? На уровне протокола. Сокеты, лонг-поллинг, что-то там ещё?
Да, согласен, всё время забываю про фичи, которые не поддерживаются в IE8, т.к. пока всё равно не получается ими пользоваться.
Без функции-конструктора — нет. А она в данном случае и есть ненужная сущность. Я имел в виду это, может быть неудачно выразился.
> Часто, классы создавать совсем не обязательно, это излишний уровень абстракции, и прототипное наследование, или даже создание объектов на лету, прекрасно справляется с такими задачами.

И чем нам тут помогает прототипное наследование в реализации JS? Какая разница, объявлять класс или функцию-конструктор, которая делат всё то же самое, что класс, но при этом не класс?
Можно было бы про Бритву Оккама вспомнить, если бы в JS можно было использовать в качестве прототипа произвольный объект. Но это не так.
А где вы его увидели? Она разная. Поэтому один и ставит одну цену, другой — другую. Если бы она для всех была одинаковой, аукционы были бы не нужны.
Более того, раздел начинается вот с таких слов:
> Как же определить, сколько денег брать за клик? Ведь прибыль от него для каждого рекламодателя может быть разной.
Это математическое доказательство, абсолютно корректное при заданных условиях.
> Rovio признается, что пока медленно осваивает фритуплей
Чуть не полез в гугл искать, кто такой фритупль.
Но подборка хорошая :)
По поводу совмещения activate и initialize можно подумать. Имя remove мне использовать не хотелось бы, т.к. в целом смысл тут несколько другой, чем у remove в Backbone.View: remove удаляет элемент из DOM, а deactivate вызывается, когда элемент удалён со страницы.
> В обоих случаях получаются черные ящики
Это неверно. В случае Backbone.Component разработчик сам решает, как ему генерировать текст. Он может использовать любой шаблонизатор или сгенерировать в jQuery набор DOM-элементов и потом вызывать html(). Или просто строку склеить. То есть
1) это не чёрный ящик
2) нет никаких ограничений на метод генерации HTML
В случае React вам придётся использовать манипуляцию DOM либо JSX. То есть React накладывает свои ограничения на инструментарий разработки, Bacbkone.Component — нет.
Бог с ней, с терминологией. Давайте так: React — это opinionated решение (извиняюсь, не представляю как это адекватно перевести на русский), которое например говорит вам, что шаблоны использовать не надо (ну или предлагает в качестве варианта JSX). С «голым» Backbone у вас таких ограничений нет, Backbone.Component тоже оставляет отрисовку полностью на усмотрение разработчика. Хотите шаблоны — используйте шаблоны, хотите манипуляцию DOM — используйте манипуляцию DOM. Можете с сервера подтягивать отрисованные куски HTML.
То есть я старался не выходить за идеологию Backbone, с React это никак не получится.
Да, но тут есть оборотная сторона: читабельность.
Если я должен просмотреть 5 файлов (а перед этим ещё и найти, какие файлы просматривать), чтобы понять, как работает одна небольшая область экрана, это ну никак не способствует общей читабельности кода. Если область экрана управляется одним классом, вся логика её работы у вас сразу перед глазами.
На мой вкус это перевешивает всё остальное. Как известно, код больше времени читается, чем пишется.
Ну если обе стороны не понимают, о чём спорят, значит пора закругляться :)
Некорректно:
1) у вас нет документации
2) о вашей наработке кроме вас никто не знает (0 звёздочек на гитхабе)
То есть это решение не существует ни для кого кроме вас. Я бы его никогда не нашёл, если бы вы здесь мне его не привели.
Так что я до сих пор не понимаю, что мы сравниваем и о чём разговор.
А, вы про экраны в редакторе? Тогда да, 2+ страниц вполне встречается. Не вижу в этом проблемы, хотя тут тоже на вкус и цвет. Меня куда больше напрягает скакать из одного файла в другой, чем по одному файлу, который отвечает за одну область экрана.
Нет, вы не поняли. Я не о велосипедности как таковой, в ней ничего плохого нет (любая разработка — чей-то велосипед так или иначе). Я не употреблял слово «велосипед» в негативном значении.
Я только о том, что я решал проблему, готового решения которой не нашёл, поэтому к чему эти вопросы «зачем»? Ну затем, что решения не было.
Ну хорошо, я согласен, что в отдельных случаях та архитектура, которую я привёл, не подойдёт. Я и не утверждаю, что она универсальна. Я сказал, что обычно такие сложности не требуются, и трёх уровней вполне достаточно.
Если семантика приложения такова, что в нём объективно есть многоуровневые вложенные элементы (как в этом меню, о котором вы говорите), конечно, логично использовать для него вложенные вьюхи. Но это скорее исключение и с моей субъективной позиции говорит о плохом дизайне интерфейса.

Информация

В рейтинге
Не участвует
Откуда
Нижний Новгород, Нижегородская обл., Россия
Зарегистрирован
Активность