Давайте не будем обманывать себя и других - вы тут стыдливо умолчали и о Сбере и о Тинькове и о ВК и многие многие другие - все они используют Redux
По поводу Zustand - все его внутреннее устройство состоит из pub/sub объекта (для работы с не React) и единственный хук для React (все вместе около 2кб чистого кода!!!!) - чего еще проще может быть?????
ЗЫ: и давайте без эмоциональных высказываний и оценок - мы все же в публичном пространстве
Вы говорите как вы героически сражались с тем что сотворили не используя знания и системный подход к проектированию UI - да вы молодцы поборолись со своими же проблемами и смогли таки создать тему
А я , пройдя такие же этапы разработки и лишь затем обнаруживший Material Design, рекомендую вам после всего этого процесса который вы прошли и которым идет большинство (не изучая теорию и лучшие практики бросаются что-то строить) изучить его - я думаю вы на многое взглянете другими глазами и узнаете что любую новую тему при системном подходе к проектированию UI не нужно героически создавать - она автоматически получается за пару секунд :) Думаю что после изучения Material Design у вас возникнет сильное желание переписать все сделанное ранее )
Вопрос не в конкретном инструменте, а в основных принципах дизайна ну отсюда вытекает естественный процесс генерации цветов.
Material Design - это не про конкретную библиотеку компонентов - это про дизайн и проектирование на его основе любых дизайн-систем и библиотек компонентов (там собраны лучшие идеи и практики дизайна интерфейсов)
Благодаря системному подходу в дизайне можно генерировать тысячи цветовых схем , которые будут консистентны и будут содержать контрастные цвета
Посмотрите на Хром - там есть галочка динамически менять цветовые темы - он по несколько раз за день меняет цветовые схемы - они генерируются динамически!
А так можно героически напрягаться и в конце месяца сгенерировать таки одну тему для продукта, руками подбирая цвета и даже потом какой-то инструмент изобрести, но это процесс от обратного
После такой работы если вы прочтете Material Desing вы будете удивлены : блин а почему мы раньше это не прочли? мы бы не мучались и сделали все гораздо проще!
отнесем излишнюю эмоциональность комментатора на весенние деньки :), а по сути и без эмоций могу сказать, что то что любят начинающие и те кто пишет сам (всякую магию которая делается одной буквой и тому подобное) в промышленной разработке в больших командах не применимо - там эта "магия" вылазит боком! Поэтому все лидеры рынка и пишут до сих пор на Redux и на MobX не перейдут никогда. Сейчас все из них присматриваются и переходят на Zustand.
По поводу всякой "магии" и черных волшебных ящиков у разработчиков выработалось защитное правило: все явное лучше не явного так проще найти и понять что и почему - в "магии" замучаешься искать
Сегодня ни то ни другое не нужно ибо оба бойлерплейт - самое минималистичное по размеру и самое оптимальное и богатое по функционалу решение - Zustand ( я описывал его реализацию в статье)
ИИ - это и есть универсальный язык выполнения ваших программ при помощи передачи ему инструкций на человеческом языке. ИИ и есть квинтэссенция развития языков программирования (понятно что это не прям сейчас, но уже в ближайшем будущем)
Мы у себя используем JsonRpc и не имеем проблем со смешиванием кодов состояния сети с кодами состояний данных из АПИ: - ошибки транспортного уровня обрабатываем и отдаем как ошибки транспортного уровня - ошибки АПИ напрямую проходят к потребителю ровно так же как и успешные запросы
Ну а в общем - данный слой должен любую ошибку прямо передать потребителю - в нём не должно быть никакой логики. Ставите try/catch на fetch() и json() и в случае возникновения ошибки просто возвращаете объект с ошибкой
скажу даже больше - у нас микросервис АПИ (тот который не имеет своей логики и является передастом между клиентом и БД) не изменяется вообще никогда - меняются/генерируются лишь JSON схемы и сервису лишь подсовывается новая схема при его рестарте Мы вообще прагматичные лентяи )))
Некоторые из них прибегают к автогенерации кода на основе схем Swagger, другие переписывают код вручную.
Изменить = сгенерировать новую версию при помощи инструментов (их есть для генерации интерфейсов на typescript) или для тек кто пишет руками - изменить руками.
Разработчик АПИ будет делать все то же что и раньше только инструменты его не будут генерировать код а будут генерировать только описание интерфейсов
в начале всегда возникает не приятие - новое не понятное, но если понять - то потом не оторвешь за уши :) старый подход предлагает генерировать тонны однотипного кода - мой метод предлагает его вообще не генерировать и облегчить жизнь фронтендерам и юзерам, но все в начале протестуют - не хотят ни добра фронтэндерам ни радости юзерам ну потому что привыкли уже по-старинке)) а зачем что-то менять? ))
нет не предлагаю - я предлагаю вам как и раньше при помощи инструментов того же swagger генерировать только описание интерфейса на typescript! Для бэкэндеров ничего в процессе не меняется, а вот во фронтенде - приложение получает большой плюс в виде отсутствия пустого кода
встроенные методы не приветствую и не использую (см п.3 рекомендации) но в коде за api скрывается интерфейс pub/sub объекта (реального хранилища данных)
эти методы пробрасываются для прямых подписок и прямых манипуляций с данными в хранилище (когда внутри метода хранилища какие-то объекты могут подписываться на обновление данных и реагировать) - думаю что это для крайне экзотических ситуаций и в 99 .9% случаев он не используется - достаточно предоставляемых методов get и set
методы get и set - просто синонимы методов getState и setState
пример с set есть либо в readme либо в доке - точно помню
в статью, я думаю не нужно включать, статья получится копией документации - смысл статьи показать основные возможности и заинтересовать, а детали уже всегда можно в доке найти
Давайте не будем обманывать себя и других - вы тут стыдливо умолчали и о Сбере и о Тинькове и о ВК и многие многие другие - все они используют Redux
По поводу Zustand - все его внутреннее устройство состоит из pub/sub объекта (для работы с не React) и единственный хук для React (все вместе около 2кб чистого кода!!!!) - чего еще проще может быть?????
ЗЫ: и давайте без эмоциональных высказываний и оценок - мы все же в публичном пространстве
Вы говорите как вы героически сражались с тем что сотворили не используя знания и системный подход к проектированию UI - да вы молодцы поборолись со своими же проблемами и смогли таки создать тему
А я , пройдя такие же этапы разработки и лишь затем обнаруживший Material Design, рекомендую вам после всего этого процесса который вы прошли и которым идет большинство (не изучая теорию и лучшие практики бросаются что-то строить) изучить его - я думаю вы на многое взглянете другими глазами и узнаете что любую новую тему при системном подходе к проектированию UI не нужно героически создавать - она автоматически получается за пару секунд :) Думаю что после изучения Material Design у вас возникнет сильное желание переписать все сделанное ранее )
Вопрос не в конкретном инструменте, а в основных принципах дизайна ну отсюда вытекает естественный процесс генерации цветов.
Material Design - это не про конкретную библиотеку компонентов - это про дизайн и проектирование на его основе любых дизайн-систем и библиотек компонентов (там собраны лучшие идеи и практики дизайна интерфейсов)
Благодаря системному подходу в дизайне можно генерировать тысячи цветовых схем , которые будут консистентны и будут содержать контрастные цвета
Посмотрите на Хром - там есть галочка динамически менять цветовые темы - он по несколько раз за день меняет цветовые схемы - они генерируются динамически!
А так можно героически напрягаться и в конце месяца сгенерировать таки одну тему для продукта, руками подбирая цвета и даже потом какой-то инструмент изобрести, но это процесс от обратного
После такой работы если вы прочтете Material Desing вы будете удивлены : блин а почему мы раньше это не прочли? мы бы не мучались и сделали все гораздо проще!
Браво! Мои восхищения и поздравления!
Люди сами спроектировали и довели до ума хорошее устройство а не просто купили абы что на рынке!!!! Браво!
А если бы перед началом разработки изучили бы опыт Material Design - не пришлось бы сейчас мучаться подбирать и изобретать! :)
MD3 - просто песня с его инструментом по генерации и подбору цветов для светлой и темной теме по картинке, по брендовым и кастомным цветам
отнесем излишнюю эмоциональность комментатора на весенние деньки :), а по сути и без эмоций могу сказать, что то что любят начинающие и те кто пишет сам (всякую магию которая делается одной буквой и тому подобное) в промышленной разработке в больших командах не применимо - там эта "магия" вылазит боком!
Поэтому все лидеры рынка и пишут до сих пор на Redux и на MobX не перейдут никогда. Сейчас все из них присматриваются и переходят на Zustand.
По поводу всякой "магии" и черных волшебных ящиков у разработчиков выработалось защитное правило: все явное лучше не явного так проще найти и понять что и почему - в "магии" замучаешься искать
Сегодня ни то ни другое не нужно ибо оба бойлерплейт - самое минималистичное по размеру и самое оптимальное и богатое по функционалу решение - Zustand ( я описывал его реализацию в статье)
Наши чаты гораздо лучше понимают русский язык и соответственно работа с текстом у них получается лучше: GigaChat от Сбера, YandexGPT
ИИ - это и есть универсальный язык выполнения ваших программ при помощи передачи ему инструкций на человеческом языке.
ИИ и есть квинтэссенция развития языков программирования (понятно что это не прям сейчас, но уже в ближайшем будущем)
Мы у себя используем JsonRpc и не имеем проблем со смешиванием кодов состояния сети с кодами состояний данных из АПИ:
- ошибки транспортного уровня обрабатываем и отдаем как ошибки транспортного уровня
- ошибки АПИ напрямую проходят к потребителю ровно так же как и успешные запросы
Ну а в общем - данный слой должен любую ошибку прямо передать потребителю - в нём не должно быть никакой логики. Ставите try/catch на fetch() и json() и в случае возникновения ошибки просто возвращаете объект с ошибкой
Вы всё верно поняли из статьи!
скажу даже больше - у нас микросервис АПИ (тот который не имеет своей логики и является передастом между клиентом и БД) не изменяется вообще никогда - меняются/генерируются лишь JSON схемы и сервису лишь подсовывается новая схема при его рестарте
Мы вообще прагматичные лентяи )))
Изменить = сгенерировать новую версию при помощи инструментов (их есть для генерации интерфейсов на typescript) или для тек кто пишет руками - изменить руками.
Разработчик АПИ будет делать все то же что и раньше только инструменты его не будут генерировать код а будут генерировать только описание интерфейсов
Понятно! Вы как и все остальные минусующие бэкэндеры прочитали заголовок и максимум 1й абзац и статью не прочли и кинулись писать гневный коммент ))
Вся статья и все комменты о том что не нужно будет при моем подходе НИКОГДА БОЛЬШЕ В ЖИЗНИ писать/генерировать код для клиента!!! )
в начале всегда возникает не приятие - новое не понятное, но если понять - то потом не оторвешь за уши :)
старый подход предлагает генерировать тонны однотипного кода - мой метод предлагает его вообще не генерировать и облегчить жизнь фронтендерам и юзерам, но все в начале протестуют - не хотят ни добра фронтэндерам ни радости юзерам ну потому что привыкли уже по-старинке)) а зачем что-то менять? ))
нет не предлагаю - я предлагаю вам как и раньше при помощи инструментов того же swagger генерировать только описание интерфейса на typescript!
Для бэкэндеров ничего в процессе не меняется, а вот во фронтенде - приложение получает большой плюс в виде отсутствия пустого кода
писать на сервере заголовки CSP для страницы
привет!
встроенные методы не приветствую и не использую (см п.3 рекомендации) но в коде за api скрывается интерфейс pub/sub объекта (реального хранилища данных)
interface StoreApi<T> {setState: SetStateInternal<T>;getState: () => T;getInitialState: () => T;subscribe: (listener: (state: T, prevState: T) => void) => () => void;}
эти методы пробрасываются для прямых подписок и прямых манипуляций с данными в хранилище (когда внутри метода хранилища какие-то объекты могут подписываться на обновление данных и реагировать) - думаю что это для крайне экзотических ситуаций и в 99 .9% случаев он не используется - достаточно предоставляемых методов get и set
методы get и set - просто синонимы методов
getStateиsetStateпример с set есть либо в readme либо в доке - точно помню
в статью, я думаю не нужно включать, статья получится копией документации - смысл статьи показать основные возможности и заинтересовать, а детали уже всегда можно в доке найти
Вот это жесткие реалии жизни :)
Молодцы!
отличная статья! спасибо!
очень нравится стиль - это куда интереснее и познавательнее чем сухие доки