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