Ajax
Web design
JavaScript
Programming
HTML
Comments 28
0
Как у посетителя известного дочернего ресурса Рутрекера, у меня своеобразные ассоциации с названием библиотеки)
+7
— Давайте загоним логику в string, а потом мужественно будем её отлаживать?
— Отличная идея!

Неструктурированная и некомпилируемая AOT шаблонизация — это so 2012. Тогда это казалось модно и молодёжно. К 2019 году пора бы уже понять, что это не масштабируется. Вообще. Совсем.
0

В правилах прописывается только относительно простая логика взаимосвязи между элементами. Хардкор, требующий пошаговой отладки, пишется отдельно на js (или ts если хотите), дап просто обращается потом к этому коду.

+3
Она «относительно простая» только пока вы пишете с её помощью «относительно простые» вещи.
Алсо, отвечая на комментарий ниже, если ради структуры мне руками предлагается структурировать стринги как надо, то зачем мне вообще тогда стринги (читай: dap) in the first place?
0

Либо я не понимаю, что вы имеете в виду под "структурировать стринги", либо вы не вполне поняли, где и зачем пишутся дап-правила, и как они соотносятся с шаблонами. Можете на каком-нибудь примере показать, что вы хотите?

0
Либо я не понимаю, что вы имеете в виду под «структурировать стринги»

Задать им тип, в простейшем случае. Или хотя бы открыть их для статического анализа (инструментом, который еще написать кому-то придётся). Иначе каждая опечатка превращается или в падение шаблона, или, что в разы хуже, в его тихую неправильную работу.
0

Кому "им"? Что вы стрингами называете? Правила, которые в виде простых строк пишутся или данные, с которыми дап работает?
Если первое, то непонятно какой тип вы "им" хотите задать.
Если второе — то при чем тут стринги вообще? Сам дап работает с любыми js-данными, которые вы ему дадите. Он ими вообще не интересуется, а только передает между "участниками процесса" как есть, без всяких стрингов. А уж как их трактовать и какие типы кому назначать — это вы сами решаете.

0
Правила, которые в виде простых строк пишутся или данные, с которыми дап работает?

Вы искренне не понимаете, или пытаетесь, пардон за мой французский, играть в дурачка? Кто в вашем чудесном мире называет данные «стрингами»?

Если первое, то непонятно какой тип вы «им» хотите задать.

Соответствующий их назначению. Тип соответствующего элемента DOM, если речь про html. Тип данных, если речь идёт про ссылку на оные, и так далее. Нормальная система шаблонизации должна быть анализируема, а еще лучше — статически типизирована, иначе всё обсуждение крутости таких систем — это разговоры в пользу бедных; несколько опечаток в тысячах этих строк превращают результат в тыкву.
0

В моем чудесном мире полно разных людей, называющих стрингами совершенно разные вещи. И под "запихнуть в стринги" понимающих тоже разное. Так что не всегда и угадаешь.
Где написано, что такое "нормальная система шаблонизации" и что она кому "должна", не подскажете?

0

Алсо, если говорить про UI, там взаимосвязи между элементами кагбе и должны быть "относительно простыми" с т.з. дапа по крайней мере (хоть это и не обязательно будет просто с т.з. реакта или, прости г-ди, jQuery). Из моего опыта, если правила получаются сложные и запутанные — обычно это сигнал о плохой логике самой связи.

0

Структурировать шаблоны дап никак не мешает. Не требует, но и не мешает.

0
Вместо блоков кода — цепочки.

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")
)
0
Нет. Ничего общего, кроме того, что и тут и там присутствуют вызовы методов. Ну так они почти в любом js-коде присутствуют. В d3 цепочка методов последовательно выполняет конкретные действия над контекстом исполнения. В dap методов всего несколько (во всех примерах выше их только два: .d и .ui), и они просто назначают шаблону правила. А весь движ идет уже в этих правилах и вызываемых ими функциях.
+3
Продолжу тему ассоциаций. Напомнило $mol. Точно так же написано черт-те как, происходит черт-те что, и никому читать такой код не хочется.
+1
У винтажа за этим всем есть нормальные идеи (в частности та самая строгая типизация через препроцессинг шаблонов), просто реализация и стиль — не для людей, а для больших человекообразных роботов. А тут никаких новых идей, просто придумывание своего собственного и очень нужного (нет) языка.
0
Да, сходства есть: DOM строится из JS вместо HTML, и нотация элементов похожа на CSS. На этом, пожалуй, все. И в dap это совсем не главное. Изначально (2008 г, dapmx.org) dap был на HTML, потом на XML, и только недавно от этого всего избавился в пользу чистого JS.
Магический синтаксис — это собственно дап и есть.
0
Кто-то, кроме самого разработчика jooher этим пользовался? Есть фидбеки по процессу боевой разработки?
0
Нет, я его, можно считать, еще не публиковал. Пользуюсь сам для своих нужд около 10 лет.
Из примеров:
bankreports-dapmx-o.1gb.ru (самое первое dap-приложение 2008-го года, ныне заброшеное),
bazamagaza-com.1gb.ru (интернет-магазин/склад/crm в одном флаконе, тоже достаточно древний)
dapmx.org/apps/rockauto (простой фронтенд к магазину автозапчастей)

Боевые проекты в открытый доступ дать не могу. т.к. там живые клиенты с данными.

Если будет интерес у почтенной публики, распишу процесс подробно на примере несложного PWA приложения, которое хочу запустить в ближайшее время.
0
Привет! Обращусь вот к этой строке:
:query`https://jsonplaceholder.typicode.com/users"
Замечательно, что библиотека берет взаимодействие с сетью под капот. Однако может у меня на работе что-то не так — ux-правила требуют, чтобы при запросе показывался прелоадер, в случае ошибки корректно выводилось её содержание пользователю и дальше всякие-всякие сценарии развития ситуации.
Можно ли такое провернуть в dap? Если да — то насколько оно сложнее выглядит по сравнению с этой маркетинговой строчкой?
0
В dap можно провернуть все, что можно провернуть в js. Dap — это не «язык вместо js», а просто средство передачи данных от одного элемента другим.

Что касается обработки запросов.
Конвертор :query — для ленивых (лично я пока реально пользовался только им). Он получает данные, парсит их в соответствии с mime типом и отдает результат. Если что-то пошло не так, он просто отдает «ничто». Если вам не важно, что именно пошло не так (обычно так и есть, это нормальное для браузера поведение), и достаточно просто выдать ошибку вида «ой!», то это будет что-то вроде:
? $data=myDataUrl:query errorMessage:alert; .... используем $data ....

Если вам надо прям все знать, то можно воспользоваться более низкоуровневым конвертором :request, который просто выполняет запрос и отдает его как есть, со всеми потрохами:
$req=myDataUrl:request; ! $req.status $req.headers и т.д.

Если вы хотите вообще как-то хитро запросы делать, можете сделать свой конвертор, с блэкджеком прогрессбаром и алертами и пользоваться им: $data=myDataUrl:myFancyDataLoader

В принципе это тема для отдельной статьи. Не конкретно обработка ошибок загрузки, а использование собственных функций. То, что дапа будет выглядеть простым конвертором, на деле вполне может быть жыыырным черным ящиком, именно спрятанным под капот.
0
Было бы интересно посмотреть решение на dap стандартной задачи типа Todo-MVC, чтобы было с чем сравнить.
0
UPD там с http-запросами была проблемка (как и в оригинале): обращения с https-фронта к http-бэку блокировались браузером (mixed content). Решено.
Only those users with full accounts are able to leave comments., please.