Вы с помощью таких задач ищете людей с опытом, чтобы они и в проде такое выдавали и считали это нормой?
Вы уверены, что правильно понимаете понятие race condition? Это не риторический вопрос, т.к. если мы запросили 2 разных url через этот хук, то это не состояние гонки. Гонка это когда у вас 2 одинаковых запроса идут и кто первый ответил, тот и молодец))) А у вас по коду получается, что компонент при монтировании/размонтировании просто для вида локальную переменную поменяет и тут же вычистит. Запрос при этом может уйти на сервер, исполнится там с 200 OK и, например, в случае с JWT, обновит токен с ответом вникуда, что повлечёт следом некорректную работу на фронте (невалидный токен).
У меня предложение к автору: а теперь эту ToDo нужно расширить и ввести кнопки массового переключения: все отмеченные становятся не отмеченными и наоборот. При этом нужно отправить запрос на сервер об этом и результат обработать выводом с проверкой, что список действительно нужно перерисовать или показать тостер с сообщением, что данные на сервере не обновились (500 ошибка пришла). Как будет выглядеть такое решение с вашей структурой?
В конце статье есть раздел Ссылки и ресурсы, там ссылка на фронт.
По мета-тегам: OG можно скриптом добавить, да, а вот органические типа description хоть и можно, но поисковики такое не любят. К тому же скриптовые OG тот же вотсапп вроде как не генерирует, в отличии от телеги. Так что скорее это костыль, а не архитектурно правильное решение (пилить проект как SPA). Но это сугубу моё ИМХО.
Судя по фронт-репе, там вообще ещё ничего из описанного не используется толком))) Даже рейс-кондишн для рефреш-токена никак не отлавливается, что говорит о том, что идея-то у проект хорошая, но реализация подкачает скорее всего. Особенно в моменте, когда проекту потребуется отдавать мета-теги для генерации превью в месенджерах и микроразметку для поисковиков, а стек скажет: надо было раньше про SSR думать)))
Это они просто решили так свою же ТП закрыть и полностью на ботов перевести) Удобно же: делаешь скрипт про ожидание и через 30 минут тебя сбрасывает не сотрудник, а "техническое ограничение".. идёшь в чат, а там бот! Профит.
Вставлю свои 5 копеек, т.к. большинство гайдов в сети как под копирку и нигде не встречал до банального простой вещи. Тёмное и светлое оформление это не "theme", а "theme mode".
Это стоит учитывать при проектировании системы, если планируете потом переиспользовать компоненты UI. Такой подход даст возможность разделить логику цветовой палитры и её использования в светлом/тёмном режиме.
Конкретно в вашем примере - малиновая тема оформления по случаю дня рождения компании должна быть доступна и для светлого и для тёмного режима, режим нужно тягать из системных настроек через window.matchMedia и создавать 2 контекста, либо расширять текущий, чтобы были и data-theme и data-theme-mode. Вот тогда будет "по феншую")))
У меня 2 вопроса/замечания:
Вы с помощью таких задач ищете людей с опытом, чтобы они и в проде такое выдавали и считали это нормой?
Вы уверены, что правильно понимаете понятие race condition? Это не риторический вопрос, т.к. если мы запросили 2 разных url через этот хук, то это не состояние гонки. Гонка это когда у вас 2 одинаковых запроса идут и кто первый ответил, тот и молодец))) А у вас по коду получается, что компонент при монтировании/размонтировании просто для вида локальную переменную поменяет и тут же вычистит. Запрос при этом может уйти на сервер, исполнится там с 200 OK и, например, в случае с JWT, обновит токен с ответом вникуда, что повлечёт следом некорректную работу на фронте (невалидный токен).
У меня предложение к автору: а теперь эту ToDo нужно расширить и ввести кнопки массового переключения: все отмеченные становятся не отмеченными и наоборот. При этом нужно отправить запрос на сервер об этом и результат обработать выводом с проверкой, что список действительно нужно перерисовать или показать тостер с сообщением, что данные на сервере не обновились (500 ошибка пришла). Как будет выглядеть такое решение с вашей структурой?
В конце статье есть раздел Ссылки и ресурсы, там ссылка на фронт.
По мета-тегам: OG можно скриптом добавить, да, а вот органические типа description хоть и можно, но поисковики такое не любят. К тому же скриптовые OG тот же вотсапп вроде как не генерирует, в отличии от телеги. Так что скорее это костыль, а не архитектурно правильное решение (пилить проект как SPA). Но это сугубу моё ИМХО.
Судя по фронт-репе, там вообще ещё ничего из описанного не используется толком))) Даже рейс-кондишн для рефреш-токена никак не отлавливается, что говорит о том, что идея-то у проект хорошая, но реализация подкачает скорее всего. Особенно в моменте, когда проекту потребуется отдавать мета-теги для генерации превью в месенджерах и микроразметку для поисковиков, а стек скажет: надо было раньше про SSR думать)))
Это они просто решили так свою же ТП закрыть и полностью на ботов перевести) Удобно же: делаешь скрипт про ожидание и через 30 минут тебя сбрасывает не сотрудник, а "техническое ограничение".. идёшь в чат, а там бот! Профит.
Вставлю свои 5 копеек, т.к. большинство гайдов в сети как под копирку и нигде не встречал до банального простой вещи. Тёмное и светлое оформление это не "theme", а "theme mode".
Это стоит учитывать при проектировании системы, если планируете потом переиспользовать компоненты UI. Такой подход даст возможность разделить логику цветовой палитры и её использования в светлом/тёмном режиме.
Конкретно в вашем примере - малиновая тема оформления по случаю дня рождения компании должна быть доступна и для светлого и для тёмного режима, режим нужно тягать из системных настроек через window.matchMedia и создавать 2 контекста, либо расширять текущий, чтобы были и data-theme и data-theme-mode. Вот тогда будет "по феншую")))
Тот момент, когда читая статью, я понял, что кажется учился в школе с этим Стасом ? Детектив с эффектом присутствия)))
Попробую предложить вариант: CSS Tree Shaking, Storybook и Emmet LiveStyle.