Уже более полугода Polymer ломает мне мозг бывшего jQuery/Angular скриптера. За это время я понял насколько легко потерять из виду потоки данных. Я считаю, данные должны свободно течь по неким видимым трубам, проходящие через элементы страницы. Каждый раз данные загрязняются, либо очищаются логикой другого элемента. Это похоже на канализацию (в лучшем её исполнении).
Сравнивая с тем, что придумали до меня гугловцы, я взял за основу элемент <iron-ajax>. По его примеру создал новый элемент <my-http>. Пусть это будет некий враппер HTTP-запросов, нагруженный новой логикой обработки ошибок:
<my-http get="./product"
handle-as="json"
params="{{ myValues }}
on-code-400="code400Callback"
result-as="productValue"
<validate-product value="productValue"
on-catch="errorCallback"
result-as="validateProduct">
<text-area>{{ validateProduct }}</text-area>
</validate-product>
</my-http>Здесь элемент <validate-product> будет иметь логику валидации значения productValue, которое приходит в формате JSON в случае успеха, после HTTP GET запроса. Уже очищенные, отвалидированные значения реактивно показываются в кастомном элементе <text-area>.
Мне нужно возразить, почему бы не создать просто функцию-фильтр validateProduct, который будет очищать значение productValue? Что же давайте напишем то, как это будет выглядеть и что произойдёт:
<my-http get="./product"
handle-as="json"
params="{{myValues}}
on-code-400="code400Callback"
result-as="productValue"
<text-area>{{ validateProduct(
productValue
) }}</text-area>
</my-http>Вроде кода даже стало меньше, всё выглядит очень хорошо. Но возникла проблема, функция errorCallback теперь объявлена где-то ещё. Для её поиска придётся залезть в JS и посмотреть как отрабатывает функция validateProduct. Т.е. мы потеряли из виду описание трубы данных, перенесли её в JS и теперь думаем как правильно создать MVC.
Что если будет несколько слоёв валидаций значения? Захламление будет. Сейчас оно захламляет наши компоненты, их логика находится на разных классах, в разных файлах, на разных репозиториях… В случае факапа приходится долго проходить по стектрейсу чтобы найти ту самую функцию, которая упала.
P.S. Такой подход мне чем-то напоминает XSLT-трансформации, но логика остаётся внутри JS. И самое красивое при таком подходе то, что HTML становится как бы средством описания логики работы приложения в целом.
P.S.S. Вообще я думаю языку HTML нужно нечто вроде заголовочных файлов *.h, или поддержки программных интерфейсов/абстрактных классов, типо C#. Всё-таки язык HTML декларативный и, возможно, было бы удобно иметь возможность описания шагов результата, а не бегать с дебаггером по всей структуре проекта за столь ускользающими данными.
