Я смотрел пару лет назад, тогда мне показалось, что инструмент сам по себе по сложности сильно превосходит задачи, которые он решает. Выглядит, конечно, как реактивный двигатель производства иных цивилизаций. Не то что бы $mol та штука, в которую можно быстро вкатиться с учётом того, что нужно освоить ЯП, если в этом изменений не было )) так что, боюсь, потребуется времени больше чем на что-либо другое (более очевидное).
В остальном, Дмитрий молодец, хорошая штука. К этому нужно делать что-то вроде обучающего модуля, чтоб проще было вкатиться
Кстати, да. Под реактивностью обычно хочется видеть как минимум Proxy-объект. Это несложно, но это должно быть абстрагировано от UI - отсюда следует, что это не проблема управления вкладками или прочим UI, а скорее, подписка на изменение состояния (и должно быть описано отдельно)
Это интересный эксперимент, но, кмк, для простого лендинга (или другого контента со статической разметкой). Работа построенная на мутациях DOM напрямую в растущем проекте ведёт к росту императивного кода и снижению уровня абстракции и его рассеиванию (а должно быть наоборот). Да, здесь работа сводится к работе с данными - это хорошо, но я подозреваю, отказавшись от React (как заявлено в заголовке), Вы должны будете прийти к его альтернативе как минимум т.к. обновление данных - это ещё не всё, также нужна возможность описывать поведение аппки, чтоб оставаться на высоком уровне абстракции.
Это да. Как мне кажется, в fsd есть одна хорошая фундаментальная идея - разбивать бизнес-логику на слои, но вокруг этого раздута "методология" с кучей вопросов и ответов, у многих создаётся ложное представление, что этот грамотный подход присущ исключительно fsd. Достаточно сместить фокус из fsd в сторону принципиального разделения БЛ на слои, каждый из которых имеет свою зону ответственности и может быть доработан в абстракции от других - и окажется, что архитектура может быть совершенно разной (я предпочитаю древовидную) без жёстких рамок "здесь папки создаём с такими файликами, там с другими" - в итоге окажется, что fsd это только один из вариантов (кмк, не самый лучший, чтоб на нем зацикливаться)
Как-то в одной крупной компании я был свидетелем обсуждения недовольства, почему пин-код клиента для входа в приложение хранится в локал-сторадж ("это немыслимо", "что скажут безопасники"...). Но как-то недалеко от релиза я слышу "ребят, давайте запустим уже через месяц, топ-менеджмент ждать не любит". И тут я все понял...
Из личного опыта докину свои 50 копеек. Лучший инструмент - это тот который ты написал сам, т.к. он лучше всего подходит под твои задачи. В остальных случаях нужно подстраиваться под инструмент (каким бы он ни был красивым, продуманным, проработанным кем-то другим).
Пару советов насчёт тех проблем, что решил для себя, но, как вижу, не решил автор.
Совет 1. Чтоб не выгорать - не живите одним проектом; Даже если проект катится к чертям, важно сохранять позитивный настрой - тогда у него ещё есть шансы )
Совет 2. Локализуйте беспорядок до его появлении: если кто-то сделал чушь, эта помойка должна быть атомарной (где-то есть начало и конец) - вплоть до полного понимания что именно можно выпилить/заменить. Это вопросы абстракции и постановки задач.
Написанная тонна библиотек на протяжении лет развития реакта, начиная с 2013 года (я имею ввиду пакеты npm, которые пишут люди чтоб переиспользовать свой код в разных проектах) на классах сегодня может работать как же и новый код на хуках (да, есть рекомендации использовать функциональщину - от эволюции не уйдешь, к ней давно шли); а вот второй Ангуляр сломал представление о первом, что было большой ошибкой (кмк лучше бы ребрендинг) - доверия к нему уже тогда больше не стало, да и появился он позже в 2016 да ещё и с "ломающими изменениями" при переходе на второй -> его и меньше брали в прод с такими качелями (чего на тот момент ещё от него ожидать - было непонятно. Ок, про Ангуляр тогда не будем). Я к тому, что обратная совместимость - залог доверия и надёжности.
Да, пусть, реакт, библиотека, но сейчас она в топе.
Реакт в топе, потому что изначально соблюдал обратную совместимость, не ломаясь между версиями. В отличие от других (не будем показывать пальцем на Ангуляр, к примеру).
Мы про исходный код говорим (про стиль его написания). На клиенте мы увидим продукт сборки в действии (про него мы не говорим)
И не про браузер речь, разумеется, а про "хрупкий" и "надёжный" код (как написанный человеком исходник). Если нужны такие вводные, пожалуйста - мы исходим из того, что транспайлер отработал как надо, код везде выполняется одинаково, говорим только об обработке ошибок входных данных и приведена аналогия "красных лампочек в интерфейсе" как хороший пример ориентира, какая часть системы отказала в данный момент (защитное программирование в действии, "хрупкий" код не даст такого эффекта).
Хотя, допускаю, Вы могли не понять аналогию, ну да ладно.
А здесь уже про разное. Ошибки должны быть обработаны независимо от браузера. Я про Защитное программирование - думаю за ним будущее ) вы когда-нибудь бывали на каком-нибудь военном командном пункте какой-нибудь абстрактной установке? Представьте что, для каждой неисправности есть красная лампочка и табличка (это удобно, потому что это стандарт вывода ошибки) - и это модульная система, где каждый модуль легко заменяем и быстро диагностируется
Я смотрел пару лет назад, тогда мне показалось, что инструмент сам по себе по сложности сильно превосходит задачи, которые он решает. Выглядит, конечно, как реактивный двигатель производства иных цивилизаций. Не то что бы $mol та штука, в которую можно быстро вкатиться с учётом того, что нужно освоить ЯП, если в этом изменений не было )) так что, боюсь, потребуется времени больше чем на что-либо другое (более очевидное).
В остальном, Дмитрий молодец, хорошая штука. К этому нужно делать что-то вроде обучающего модуля, чтоб проще было вкатиться
Ну соррямба, atomic design system не прикрутил в этот простейший пример ) но ты молодец, что заметил
Конечно, можно вынести в конфиг настроек отдельно. Хотя, пожалуй, лучше решить это средствами чистого css - условно задать класс возможность есть.
Накидал свой пример https://habr.com/ru/articles/983268/
Кстати, да. Под реактивностью обычно хочется видеть как минимум Proxy-объект. Это несложно, но это должно быть абстрагировано от UI - отсюда следует, что это не проблема управления вкладками или прочим UI, а скорее, подписка на изменение состояния (и должно быть описано отдельно)
Это интересный эксперимент, но, кмк, для простого лендинга (или другого контента со статической разметкой). Работа построенная на мутациях DOM напрямую в растущем проекте ведёт к росту императивного кода и снижению уровня абстракции и его рассеиванию (а должно быть наоборот). Да, здесь работа сводится к работе с данными - это хорошо, но я подозреваю, отказавшись от React (как заявлено в заголовке), Вы должны будете прийти к его альтернативе как минимум т.к. обновление данных - это ещё не всё, также нужна возможность описывать поведение аппки, чтоб оставаться на высоком уровне абстракции.
Это да. Как мне кажется, в fsd есть одна хорошая фундаментальная идея - разбивать бизнес-логику на слои, но вокруг этого раздута "методология" с кучей вопросов и ответов, у многих создаётся ложное представление, что этот грамотный подход присущ исключительно fsd. Достаточно сместить фокус из fsd в сторону принципиального разделения БЛ на слои, каждый из которых имеет свою зону ответственности и может быть доработан в абстракции от других - и окажется, что архитектура может быть совершенно разной (я предпочитаю древовидную) без жёстких рамок "здесь папки создаём с такими файликами, там с другими" - в итоге окажется, что fsd это только один из вариантов (кмк, не самый лучший, чтоб на нем зацикливаться)
Как-то в одной крупной компании я был свидетелем обсуждения недовольства, почему пин-код клиента для входа в приложение хранится в локал-сторадж ("это немыслимо", "что скажут безопасники"...). Но как-то недалеко от релиза я слышу "ребят, давайте запустим уже через месяц, топ-менеджмент ждать не любит". И тут я все понял...
Из личного опыта докину свои 50 копеек. Лучший инструмент - это тот который ты написал сам, т.к. он лучше всего подходит под твои задачи. В остальных случаях нужно подстраиваться под инструмент (каким бы он ни был красивым, продуманным, проработанным кем-то другим).
Насчёт п 2. Мне тоже всегда switch-case нравился больше )
Добавьте скринов. А то запускать нет времени, а посмотреть охота, что у вас там получилось.
По Вашей наводке пошел искать. Зашёл. Поржал )
Отличное начало
Попробуйте прочитать ещё раз. Возможно не с первого раза, но что-то новое без сомнения должно открыться. Главное, не останавливайтесь на полпути )
Пару советов насчёт тех проблем, что решил для себя, но, как вижу, не решил автор.
Совет 1. Чтоб не выгорать - не живите одним проектом; Даже если проект катится к чертям, важно сохранять позитивный настрой - тогда у него ещё есть шансы )
Совет 2. Локализуйте беспорядок до его появлении: если кто-то сделал чушь, эта помойка должна быть атомарной (где-то есть начало и конец) - вплоть до полного понимания что именно можно выпилить/заменить. Это вопросы абстракции и постановки задач.
Написанная тонна библиотек на протяжении лет развития реакта, начиная с 2013 года (я имею ввиду пакеты npm, которые пишут люди чтоб переиспользовать свой код в разных проектах) на классах сегодня может работать как же и новый код на хуках (да, есть рекомендации использовать функциональщину - от эволюции не уйдешь, к ней давно шли); а вот второй Ангуляр сломал представление о первом, что было большой ошибкой (кмк лучше бы ребрендинг) - доверия к нему уже тогда больше не стало, да и появился он позже в 2016 да ещё и с "ломающими изменениями" при переходе на второй -> его и меньше брали в прод с такими качелями (чего на тот момент ещё от него ожидать - было непонятно. Ок, про Ангуляр тогда не будем). Я к тому, что обратная совместимость - залог доверия и надёжности.
Да, пусть, реакт, библиотека, но сейчас она в топе.
Реакт в топе, потому что изначально соблюдал обратную совместимость, не ломаясь между версиями. В отличие от других (не будем показывать пальцем на Ангуляр, к примеру).
В этом основной секрет "живых" фреймворков.
Ого, тут свои комменты удалять нельзя
[Комментарий удален]
(решил не комментировать обсуждение кода на языке на котором не пишу))
Я как раз не сторонник раздувать код.
Если все делать правильно, не повторяя свой код, он и будет выглядеть и весить соответственно.
Не делайте 100 проверок, делайте одну стандартно.
Мы про исходный код говорим (про стиль его написания). На клиенте мы увидим продукт сборки в действии (про него мы не говорим)
И не про браузер речь, разумеется, а про "хрупкий" и "надёжный" код (как написанный человеком исходник). Если нужны такие вводные, пожалуйста - мы исходим из того, что транспайлер отработал как надо, код везде выполняется одинаково, говорим только об обработке ошибок входных данных и приведена аналогия "красных лампочек в интерфейсе" как хороший пример ориентира, какая часть системы отказала в данный момент (защитное программирование в действии, "хрупкий" код не даст такого эффекта).
Хотя, допускаю, Вы могли не понять аналогию, ну да ладно.
А здесь уже про разное. Ошибки должны быть обработаны независимо от браузера. Я про Защитное программирование - думаю за ним будущее ) вы когда-нибудь бывали на каком-нибудь военном командном пункте какой-нибудь абстрактной установке? Представьте что, для каждой неисправности есть красная лампочка и табличка (это удобно, потому что это стандарт вывода ошибки) - и это модульная система, где каждый модуль легко заменяем и быстро диагностируется