Смотрите. В 1-м своём комментарии я не навязывал обязательное использование стора. Я лишь перечислил плюсы такого подхода. Если есть пагинация, и нужно фильтровать данные в разных местах - стор, скорее всего, не стоит использовать вовсе. Всё зависит от потребностей)
Когда я писал второй комментарий, я неверно вас понял, за что извиняюсь. Решил, что вы собрались писать логику обработки данных прямо в компоненте))
Но тем не менее. Допустим, у вас есть множество сервисов, занимающихся обработкой и получением данных. Стора в проекте пока нет. Вы в компонентах получаете / отправляете данные только через сервисы. Но вдруг появляется первый ваш стор. И прямо в этом сторе прописано:data.value = await (await fetch(...)).json();проходит какое-то время, и в команду приходит новенький. Ему дают задачу: дописать логику получения данных с бэка. Например, поменять формат данных, возвращаемых API. Где он будет искать логику получения данных? Конечно, в сервисах. А найдёт в сторе. И где ему дописывать новую логику?
Ну так в вашей схеме получается, что кто угодно может изменить стор. Я вообще не представляю, как КОМПОНЕНТ может менять стор? Я всегда все операции с данными делаю через сервисы. Если есть сотня компонентов и сервисов, и при этом часть компонентов меняет данные самостоятельно - это жесть. Я через это проходил на своих проектах))
Получается, что данные запрашиваются через сервисы и записываются в стор, а компоненты только читают данные из стора. Как вы и написали. Данные записываются в хранилище, и через реактивность подтягиваются там, где нужно. Это очень удобно
Не всем компонентам нужна консистентность
Вы неправильно понимаете принцип, который я описал. Вот у вас есть исходные данные в сторе. Одному компоненту требуется сортировка по цене, другому - по цвету и с фильтром по категориям. Вместо того, чтобы хранить копии данных в сторе для каждого компонента - берёте и реактивно сортируете/фильтруете данные из стора через computed. У вас будет 1 источник истины и никаких лишних копий данных
Так тестируйте сервис
Вот исходя из моих доводов выше, представьте, как будет удобно тестировать такую систему. Вы один раз для всех зависимых компонентов задаёте данные в сторе, а потом через computed делаете с ними, что хотите, и проверяете
На мой взгляд, тут чистейшей воды side effect. Если это стор - ожидаемо, что ты получаешь уже сохраненные данные. Тогда можно тупо в сервис это запихнуть. Или тут подразумевается некий кэш?
На самом деле, я осознал, что немного соврал. Примерно в 50% случаев при поиске вылезает ИИ от Гугла/Яндекса. Большой плюс здесь в том, что эти ИИ довольно глупые, чтобы "качественно галлюцинировать" - все их выдумки видны сразу, с первого взгляда понятно, когда нужно искать самому
Это очень хороший компромисс, это действительно помогает в простых запросах. И это намного эффективнее, чем вбивать запрос в "тяжёлую" нейросеть. Я бы сказал, это как из пушки по воробьям) а вот лайтовые поисковые ИИ типа "поиск с Я.Алисой" - идеально
На форумах люди проверяли и тестировали решение. Причем с обеих сторон - и автор вопроса, и автор ответа. Плюс люди в комментариях ругаются, если ответ плохой. Качество контента на форумах и на ИИ даже сравнивать страшно
Часто люди спрашивают, зачем понимать, осознавать, что ты делаешь через нейросеть. И в чём вообще проблема нейросетей. Отличный пример: автор статьи в начале пишет, что он очень переживает по поводу безопасности. Он же в конце: отключает на macOS проверку сертификатов из-за какой-то ошибки
P.S. а ведь раньше форумы ругали за качество... Видно, что сейчас приоритетнее количество
Вот и у меня то же самое. В существующем проекте вообще невозможно пользоваться нейронками. Если вдруг кто-то смог, поделитесь рецептом, пожалуйста... У меня халтура - логистический проект на 4 сервиса в монорепе. Очень не хочется писать самому, но LLM выдаёт такой ужас, что приходится
Честно, для меня гуглить в ряде случаев намного продуктивнее того же ЛЛМ поиска. Пока он подумает, погенерирует, ошибётся и поправит сам себя, я уже давно вобью в поиск ключевые слова (которые в разы короче промпта, кстати) и получу ответ, даже не открывая ссылку, из описания статьи
Конечно, всё зависит от цели. И, наверное, от стоимости подписки на LLM)) но я перепробовал очень много бесплатных моделей, и понял, что во многих случаях, например, проще почитать оригинальное объяснение на старом добром stackoverflow, чем глючную выдачу LLM. Просто потому, что на stackoverflow это уже кто-то проверил, и это реально работает
Это же касается и гугления ответов на экзаменах, кстати. Если мне задают вопрос, на который я плохо знаю ответ, я иду гуглить его, и разбираюсь в теме за несколько запросов. Тем, кто пользовался LLM, почти никогда не засчитывают ответ, потому что LLM режет детали или выдумывает их
Внутри стора нельзя писать логику получения запросов. Для этого есть сервисы. Сервис должен получать данные с АПИ, обрабатывать и отправлять в стор
Зачем хранить данные в сторе, если они используются в 1 компоненте? 1) консистентность - данные с Бека хранятся в одном месте; 2) удобство тестов - можно легко мокать стор (попробуйте замокать локальную переменную где-то в сервисе); 3) удобная отладка - просмотр содержимого стора; ...и т.д.
Давайте так. Что проще: написать сервер на Python, сразу генерирующий HTML, или написать API на Python и клиент на JS? Пишите хоть на ванильном JS, это всё равно будет сложнее первого варианта. И я даже не упомянул настройку CI/CD пайплайнов...
Смотрите. В 1-м своём комментарии я не навязывал обязательное использование стора. Я лишь перечислил плюсы такого подхода. Если есть пагинация, и нужно фильтровать данные в разных местах - стор, скорее всего, не стоит использовать вовсе. Всё зависит от потребностей)
Когда я писал второй комментарий, я неверно вас понял, за что извиняюсь. Решил, что вы собрались писать логику обработки данных прямо в компоненте))
Но тем не менее. Допустим, у вас есть множество сервисов, занимающихся обработкой и получением данных. Стора в проекте пока нет. Вы в компонентах получаете / отправляете данные только через сервисы. Но вдруг появляется первый ваш стор. И прямо в этом сторе прописано:
data.value = await (await fetch(...)).json();проходит какое-то время, и в команду приходит новенький. Ему дают задачу: дописать логику получения данных с бэка. Например, поменять формат данных, возвращаемых API. Где он будет искать логику получения данных? Конечно, в сервисах. А найдёт в сторе. И где ему дописывать новую логику?Нужны 4 человека-добровольца. Задача: сменить имена на root, nobody, Admin и Guest
Тут принцип другой. VLESS использует маскировку, а в Naive буквально скопировали реализацию из хрома, как я понял
Ну и VLESS довольно успешно блокируется. Очевидно, что, если бы он не был на волне хайпа, внимания бы к себе не привлек, о чём автор и сказал
Ну так в вашей схеме получается, что кто угодно может изменить стор. Я вообще не представляю, как КОМПОНЕНТ может менять стор? Я всегда все операции с данными делаю через сервисы. Если есть сотня компонентов и сервисов, и при этом часть компонентов меняет данные самостоятельно - это жесть. Я через это проходил на своих проектах))
Получается, что данные запрашиваются через сервисы и записываются в стор, а компоненты только читают данные из стора. Как вы и написали. Данные записываются в хранилище, и через реактивность подтягиваются там, где нужно. Это очень удобно
Вы неправильно понимаете принцип, который я описал. Вот у вас есть исходные данные в сторе. Одному компоненту требуется сортировка по цене, другому - по цвету и с фильтром по категориям. Вместо того, чтобы хранить копии данных в сторе для каждого компонента - берёте и реактивно сортируете/фильтруете данные из стора через computed. У вас будет 1 источник истины и никаких лишних копий данных
Вот исходя из моих доводов выше, представьте, как будет удобно тестировать такую систему. Вы один раз для всех зависимых компонентов задаёте данные в сторе, а потом через computed делаете с ними, что хотите, и проверяете
Довольно странное решение... Зачем тогда сервисы?
На мой взгляд, тут чистейшей воды side effect. Если это стор - ожидаемо, что ты получаешь уже сохраненные данные. Тогда можно тупо в сервис это запихнуть. Или тут подразумевается некий кэш?
На самом деле, я осознал, что немного соврал. Примерно в 50% случаев при поиске вылезает ИИ от Гугла/Яндекса. Большой плюс здесь в том, что эти ИИ довольно глупые, чтобы "качественно галлюцинировать" - все их выдумки видны сразу, с первого взгляда понятно, когда нужно искать самому
Это очень хороший компромисс, это действительно помогает в простых запросах. И это намного эффективнее, чем вбивать запрос в "тяжёлую" нейросеть. Я бы сказал, это как из пушки по воробьям) а вот лайтовые поисковые ИИ типа "поиск с Я.Алисой" - идеально
На форумах люди проверяли и тестировали решение. Причем с обеих сторон - и автор вопроса, и автор ответа. Плюс люди в комментариях ругаются, если ответ плохой. Качество контента на форумах и на ИИ даже сравнивать страшно
Часто люди спрашивают, зачем понимать, осознавать, что ты делаешь через нейросеть. И в чём вообще проблема нейросетей. Отличный пример: автор статьи в начале пишет, что он очень переживает по поводу безопасности. Он же в конце: отключает на macOS проверку сертификатов из-за какой-то ошибки
P.S. а ведь раньше форумы ругали за качество... Видно, что сейчас приоритетнее количество
Вот и у меня то же самое. В существующем проекте вообще невозможно пользоваться нейронками. Если вдруг кто-то смог, поделитесь рецептом, пожалуйста... У меня халтура - логистический проект на 4 сервиса в монорепе. Очень не хочется писать самому, но LLM выдаёт такой ужас, что приходится
Честно, для меня гуглить в ряде случаев намного продуктивнее того же ЛЛМ поиска. Пока он подумает, погенерирует, ошибётся и поправит сам себя, я уже давно вобью в поиск ключевые слова (которые в разы короче промпта, кстати) и получу ответ, даже не открывая ссылку, из описания статьи
Конечно, всё зависит от цели. И, наверное, от стоимости подписки на LLM)) но я перепробовал очень много бесплатных моделей, и понял, что во многих случаях, например, проще почитать оригинальное объяснение на старом добром stackoverflow, чем глючную выдачу LLM. Просто потому, что на stackoverflow это уже кто-то проверил, и это реально работает
Это же касается и гугления ответов на экзаменах, кстати. Если мне задают вопрос, на который я плохо знаю ответ, я иду гуглить его, и разбираюсь в теме за несколько запросов. Тем, кто пользовался LLM, почти никогда не засчитывают ответ, потому что LLM режет детали или выдумывает их
Внутри стора нельзя писать логику получения запросов. Для этого есть сервисы. Сервис должен получать данные с АПИ, обрабатывать и отправлять в стор
Зачем хранить данные в сторе, если они используются в 1 компоненте? 1) консистентность - данные с Бека хранятся в одном месте; 2) удобство тестов - можно легко мокать стор (попробуйте замокать локальную переменную где-то в сервисе); 3) удобная отладка - просмотр содержимого стора; ...и т.д.
В современных реалиях фраза "7068 строк кода, 15 модулей и ни одного фреймворка" звучит страшно XD
Но это шутка, конечно) решение супер, я сам хотел для себя написать что-то подобное. Точ что описано в статье - прям то, что нужно!
Хах, понятное дело. Поэтому призываю и тебя не писать "на шару" :)
В любом случае, тут решение далеко от идеала
Тогда согласен на все сто. Очень не нравится, когда люди следуют паттернам по принципу "потому что так надо"
Хах, такими темпами новый TCP протокол получится))
Понимаю, что этот пример написан "для демонстрации простоты", но почему не написать вот так ради соответствия стандартам?
Давайте так. Что проще: написать сервер на Python, сразу генерирующий HTML, или написать API на Python и клиент на JS? Пишите хоть на ванильном JS, это всё равно будет сложнее первого варианта. И я даже не упомянул настройку CI/CD пайплайнов...
Скажем так, в СССР с "пятилеткой за 1 год" это было выражено наиболее ярко
Это очень радует)
Было бы интересно увидеть комментарии людей из стартапов типа OpenAI)) после речей Альтмана складывается ощущение, что там люди 24/7 работают
Искал этот коммент :)
Хочу дополнить, что FastAPI вполне неплохо работает с синхронным кодом, запуская обработчики в отдельных потоках
А почему RESTful - плохо? Да, всё, что Вы перечислили до этого, имеет место быть. Но это не мешает существовать корректному RESTful)
P.S. у GET методов нет body (или тут имеется ввиду не метод, а "суть" - получение данных?)