Сообщение с retain=true будет висеть в топике и хранить состояние сенсора, к примеру. Да, не полноценное хранилище, но всегда актуальная очередь апдейтов
Состояние потока это называется, давно описано. Рецепт такой: нужна интересная задача, достаточно сложная, чтобы не быть рутинной, и достаточно простая, чтобы не напрягала. Где-то посередине между блужданием ума от скуки и напряжением ума от сложности можно поймать тот самый поток и даже отключиться от реальности. Подробнее у автора термина, М. Чиксентмихайи.
pages — собственно, страницы, могут иметь локальные хранилища для хранения состояния
widgets — всё, что рендерится в прямоугольник и отображается на экране; локальные хранилища для хранения состояния конкретного виджета
features — всё, что не рендерится в самостоятельный прямоугольник (к примеру, рендеринг геометрий на карте; набор компонентов из одной доменной области, используемые в разных виджетах) и всё, что работает с более чем одной сущностью — самый разнообразный слой, кмк
entities — запросы к API, адаптеры типа tanstack/*-query, мапперы полей, подключение mock-данных, контроллеры WebSocket-соединений, работа sync engine; компоненты, отображающие состояние строго одной сущности, i18n-словари терминов сущности, типы, enum-ы
На типичных задачах выбор только между widgets и features, и если выбор не очевиден, я начинаю с features.
Если изменилась бизнес-логика, связанная с сущностями — вы это поймёте и без подсказок, аналогично с глобальными штуками в app и shared. Какие-то из pages можно значительно параметризовать из app, и это тоже нормально.
Если прям очень необходим ещё один слой — его вполне можно завести, в этом тоже ничего страшного нет, только исчерпывающе опишите в документации. В моих проектах есть «патчи» поверх внешних соглашений; пример: Conventional Commits, но сообщение коммита должно быть на русском и отвечать на вопрос «что сделано». Это расписано в документации, и вопросов у коллег, в том числе новых, ноль. Или ESLint-конфиг от Airbnb, но с конкретно описанными изменениями.
И да, разумеется, FSD это только для UI-приложений. И да, его надо уметь готовить, однако это несложно. На мой взгляд, это система папок, плюс SOLID, насколько возможно, плюс слегка DDD-майндсет.
Хорошо бы вынести эти селекторы во внешние списки, как у AdBlock:
— это отвяжет правила от кода и позволит обновлять правила чаще, чем версии в сторе, при любых изменениях в структуре страниц магазинов
— даст возможность добавлять свои правила (а если ещё будет кнопка «отправить правило», то лично у меня появится возможность улучшить проект, но не лезть в код расширения на гитхабе)
Так и не понял, что конкретно было сделано. Ок, примеры кода — а для чего они? Заказчик планировал внедрить этот код в какие-то проекты и потом эксплуатировать эксплойт? Этот код нужно выполнить в каком-то окружении, чтобы был эффект, похожий на «я запустил shell code, я кулхацкер»? Или это часть целого проекта с закладками-бэкдорами? В чём, блин, заключался заказ?
Значит, испытание здесь в том, чтобы найти способ получить повышение в сложившейся структуре. Вариант «найти новое место работы» тоже является валидным решением.
Сообщение с
retain=trueбудет висеть в топике и хранить состояние сенсора, к примеру. Да, не полноценное хранилище, но всегда актуальная очередь апдейтовКак красиво! Это ваш стандартный тест для LLM-ок? У вас есть внутренний рейтинг таких посланий? :)
Состояние потока это называется, давно описано. Рецепт такой: нужна интересная задача, достаточно сложная, чтобы не быть рутинной, и достаточно простая, чтобы не напрягала. Где-то посередине между блужданием ума от скуки и напряжением ума от сложности можно поймать тот самый поток и даже отключиться от реальности. Подробнее у автора термина, М. Чиксентмихайи.
В относительно небольших проектах FSD отлично работает:
app — инициализация приложения, роутеров, стейт-менеджеров, i18n-библиотек
pages — собственно, страницы, могут иметь локальные хранилища для хранения состояния
widgets — всё, что рендерится в прямоугольник и отображается на экране; локальные хранилища для хранения состояния конкретного виджета
features — всё, что не рендерится в самостоятельный прямоугольник (к примеру, рендеринг геометрий на карте; набор компонентов из одной доменной области, используемые в разных виджетах) и всё, что работает с более чем одной сущностью — самый разнообразный слой, кмк
entities — запросы к API, адаптеры типа
tanstack/*-query, мапперы полей, подключение mock-данных, контроллеры WebSocket-соединений, работа sync engine; компоненты, отображающие состояние строго одной сущности, i18n-словари терминов сущности, типы, enum-ыshared — экземпляры глобальных штуковин типа HTTP-клиента, query-клиента, стейт-менеджера; функции-хелперы, кастомные компоненты поверх UI-кита
На типичных задачах выбор только между widgets и features, и если выбор не очевиден, я начинаю с features.
Если изменилась бизнес-логика, связанная с сущностями — вы это поймёте и без подсказок, аналогично с глобальными штуками в app и shared. Какие-то из pages можно значительно параметризовать из app, и это тоже нормально.
Если прям очень необходим ещё один слой — его вполне можно завести, в этом тоже ничего страшного нет, только исчерпывающе опишите в документации. В моих проектах есть «патчи» поверх внешних соглашений; пример: Conventional Commits, но сообщение коммита должно быть на русском и отвечать на вопрос «что сделано». Это расписано в документации, и вопросов у коллег, в том числе новых, ноль. Или ESLint-конфиг от Airbnb, но с конкретно описанными изменениями.
И да, разумеется, FSD это только для UI-приложений. И да, его надо уметь готовить, однако это несложно. На мой взгляд, это система папок, плюс SOLID, насколько возможно, плюс слегка DDD-майндсет.
Можно прямо в вики: https://ru.wikipedia.org/wiki/Транспорты_типа_«Либерти»
Там нынче есть возможность в настройках отключить автосохранение медиа в галерею. Потом ужать размер кэша до приемлемого. И прощай ручная чистка
Хорошо бы вынести эти селекторы во внешние списки, как у AdBlock:
— это отвяжет правила от кода и позволит обновлять правила чаще, чем версии в сторе, при любых изменениях в структуре страниц магазинов
— даст возможность добавлять свои правила (а если ещё будет кнопка «отправить правило», то лично у меня появится возможность улучшить проект, но не лезть в код расширения на гитхабе)
Так и не понял, что конкретно было сделано. Ок, примеры кода — а для чего они? Заказчик планировал внедрить этот код в какие-то проекты и потом эксплуатировать эксплойт? Этот код нужно выполнить в каком-то окружении, чтобы был эффект, похожий на «я запустил shell code, я кулхацкер»? Или это часть целого проекта с закладками-бэкдорами? В чём, блин, заключался заказ?
В винде есть встроенная история буфера обмена, вполне удобная, нужно только включить в настройках
Значит, испытание здесь в том, чтобы найти способ получить повышение в сложившейся структуре. Вариант «найти новое место работы» тоже является валидным решением.