Нет, не является, в данном примере, это не реактивность.
Когда мы накладываем на window слушатель, и чекаем текущий путь в браузере, если путь изменился - на основе этого делаю запрос к серваку и получаю нужный компонент в зависимости от состояния pathname, но чтобы данный пример был действительно реактивным, стоит использовать Proxy.
А в моем понимании реактивность - это когда у нас есть состояние и при изменении его, что то происходит (Ну тот же самый useState). Но в моем случае у меня нет прям четкого состояния.
Посмотри есть у объекта эта фунция вообще, возможно косяк с namespace или областью видимости где вызваешь её, а так сложно сказать, нужно код посмотреть
Правильный камень, но у меня в bitrix не получилось закинуть sass по другому. Так чтобы их корявый сборщик работал и собирал sass. Это все же лучше чем писать css без препроцессоров.
Тут идет речь о фронтовской части в Битрикс (да, можно выкинуть её как API, но условия бывают разные). А если конкретнее то идет речь о том, как стоит организовать работу фронтов если такие имеются, и если планируется использование каких то npm пакетов. Чтобы не подключать их через CDN и всегда была возможность пересобрать фронт. + Битрикс понадобится если на проекте есть бэкэнд модули или ООП компоненты с которыми придется взаимодействовать через BX.ajax
интересно ты придумал)
Вроде как нет, там какой то другой подход, я ошибся)
Да не, это скорее всего последняя статья или предпоследняя. Я добился чего хотел от этого кактуса)
Ахахахаахахах) есть такое)
Наверное стоило вынести в кавычки)
Нет, не является, в данном примере, это не реактивность.
Когда мы накладываем на window слушатель, и чекаем текущий путь в браузере, если путь изменился - на основе этого делаю запрос к серваку и получаю нужный компонент в зависимости от состояния pathname, но чтобы данный пример был действительно реактивным, стоит использовать Proxy.
А в моем понимании реактивность - это когда у нас есть состояние и при изменении его, что то происходит (Ну тот же самый useState). Но в моем случае у меня нет прям четкого состояния.
Мужик, ты крут) продолжай в том же духе, хотя как по мне вот настолько низкий уровень - мазохизм))) Ну в любом случае на любителя.
Удачи в создании игры)
Посмотри есть у объекта эта фунция вообще, возможно косяк с namespace или областью видимости где вызваешь её, а так сложно сказать, нужно код посмотреть
Такая же история)
Надеюсь уйдешь от битры, я как другие фреймы попробовал, больше не хочется возвращаться на этот "кртуой фреймворк"
Фронт в битриксе можно нормально писать, но да))) это полная жесть местами. Хотя в целом если писать на нативном JS, то в целом не все так плохо.
увы нет возможности(
Хорошо в следующей статье или после нее напишу
Я согласен с тобой полностью, на данный момент я просто на нем работаю, а сам переучиваюсь на другой стэк. Просто делюсь интересными наработками))
Правильный камень, но у меня в bitrix не получилось закинуть sass по другому. Так чтобы их корявый сборщик работал и собирал sass. Это все же лучше чем писать css без препроцессоров.
спасибо, уже поправил
Бог оставил нас когда битрикс появился, ты зашел туда где не светит солнце.
Неплохая статья, но очень базовая. В целом можно использовать к примеру tailwind у которого почти всегда в rem идет.
И будет вам радость. Но правда классов много будет коде и в дом дереве.
Воу, очень полезная информация. Но судя по всему это нововведение в css.
Насколько эта штука хорошо поддерживается?
Тут идет речь о фронтовской части в Битрикс (да, можно выкинуть её как API, но условия бывают разные). А если конкретнее то идет речь о том, как стоит организовать работу фронтов если такие имеются, и если планируется использование каких то npm пакетов. Чтобы не подключать их через CDN и всегда была возможность пересобрать фронт. + Битрикс понадобится если на проекте есть бэкэнд модули или ООП компоненты с которыми придется взаимодействовать через BX.ajax
Справедливое замечание) уже поправил
Я давно пробовал работать с интегрированной Vue второй версии. На тот момент поддержки - Compostion API не было