Подход имеет смысл когда необходимо реализовать уникальный дизайн системы по макетами с нуля. P.S.: <input type="submit" /> желательно вынести так же в отдельный компонент.
Попробовал настроить под модель Ollama в webstorm, так там баг с выпадающим списком провайдеров, он отображается ниже основного диалога. Может можно как-то через конфиг задать дефолтный провайдер?
Имеется в виду случай, когда приложение обновилось в момент заполнения формы. Соответственно бандл приложения так же может измениться, и если не перезагрузить страницу, то есть вероятность перехода по старым кускам кода (может тут не прав). Если страницу не перезагружать, то насколько понимаю, старые части бандла будут браться из кэша за который отвечает service worker. И вот тут самый главный вопрос - в какой момент времени будет загружен новый бандл? Как-то в фоне без обновления страницы или нет? И не сломает ли обновление бандла в фоне существующее состояние приложения (открытые диалоги, заполнения форм и прочее). Получилось довольно таки сумбурно, но думаю основной посыл понятен.
Как вы обновляете service worker для PWA в которых есть формы? По идее нужно реализовывать какое-то действие подтверждения, чтобы данные которые ввел пользователь в форму, не сбросились при перезагрузке страницы.
Могу предположить, что у автора статьи простые проекты, которые не предусматривают такую сложную функциональность в виде порционной загрузки данных. Притом безоговорочно и даже не обсуждается, будет только так и больше никак.
Всё что выходит за рамки условных "лендингов", сразу вызывает множество вопросов...
Я бы еще понял, если бы топили за какой-нибудь CMS Drupal или Wordpress, где есть механизмы динамической загрузки HTML и стандартные средства на уровне API фреймворка для этого. Но писать всё это вручную - считай подвиг совершить. Но повторюсь, такое и не требуется, насколько понимаю.
А как вы будете расширять ваш MVP, когда к вам придут и спросят "мобильное приложение мне сделайте"?
Можно же сразу реализовать API на бэкенде (самый простой REST) и с ним работать как в вебе так и на мобильных платформах. А так, придется еще и rest api допиливать бэкендеру. Слишком большая нагрузка идет на него - и макеты поддерживай, и API, и еще тесты для всего этого пиши (вижу радость в его глазах).
Про проблемы фронта, которые вы озвучили - это банальные ошибки, которые быстро решаются. И вопрос синхронизации состояния UI с URL лучше сразу прописывать отдельным требованием в ТЗ, и не интерпретировать как "само разумеющееся". "Само разумеющиеся" - это если нет в ТЗ, значит не делаем (субъективное мнение).
Претензию про SEO вообще не понял, давно уже всё решается фреймворками Nuxt или Next, которые умеют в SSR.
Почему такое пренебрежительное отношение к фронтендерам (естественно к уровню мидл+) тоже не понял. Я тоже был бэкендером и использовал тот подход, о котором вы пишете. Данный подход имеет право на жизнь, но процент таких проектов даже среди MVP сейчас не значителен. Если у вас такая специфика работы и подход эффективен - то ОК, рад за вас. Но почему при этом, жесткой критике придается "стандартный подход" - загадка? Ведь в вашем подходе тоже много минусов.
В новой версии при наведении на громкость и прокручивании колеса мыши ничего не происходит. В старой версии - менялась громкость. Так же при нажатии на "пробел" трек воспроизводился/ставился на паузу вне зависимости от фокуса на кнопке play. Аналогично и другие хоткеи, которые так же не предусмотрены: перемотка стрелками, l-следующий трек и прочее. Старые фичи так и не завезли, но видимо никого это не волнует.
Про многошаговасть - какое-то усложнение. Например, при установке какого-то софта на свой ПК вы часто видели, чтобы "сброс" редиректил куда-то на шаг назад. На то он и сброс, чтобы очистить состояние (считайте "отмена"). А для предыдущего шага - кнопка "назад".
Про сохранение состояния в localStorage - это всего лишь самый банальный вариант реализации, и понятное дело, что данные черновика нужно хранить на сервере, как минимум еще и для синхронизации с мобильным приложением. Но для MVP и localStorage может вполне подойти...
Никто не видел примеров улучшений архитектуры и не делал этого? А как же те сотни докладов на конференциях "как мы все переписали и стали жить лучше"? В общем, позволю не согласится с вашим тезисом (в том числе и про "а тем более сам не делал").
Не вижу смысла продолжать дискуссию, все высказались и остались при своем мнении. За статью спасибо :)
Мы сейчас размышляем над задачей, которая точно не сформулирована и всех нюансов не учесть.
Даже если всё-таки форма многошаговая, то нет ничего отталкивающего с точки зрения UX в кнопке "сброс". Если значение в словаре на бэке удалили (заархивировали), а на клиенте оно есть - тоже не вижу проблем сделать соответствующие проверки и очищать поле. Далее, можно придумывать требования какие угодно - смена набора полей для формы, внедрение версионирования данных и прочее...
Я о том, что нужно соблюдать баланс между простотой выбранного решения и тем, как данное решение можно масштабировать. Чтобы не оказалось так, что новые функции системы требуют полного переделывания существующей архитектуры. Хоть и "нет идеальной архитектуры и решений", но мы можем существенно упростить себе жизнь, пытаясь придерживаться масштабированности, расширяемости и универсальности системы.
Вы описываете принцип YAGNI и я с ним полностью согласен. То есть не стоит делать фичи, в которых нет острой необходимости. Если такие кейсы редкость (как озвучил в сообщении ранее) и в целом не критично, тогда все становится понятно. Но если придется решать такую задачу, то я бы наверное сделал что-то на подобии черновиков. Например, как в телеграме, пишем сообщение и меняем чат (не отправляя сообщения). После того как возвращаемся к чату, где было написано сообщение - показываем черновик текста в инпуте. Так и с формой - сохраняем данные (хоть в тот же localStorage), и при перезагрузке страницы получаем то, что было введено ранее.
Учитываете ли вы введенные данные на формах? Например, пользователь заполнял форму и дошел до "сложного" компонента, который загружает данные по отдельному API. И если выяснится, что после выполнения запроса версия фронта устарела, то потребуется обновить страницу. Что будет с введенными данными на форме? Или у вас всё предусмотрено или в принципе нет таких кейсов?
А можете подробнее рассказать об архитектуре фронтовых расширений, использовали ли вы module federation или какой-то другой инструмент для микрофронтов?
Или я не разобрался или что-то не то с хоткеями... В старой версии пробел запускал/останавливал проигрывание, а при наведении на громкость, можно было поменять значение колесом мыши без лишних кликов. Теперь этого нет, и стало не особо удобно в этом плане :(
В статье больше про SOLID, но и про чистый код тоже есть здравые мысли.
Подход имеет смысл когда необходимо реализовать уникальный дизайн системы по макетами с нуля.
P.S.:
<input type="submit" />желательно вынести так же в отдельный компонент.В общем нужно читать доку в любом случае :) Спасибо.
Попробовал настроить под модель Ollama в webstorm, так там баг с выпадающим списком провайдеров, он отображается ниже основного диалога. Может можно как-то через конфиг задать дефолтный провайдер?
Спасибо за разъяснение.
Имеется в виду случай, когда приложение обновилось в момент заполнения формы. Соответственно бандл приложения так же может измениться, и если не перезагрузить страницу, то есть вероятность перехода по старым кускам кода (может тут не прав). Если страницу не перезагружать, то насколько понимаю, старые части бандла будут браться из кэша за который отвечает service worker. И вот тут самый главный вопрос - в какой момент времени будет загружен новый бандл? Как-то в фоне без обновления страницы или нет? И не сломает ли обновление бандла в фоне существующее состояние приложения (открытые диалоги, заполнения форм и прочее). Получилось довольно таки сумбурно, но думаю основной посыл понятен.
Как вы обновляете service worker для PWA в которых есть формы? По идее нужно реализовывать какое-то действие подтверждения, чтобы данные которые ввел пользователь в форму, не сбросились при перезагрузке страницы.
Могу предположить, что у автора статьи простые проекты, которые не предусматривают такую сложную функциональность в виде порционной загрузки данных. Притом безоговорочно и даже не обсуждается, будет только так и больше никак.
Всё что выходит за рамки условных "лендингов", сразу вызывает множество вопросов...
Я бы еще понял, если бы топили за какой-нибудь CMS Drupal или Wordpress, где есть механизмы динамической загрузки HTML и стандартные средства на уровне API фреймворка для этого. Но писать всё это вручную - считай подвиг совершить. Но повторюсь, такое и не требуется, насколько понимаю.
Подход рабочий, только вот с офлайн режимом возникают вопросы.
В основном заказчик сам не знает чего он хочет :)
Ну основной посыл понятен - убрать оверинжиниринг для простых проектов. За статью, спасибо.
А как вы будете расширять ваш MVP, когда к вам придут и спросят "мобильное приложение мне сделайте"?
Можно же сразу реализовать API на бэкенде (самый простой REST) и с ним работать как в вебе так и на мобильных платформах. А так, придется еще и rest api допиливать бэкендеру. Слишком большая нагрузка идет на него - и макеты поддерживай, и API, и еще тесты для всего этого пиши (вижу радость в его глазах).
Про проблемы фронта, которые вы озвучили - это банальные ошибки, которые быстро решаются. И вопрос синхронизации состояния UI с URL лучше сразу прописывать отдельным требованием в ТЗ, и не интерпретировать как "само разумеющееся". "Само разумеющиеся" - это если нет в ТЗ, значит не делаем (субъективное мнение).
Претензию про SEO вообще не понял, давно уже всё решается фреймворками Nuxt или Next, которые умеют в SSR.
Почему такое пренебрежительное отношение к фронтендерам (естественно к уровню мидл+) тоже не понял. Я тоже был бэкендером и использовал тот подход, о котором вы пишете. Данный подход имеет право на жизнь, но процент таких проектов даже среди MVP сейчас не значителен. Если у вас такая специфика работы и подход эффективен - то ОК, рад за вас. Но почему при этом, жесткой критике придается "стандартный подход" - загадка? Ведь в вашем подходе тоже много минусов.
Да, тут согласен, поддержка горячих клавиш есть, спасибо (не досмотрел). Правда изменили "включить/выключить музыку" на "k" вместо пробела.
В новой версии при наведении на громкость и прокручивании колеса мыши ничего не происходит. В старой версии - менялась громкость. Так же при нажатии на "пробел" трек воспроизводился/ставился на паузу вне зависимости от фокуса на кнопке play. Аналогично и другие хоткеи, которые так же не предусмотрены: перемотка стрелками, l-следующий трек и прочее. Старые фичи так и не завезли, но видимо никого это не волнует.
Про многошаговасть - какое-то усложнение. Например, при установке какого-то софта на свой ПК вы часто видели, чтобы "сброс" редиректил куда-то на шаг назад. На то он и сброс, чтобы очистить состояние (считайте "отмена"). А для предыдущего шага - кнопка "назад".
Про сохранение состояния в localStorage - это всего лишь самый банальный вариант реализации, и понятное дело, что данные черновика нужно хранить на сервере, как минимум еще и для синхронизации с мобильным приложением. Но для MVP и localStorage может вполне подойти...
Никто не видел примеров улучшений архитектуры и не делал этого? А как же те сотни докладов на конференциях "как мы все переписали и стали жить лучше"? В общем, позволю не согласится с вашим тезисом (в том числе и про "а тем более сам не делал").
Не вижу смысла продолжать дискуссию, все высказались и остались при своем мнении. За статью спасибо :)
Мы сейчас размышляем над задачей, которая точно не сформулирована и всех нюансов не учесть.
Даже если всё-таки форма многошаговая, то нет ничего отталкивающего с точки зрения UX в кнопке "сброс". Если значение в словаре на бэке удалили (заархивировали), а на клиенте оно есть - тоже не вижу проблем сделать соответствующие проверки и очищать поле. Далее, можно придумывать требования какие угодно - смена набора полей для формы, внедрение версионирования данных и прочее...
Я о том, что нужно соблюдать баланс между простотой выбранного решения и тем, как данное решение можно масштабировать. Чтобы не оказалось так, что новые функции системы требуют полного переделывания существующей архитектуры. Хоть и "нет идеальной архитектуры и решений", но мы можем существенно упростить себе жизнь, пытаясь придерживаться масштабированности, расширяемости и универсальности системы.
Вы описываете принцип YAGNI и я с ним полностью согласен. То есть не стоит делать фичи, в которых нет острой необходимости.
Если такие кейсы редкость (как озвучил в сообщении ранее) и в целом не критично, тогда все становится понятно.
Но если придется решать такую задачу, то я бы наверное сделал что-то на подобии черновиков. Например, как в телеграме, пишем сообщение и меняем чат (не отправляя сообщения). После того как возвращаемся к чату, где было написано сообщение - показываем черновик текста в инпуте.
Так и с формой - сохраняем данные (хоть в тот же localStorage), и при перезагрузке страницы получаем то, что было введено ранее.
Учитываете ли вы введенные данные на формах? Например, пользователь заполнял форму и дошел до "сложного" компонента, который загружает данные по отдельному API. И если выяснится, что после выполнения запроса версия фронта устарела, то потребуется обновить страницу. Что будет с введенными данными на форме? Или у вас всё предусмотрено или в принципе нет таких кейсов?
Ремонт теслы в гараже - будущее наступило.
А можете подробнее рассказать об архитектуре фронтовых расширений, использовали ли вы module federation или какой-то другой инструмент для микрофронтов?
Или я не разобрался или что-то не то с хоткеями... В старой версии пробел запускал/останавливал проигрывание, а при наведении на громкость, можно было поменять значение колесом мыши без лишних кликов. Теперь этого нет, и стало не особо удобно в этом плане :(
В некоторых случаях, полезно записывать видео с воспроизведением бага.