Комментарии 39
— Отличная идея!
Неструктурированная и некомпилируемая AOT шаблонизация — это so 2012. Тогда это казалось модно и молодёжно. К 2019 году пора бы уже понять, что это не масштабируется. Вообще. Совсем.
В правилах прописывается только относительно простая логика взаимосвязи между элементами. Хардкор, требующий пошаговой отладки, пишется отдельно на js (или ts если хотите), дап просто обращается потом к этому коду.
Алсо, отвечая на комментарий ниже, если ради структуры мне руками предлагается структурировать стринги как надо, то зачем мне вообще тогда стринги (читай: dap) in the first place?
Либо я не понимаю, что вы имеете в виду под "структурировать стринги", либо вы не вполне поняли, где и зачем пишутся дап-правила, и как они соотносятся с шаблонами. Можете на каком-нибудь примере показать, что вы хотите?
Либо я не понимаю, что вы имеете в виду под «структурировать стринги»
Задать им тип, в простейшем случае. Или хотя бы открыть их для статического анализа (инструментом, который еще написать кому-то придётся). Иначе каждая опечатка превращается или в падение шаблона, или, что в разы хуже, в его тихую неправильную работу.
Кому "им"? Что вы стрингами называете? Правила, которые в виде простых строк пишутся или данные, с которыми дап работает?
Если первое, то непонятно какой тип вы "им" хотите задать.
Если второе — то при чем тут стринги вообще? Сам дап работает с любыми js-данными, которые вы ему дадите. Он ими вообще не интересуется, а только передает между "участниками процесса" как есть, без всяких стрингов. А уж как их трактовать и какие типы кому назначать — это вы сами решаете.
Правила, которые в виде простых строк пишутся или данные, с которыми дап работает?
Вы искренне не понимаете, или пытаетесь, пардон за мой французский, играть в дурачка? Кто в вашем чудесном мире называет данные «стрингами»?
Если первое, то непонятно какой тип вы «им» хотите задать.
Соответствующий их назначению. Тип соответствующего элемента DOM, если речь про html. Тип данных, если речь идёт про ссылку на оные, и так далее. Нормальная система шаблонизации должна быть анализируема, а еще лучше — статически типизирована, иначе всё обсуждение крутости таких систем — это разговоры в пользу бедных; несколько опечаток в тысячах этих строк превращают результат в тыкву.
Алсо, если говорить про UI, там взаимосвязи между элементами кагбе и должны быть "относительно простыми" с т.з. дапа по крайней мере (хоть это и не обязательно будет просто с т.з. реакта или, прости г-ди, jQuery). Из моего опыта, если правила получаются сложные и запутанные — обычно это сигнал о плохой логике самой связи.
Структурировать шаблоны дап никак не мешает. Не требует, но и не мешает.
d3.json("https://jsonplaceholder.typicode.com/users").then(res => {
d3.select("body")
.append("ul")
.selectAll('li')
.data(res)
.enter()
.append("li")
.text((d) => d.name)
.on('click', (d) => alert(d.id));;
});
'UL.users'.d("* :query`https://jsonplaceholder.typicode.com/users"
,'LI'.d("! .name").ui("? .id:alert")
)
Магический синтаксис — это собственно дап и есть.
Из примеров:
bankreports-dapmx-o.1gb.ru (самое первое dap-приложение 2008-го года, ныне заброшеное),
bazamagaza-com.1gb.ru (интернет-магазин/склад/crm в одном флаконе, тоже достаточно древний)
dapmx.org/apps/rockauto (простой фронтенд к магазину автозапчастей)
Боевые проекты в открытый доступ дать не могу. т.к. там живые клиенты с данными.
Если будет интерес у почтенной публики, распишу процесс подробно на примере несложного PWA приложения, которое хочу запустить в ближайшее время.
:query`https://jsonplaceholder.typicode.com/users"
Замечательно, что библиотека берет взаимодействие с сетью под капот. Однако может у меня на работе что-то не так — ux-правила требуют, чтобы при запросе показывался прелоадер, в случае ошибки корректно выводилось её содержание пользователю и дальше всякие-всякие сценарии развития ситуации.
Можно ли такое провернуть в dap? Если да — то насколько оно сложнее выглядит по сравнению с этой маркетинговой строчкой?
Что касается обработки запросов.
Конвертор
:query
— для ленивых (лично я пока реально пользовался только им). Он получает данные, парсит их в соответствии с mime типом и отдает результат. Если что-то пошло не так, он просто отдает «ничто». Если вам не важно, что именно пошло не так (обычно так и есть, это нормальное для браузера поведение), и достаточно просто выдать ошибку вида «ой!», то это будет что-то вроде:? $data=myDataUrl:query errorMessage:alert; .... используем $data ....
Если вам надо прям все знать, то можно воспользоваться более низкоуровневым конвертором
:request
, который просто выполняет запрос и отдает его как есть, со всеми потрохами:$req=myDataUrl:request; ! $req.status $req.headers и т.д.
Если вы хотите вообще как-то хитро запросы делать, можете сделать свой конвертор, с
$data=myDataUrl:myFancyDataLoader
В принципе это тема для отдельной статьи. Не конкретно обработка ошибок загрузки, а использование собственных функций. То, что дапа будет выглядеть простым конвертором, на деле вполне может быть жыыырным черным ящиком, именно спрятанным под капот.
Формального регламента я, правда, не нашел, среверсил отсюда
официальные todo-mvc лежат вот здесь: https://github.com/tastejs/todomvc
Можно отправить свое решение туда в виде пулл-реквеста
Что сложного придумать синтаксис, основываясь на синтаксисе js?
(ссылка на TodoMVC, похоже, битая, поправьте. Я нашел ее в статье, работает) Посмотрел. Похоже, мы с вами с ровно противоположных сторон подходим к проблеме :)
Dap — еще один реактивный движок для веба. Совсем другой