Новости‎ > ‎

Некоторые мысли насчёт данных на клиентсайде

Отправлено 13 февр. 2016 г., 8:06 пользователем Denis Baskovsky   [ обновлено 13 февр. 2016 г., 8:25 ]
Уже более полугода 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.

Что если будет несколько слоёв валидаций значения? Захламление будет. Сейчас оно захламляет наши компоненты, их логика находится на разных классах, в разных файлах, на разных репозиториях... В случае факапа приходится долго проходить по стектрейсу чтобы найти ту самую функцию, которая упала.

PS. 
Такой подход мне чем-то напоминает XSLT-трансформации, но логика остаётся внутри JS. И самое красивое при таком подходе то, что HTML становится как бы средством описания логики работы приложения в целом. 

PSS. 
Вообще я думаю языку HTML нужно нечто вроде заголовочных файлов *.h, или поддержки программных интерфейсов/абстрактных классов, типо C#. Всё-таки язык HTML декларативный и, возможно, было бы удобно иметь возможность описания шагов результата, а не бегать с дебаггером по всей структуре проекта за столь ускользающими данными.