А вы пробовали действительно применять все то, о чем вы пишите на практике? Я про скриншоты и тестирование через play-функции? Скриншоты настроить без использования их хроматика - не очень простая задача. Play-функции - кривая обертка над playwright. Тесты гораздо более хрупкие. А постоянные релизы, ломающие предыдущую функциональность... Они только библиотеку тестов переписывали несколько раз. Как я понимаю, все ради монетизации хроматика... Я бы вот вообще не рекомендовал использовать эту кривую поделку в нормальных проектах. Там только модулей за 10+ тысяч...
симптомы глубокой системной болезни, которую можно назвать «постсоветский управленческий синдром»
Так уж прям "постсоветский" ?
Это приводит к внедрению нерабочих схем, потере ценных идей, рожденных «на передовой», и созданию в коллективе атмосферы страха, где люди предпочитают молчать, даже видя очевидные ошибки.
Ага. А рационализаторов в клятом совке расстреливала кровавая гебня. Или даже лично Сталин после обеда.
Фундаментом же многих проблем остается отношение к персоналу как к статье расходов, а не к ключевому активу.
Я так понимаю, фразу Сталина "кадры решают все" Вы не слышали..
Будущее строится не на выжимании соков, а на выращивании талантов.
Это в совке могли уволить одним днем, а бесплатные кружкИ для детей - подарок атлантов капиталистического рая?
О, кажется у нас возник диспут... Это я люблю ) Ну еще мы, кажется, не совсем поняли друг друга, когда говорили об утечках памяти. Я имел в виду утечки при удалении слушателя, когда стор остается. Вот и дал демку с удалением output, когда через некоторое время надпись в консоли исчезает, поскольку сборщик мусора отработал.
А это значит что никаких утечек при удалении стора/компонента.
К сожалению, относительно функции прослушки это не так. Вот я создал демку. При удалении слушателя не удаляется функция. Только вручную, поскольку ссылка на слушатель (переменнаяoutput, сохраненная в замыкании) так и хранится в памяти. В консоли постоянная ошибка Cannot set properties of null (setting 'textContent'). Что полностью совпадает с поведением самой первой реализации. Если удалить стор, слушатели удалятся в обоих случаях.
За использование EventTarget отдельный респект и уважуха )
Не пойму, а чем это принципиально отличается от самой первой реализации? Эмиттер неявно будет хранить все слушатели. Остальные проблемы там и остались вроде... Ну и вместо store.value = "abc" нужно будет писать store.set({value: "abc"}).
Вы имеете в виду CustomEvent? Если да, то их нужно диспатчить на уровне window (или document), поскольку потребители могут находиться вообще в разных местах DOM-дерева, и эти события не поймаешь на всплытии/погружении. Поэтому при удалении потребителя, нужно будет принудительно очищать слушатель, чтобы не засорять память. Поэтому где-то хранить слушатели все-таки придется.
1) а есть реализованный пример нескольких страниц, чтобы можно было увидеть, как там подгружаются скрипты и стили при переходе по ссылкам? Что-то у меня подозрение, что если сделать все по-уму, там будет далеко не один экран.. 2) ну.. я бы не сказал, что это прям вот декларативно ) Кроме того, с таким подходом очень резко ограничивается область применения Fusor. Опять же непонятно, чем же это лучше тех же веб-компонентов, если фактически update вызывается императивно.
Особо нет времени смотреть на код. Просмотрел только бегло. Сразу возникли вопросы. 1) я вижу, что в примере роуты у Вас через #. Значит ли это, что вы сразу полностью грузите все приложение со всеми страницами? Или это только для примера в codepen? 2) разве в вашем фреймворке (то, от чего я призываю отказаться) можно вставлять теги как есть? Или только через вашу абстракцию? 3) если все-таки нормальные теги (элементы) вставлять можно, то как вы намерены обрабатывать случаи, когда эти элементы исчезают из DOM? Допустим, элемент уничтожен каким-либо способом. Как в таком случае отследить этот момент и очистить обработчик, чтобы ссылка на этот элемент в обработчике не препятствовала работе сборщика мусора?
Ну и динамические роуты сейчас нужны плюс-минус постоянно. Даже для сайтов. Поэтому важный момент.
Логично. Добавил пример. https://grigorenkosergey.github.io/native-SPA/pages/dynamic/12 Правда, реализовал на коленках, может что-то еще упустил. Может потом внесу UPD в статью. По приоритетам.. Если высчитывать совпадение с от наиболее специфичного к наименее специфичному, то особых проблем быть не должно.
А Вы эти мигания на практике наблюдали? Потому что вообще говоря, если делать правильно, их быть не должно.
На MDN постоянно вижу, когда перехожу по страницам. Несмотря на то, что там стили и js полностью берутся из кеша.
Хм. Не могу придумать подходящий кейс.
Ну.. Мне тоже сходу в голову не приходит ) Но я уже говорил об этом, что "React со своим роутером нанес непоправимый урон моей психике". Потом проведу чуть более полное исследование этого вопроса.
P.S. на всякий случай: рассматривали для Ваших задач какой-нибудь Astro, или solid-start?
Ну да, как вариант. Только потом TS прикрутить сложно будет без сборщика. Ну и я именно исходные htm/css файлы использовал для того, чтобы автодополнение, которое дает emmet из коробки работало безупречно. Например, такие штуки .parent>.child*5.
Кстати, интересно что конкретно не получилось сделать с vite.
Честно говоря, уже не помню сути... Помню, что там внутренний сервер, который поднимается при разработке, работает совсем не так, как должен работать реальный сервер после деплоя (или как я изначально ожидал). Вроде еще были проблемы при предобработке html - файлов... Ну а может дело во врожденной кривизне рук ) Насчет необходимости роутера.. Здесь вопрос, конечно, спорный. Я его сделал для возможности разработки именно приложений, в которых есть какое-либо сохраняемое состояние. Динамические роуты - здесь вопрос добавления нескольких регулярок и небольшой доработки. Я не стал с этим заморачиваться по причине отсутствия необходимости. Ну и js выполняется не мгновенно. До того момента как JS отработает и отрисуются наши веб-компоненты пройдет некоторое время. Поэтому могут быть мигания. Когда же в окне компоненты уже зарегистрированы - такой проблемы нет.
А вы пробовали действительно применять все то, о чем вы пишите на практике?
Я про скриншоты и тестирование через play-функции? Скриншоты настроить без использования их хроматика - не очень простая задача. Play-функции - кривая обертка над playwright. Тесты гораздо более хрупкие.
А постоянные релизы, ломающие предыдущую функциональность... Они только библиотеку тестов переписывали несколько раз. Как я понимаю, все ради монетизации хроматика...
Я бы вот вообще не рекомендовал использовать эту кривую поделку в нормальных проектах. Там только модулей за 10+ тысяч...
Опять подмена понятий.
Так уж прям "постсоветский" ?
Ага. А рационализаторов в клятом совке расстреливала кровавая гебня. Или даже лично Сталин после обеда.
Я так понимаю, фразу Сталина "кадры решают все" Вы не слышали..
Это в совке могли уволить одним днем, а бесплатные кружкИ для детей - подарок атлантов капиталистического рая?
Может вот эта статья подойдет https://habr.com/ru/articles/962778/
О, кажется у нас возник диспут... Это я люблю )
Ну еще мы, кажется, не совсем поняли друг друга, когда говорили об утечках памяти. Я имел в виду утечки при удалении слушателя, когда стор остается.
Вот и дал демку с удалением output, когда через некоторое время надпись в консоли исчезает, поскольку сборщик мусора отработал.
К сожалению, относительно функции прослушки это не так. Вот я создал демку. При удалении слушателя не удаляется функция. Только вручную, поскольку ссылка на слушатель (переменная
output, сохраненная в замыкании) так и хранится в памяти. В консоли постоянная ошибкаCannot set properties of null (setting 'textContent'). Что полностью совпадает с поведением самой первой реализации.Если удалить стор, слушатели удалятся в обоих случаях.
За использование EventTarget отдельный респект и уважуха )
Не пойму, а чем это принципиально отличается от самой первой реализации? Эмиттер неявно будет хранить все слушатели. Остальные проблемы там и остались вроде... Ну и вместо
store.value = "abc"нужно будет писатьstore.set({value: "abc"}).Вы имеете в виду CustomEvent? Если да, то их нужно диспатчить на уровне window (или document), поскольку потребители могут находиться вообще в разных местах DOM-дерева, и эти события не поймаешь на всплытии/погружении. Поэтому при удалении потребителя, нужно будет принудительно очищать слушатель, чтобы не засорять память. Поэтому где-то хранить слушатели все-таки придется.
1) а есть реализованный пример нескольких страниц, чтобы можно было увидеть, как там подгружаются скрипты и стили при переходе по ссылкам? Что-то у меня подозрение, что если сделать все по-уму, там будет далеко не один экран..
2) ну.. я бы не сказал, что это прям вот декларативно ) Кроме того, с таким подходом очень резко ограничивается область применения Fusor. Опять же непонятно, чем же это лучше тех же веб-компонентов, если фактически update вызывается императивно.
Особо нет времени смотреть на код. Просмотрел только бегло. Сразу возникли вопросы.
1) я вижу, что в примере роуты у Вас через #. Значит ли это, что вы сразу полностью грузите все приложение со всеми страницами? Или это только для примера в codepen?
2) разве в вашем фреймворке (то, от чего я призываю отказаться) можно вставлять теги как есть? Или только через вашу абстракцию?
3) если все-таки нормальные теги (элементы) вставлять можно, то как вы намерены обрабатывать случаи, когда эти элементы исчезают из DOM? Допустим, элемент уничтожен каким-либо способом. Как в таком случае отследить этот момент и очистить обработчик, чтобы ссылка на этот элемент в обработчике не препятствовала работе сборщика мусора?
Логично. Добавил пример. https://grigorenkosergey.github.io/native-SPA/pages/dynamic/12 Правда, реализовал на коленках, может что-то еще упустил.
Может потом внесу UPD в статью.
По приоритетам.. Если высчитывать совпадение с от наиболее специфичного к наименее специфичному, то особых проблем быть не должно.
На MDN постоянно вижу, когда перехожу по страницам. Несмотря на то, что там стили и js полностью берутся из кеша.
Ну.. Мне тоже сходу в голову не приходит ) Но я уже говорил об этом, что
"React со своим роутером нанес непоправимый урон моей психике". Потом проведу чуть более полное исследование этого вопроса.
Нет. Посмотрю как-нибудь.
Ну да, как вариант. Только потом TS прикрутить сложно будет без сборщика. Ну и я именно исходные htm/css файлы использовал для того, чтобы автодополнение, которое дает emmet из коробки работало безупречно. Например, такие штуки .parent>.child*5.
Честно говоря, уже не помню сути... Помню, что там внутренний сервер, который поднимается при разработке, работает совсем не так, как должен работать реальный сервер после деплоя (или как я изначально ожидал).
Вроде еще были проблемы при предобработке html - файлов... Ну а может дело во врожденной кривизне рук )
Насчет необходимости роутера.. Здесь вопрос, конечно, спорный. Я его сделал для возможности разработки именно приложений, в которых есть какое-либо сохраняемое состояние. Динамические роуты - здесь вопрос добавления нескольких регулярок и небольшой доработки. Я не стал с этим заморачиваться по причине отсутствия необходимости.
Ну и js выполняется не мгновенно. До того момента как JS отработает и отрисуются наши веб-компоненты пройдет некоторое время. Поэтому могут быть мигания. Когда же в окне компоненты уже зарегистрированы - такой проблемы нет.