Насчёт потока данных на Polymer

13 февраля, 2016
1 минута чтения

Polymer Project Data Pipe
Polymer Project

Уже более полугода 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 декларативный и, возможно, было бы удобно иметь возможность описания шагов результата, а не бегать с дебаггером по всей структуре проекта за столь ускользающими данными.

Денис Сергеевич Басковский

Философ, изобретатель и поэт.

Добавить комментарий Отменить ответ

mdn
Предыдущая статья

Где найти документацию по JavaScript

material design blogger paper theme
Следующая статья

Дошли руки до обновления своего бложика

Exit mobile version