Probably in the future I am going to cover those subjects as well, thanks for the feedback. Here I just wanted to make the point that it’s not right (in my opinion) to combine type with its functionality, because function’s arguments must be equally considered as just a parts of one process which a function represents.
Я рад, что вам понравился мой дизайн, над ним то я как раз очень много потел — хотелось именно простоты и понятности в подходе. А так конечно, реализацию можете сделать проще — безусловно. Суть в том что я использую чисто функциональный подход так как я люблю так писать код, однако я понимаю, что большинство людей любит использовать более простые и привычные абстракции.
Более того я понимаю, почему хочется самому написать такое — это выглядит очень просто, однако это только на первый взгляд.
Еще добавлю, что нехватка MutationObserver особенно будет видна для маппинга ответов от ajax запросов на HTML. Там тем подходом, что вы описали, будут видны задержки.
Спасибо, что заценили. Однако скажу, что самому это реализовать — нужен запас терпения, так как там очень много деталей нужно обдумать, чтобы и дизайн для пользователя был простой и интуитивно понятный, и также чтобы работало не глючно.
Например то, что нужно использовать обязательно MutationObserver и <template/> вместо нативной реализации кастомных элементов — я не сразу увидел, а это два самых главных момента в этом подходе.
Все не так просто, я уверен вы скрипт подключаете в конце <body/>, а это не очень гуд, нужно делать запросы во время рендеринга — то есть использовать кастомные элементы + MutationObserver. Я в начале тоже думал, что все просто, а оказалось как всегда.
Никто не мешает закэшировать файл.
А почему велосипед? Просто я был бы счастлив найти готовое решение, которое позволяет также просто делать описанные вещи, а не писать что-то самому.
Если вы про это angular.io/api/common/AsyncPipe, то для меня как-то не очевидно как это должно работать. В любом случае, цель была делать простые вещи через html. Решение в EHTML в свою очередь интуитивно понятно. Я не говорю, что делать сложные веб приложения через эту либу — это гарантированно хороший выбор, однако для простых вещей как например отображение данных с сервера — она предлагает самое простое решение, что я видел.
Идеи схожи возможно, но насколько я помню там реализация идет через js директивы, то есть там нельзя делать например ajax запросы просто через HTML код.
По сути также как и с любым сайтом, который как-то использует JavaScript. Только в данном случае предполагается, что вы подключаете js либу, а дальше пишите HTML.
На счет того как это дружит с разными либами/фреймворками сложно сказать, так как надо смотреть на специфику тех технологий, что вы хотите использовать. Однако скажу, что EHTML следует спецификации кастомных элементов и атрибутов в отличии от практически всех библиотек и фреймворков таких как React или Angular, так что по крайней мере конфликта неймспейсов быть не должно.
Probably in the future I am going to cover those subjects as well, thanks for the feedback. Here I just wanted to make the point that it’s not right (in my opinion) to combine type with its functionality, because function’s arguments must be equally considered as just a parts of one process which a function represents.
А что за Fetch? Вроде ajax запросы можно делать через e-json.
А что за Fetch? Вроде ajax запросы можно делать через
e-json.Более того я понимаю, почему хочется самому написать такое — это выглядит очень просто, однако это только на первый взгляд.
Например то, что нужно использовать обязательно
MutationObserverи<template/>вместо нативной реализации кастомных элементов — я не сразу увидел, а это два самых главных момента в этом подходе.<body/>, а это не очень гуд, нужно делать запросы во время рендеринга — то есть использовать кастомные элементы + MutationObserver. Я в начале тоже думал, что все просто, а оказалось как всегда.Да и потом — у меня реализация
<e-html/>не скажу что сложная: github.com/Guseyn/EHTML/blob/master/src/E/E_HTML.jsКак видите довольно таки элегантная функциональная композиция — и элемент работает.
Впрочем можете конечно попробовать — возможно у вас выйдет лучше.
Ну кто знает, вдруг это будет популярным. А так вы правы конечно.
А почему велосипед? Просто я был бы счастлив найти готовое решение, которое позволяет также просто делать описанные вещи, а не писать что-то самому.
На счет того как это дружит с разными либами/фреймворками сложно сказать, так как надо смотреть на специфику тех технологий, что вы хотите использовать. Однако скажу, что EHTML следует спецификации кастомных элементов и атрибутов в отличии от практически всех библиотек и фреймворков таких как React или Angular, так что по крайней мере конфликта неймспейсов быть не должно.