Finom 6 авг 2014 в 15:08

(Архив) Matreshka.js — долгожданная реализация TodoMVC

3 мин

9.6K

Блог компании Matreshka.js Веб-разработка *JavaScript *

+13

Комментарии 26

hell0w0rd 6 авг 2014 в 16:41

Приемлема ли логика в HTML коде?

Странный вопрос. Что вы называете HTML кодом и что имеете ввиду под логикой? Шаблонизацию? Ну так ее использование неизбежно.

Finom 6 авг 2014 в 16:59

Я имею в виду именно логику. Вот несколько примеров из туториала AngularJS:

<li ng-repeat="phone in phones | filter:query">

Допустим, указание на то, что именно нужно вывести — приемлемо (хотя этого можно избежать), но указание на то, как фильтровать данные — лишнее. Этим должен заниматься JS код (опять же, по моему скромному мнению).

<html ng-app="phonecatApp">
...
<body ng-controller="PhoneListCtrl">

Это уже не шаблонизация, это — программировние. HTML код не должен знать какой модуль/контроллер управляет им. По идеологии Матрешки об этом знает только JS код.

<button ng-click="hello('Elmo')">Hello</button>

Без комментариев.

Пример из KnockoutJS:

<a href='#' data-bind='click: $root.removeContact'>Delete</a>

Тоже без комментариев.

В Матрешке нет шаблонизации. Если говорить о коллекции, то мы ей должны дать элемент, который будет отрендерен, а какие именно туда попадут свойства (что к чему должно быть привязано) определяется в JavaScript.

Dima_Sharihin 6 авг 2014 в 17:18

Я для Knockout сделал свой велосипед, вынеся привязку в отдельный файл(когда надоели многострочные привязки)

    app.page<MusixBox.Main.Controller, MusixBox.Main.ViewModel>('main', p =>
        p.template("common", "/Client/Pages/Main/View.html")
            .viewBinder("common", (c, vm, ctl) => {
                c['categoryList'] = {
                    template: {
                        foreach: vm.Categories,
                        name: '/Client/Pages/Main/cl-IT.html'
                    }
                };

                c['performerList'] = {
                    virtualScroll: <virtualScrollSettings>{
                        loadFn: (l, f, c) => ctl.loadPerformers(vm.activeCategory().folderName, l, f, c),
                        groups: vm.performersIndex,
                        activeValue: vm.activePerformer,
                        headerTemplate: '/Client/Pages/Main/pl-HT.html',
                        headerHeight: 46,
                        itemTemplate: '/Client/Pages/Main/pl-IT.html',
                        itemHeight: 34,
                        heightOverflow: 100,
                        containerTemplate: '/Client/Templates/VirtualScroll/vlist-group-template.html',
                        activeIndex: vm.activePerformerIndex
                    }
                };

И в коде html получается

<!-- ... -->
<div class="scroll-viewport" data-bind="bindId: 'performerList'"></div>
<!-- ... -->

hell0w0rd 6 авг 2014 в 23:09

Ну вот сейчас я как раз пишу первое приложение на ангуляре, так и подумал что вы про него.
Интересно что вы скажите о Shadow DOM, который является логичным развитием современного веба.
Я раньше тоже был против логики в html, о которой вы говорите. Но эта самая логика позволяет очень сильно ускорить разработку и уменьшить кол-во шаблонного кода, который неизбежно приходится писать в Backbone и других подобных фреймворках.
Например в популярном php шаблонизаторе Twig есть подобная фишка twig.sensiolabs.org/doc/tags/for.html#adding-a-condition, вроде пользуются, никто не считает что это плохо.
Мне кажется в шаблонах можно описывать логику отображения, иначе код превращается в абстракции ради абстракций.

Finom 6 авг 2014 в 23:39

Интересно что вы скажите о Shadow DOM, который является логичным развитием современного веба.

Мне нравится идея Shadow DOM, но, к сожалению, я пока не могу представить, как его использовать для работы.

Мне кажется в шаблонах можно описывать логику отображения, иначе код превращается в абстракции ради абстракций.

Я большой противник абстракций, а уж тем более, ради абстракций. Люблю, когда код, который я написал год назад, могу понять. Матрешка, по крайней мере для меня, позволяет это делать, причем объем приложения не сильно влияет на понимание, так как каждый логический кусочек создан при помощи отдельного класса, каждый класс в отдельном файле, как и в Backbone (хотя эти кусочки там по-другому называются).

… кол-во шаблонного кода, который неизбежно приходится писать в Backbone и других подобных фреймворках

Вот вот. Я достаточно спотыкался о шаблонный код, хочу писать меньше, получать больше. Самым оптимальным вариантом для меня было создание своего фреймворка, которому, кстати говоря, около двух лет, но выложен в качестве опен-сорц сравнительно недавно.

Например в популярном php шаблонизаторе Twig есть подобная фишка twig.sensiolabs.org/doc/tags/for.html#adding-a-condition, вроде пользуются, никто не считает что это плохо.

Сравнение шаблонизатора для PHP и для клиентского JS, на мой взгляд, — неверно. PHP не манипулирует элементами динамически при наступлении каких-то событий, он генерирует статичный HTML. Ангуляр, на мой взгляд, — идеальный инструмент для простого вывода данных. Если требуется только лишь это + простые дополнения, типа события нажатия кнопки, лучше этого инструмента я и не знаю. В PHP, да и в любом другом серверном языке, я бы тоже использовал шаблонизатор.

tenbits 6 авг 2014 в 20:25

Хороший код, тот которого нет. А в контексте приложения и концепта — логика как энергия, если она пропадает в одном месте, то обязательно должна появится в другом. А архитектура, наподобии некой философии, определяет основы "мироприложениездания" обозначая сущности и слои, награждая каждого своей логикой, ролью и обязаностью.
Если наделять html обьязанностями представления, тогда разумеется там же должна находится и логика связанная с предствалением. Где какие данные показывать(интерполяция), какие елементы обновлять при изменении модели(биндинг), какие комманды вызывать при неких действиях пользователя(сигналы/события) и т.д. Резумеется не любую логику можно описать в html, в силу специфики синтаксиса, но подобные простые вещи отлично ложатся на плечи html кода. А такие строки как this.bindElement( 'x', 'select.my-select' );) и this.on('click', '.mysuperselector', this.hello) создают ненужную зависимость контроллера от представления и раздувают сам контроллер.

tgz 6 авг 2014 в 21:49

Самая большая проблема любых js фреймворков, это то что на них нельзя писать не зная это самый js.

-2

hell0w0rd 6 авг 2014 в 23:10

А в каком языке есть фреймворки, на которых можно писать не зная языка?
А хотя постойте… Boost из C++ как раз подходит на эту роль.

-1

Kentzo 6 авг 2014 в 23:52

То есть контролируемая и исправимая ошибка вида «разработчик на месте забыл повесить обработчик» перетекает в «разработчик фреймворка допустил ошибку в коде биндинга», которые решаются только с помощью дичайших хаков?

-1

Finom 6 авг 2014 в 23:53

Разработчик и в обработчике может допустить ошибку. А где, пардон, дичайшие хаки?

Kentzo 7 авг 2014 в 00:34

Вопрос в том, на каком уровне будет баг. Если фреймворк все взаимодействие берет на себя, то влезть и поправить будет намного сложнее, чем свой собственный код.

Finom 7 авг 2014 в 00:35

Это проблема любого фреймворка и библиотеки.

Kentzo 7 авг 2014 в 02:21

Неправда. Хороший фрэймворк позволяет эффективно работать с собственной структурой и предусматривает возможность «вклиниться» в критичных местах. У данного фреймворка логика биндингов критична и непонятно можно в нее вклиниться или нет.