Я правильно понимаю картину? Сначала ты бьешься с ллм, чтобы она не накосячила с требованиями и реализацией, потом с тестами. После тебе надо всё нагенерированное просмотреть и скорее всего снова переписать. Все это в несколько итераций. Плюс, тебе надо таскать за собой целую вселенную промтов, чтобы ллм-ка тебе дала нужный результат, который все равно не очень надежный. При этом, она успешно работает с маленьким контекстом, там, где и ты вполне себе можешь без проблем справиться. А вот когда контекст становится большим, когда помощь ИИ действительно нужна, она тоже не справляется.
"Нормально делай, нормально будет!" )) Модули же создаются не просто так. Это не просто какое-то там условное деление и раскладывание по папочкам. Если начинается хаос с импортами, это повод задуматься о границах модуля, а не отказываться от модульности или тем более запрещать их импорт.
В описанной архитектуре не хватает очень важной детали -- "признака модуля". Складывать код в shared не является преступлением само по себе. Пока какая-то часть переиспользуемого кода не оформилась по совокупности признаков в модуль ей самое место в общей папке. А вот когда таких кусочков становится много и их все можно отгородить какой-то категорией, это становится модулем. И да, ты можешь его переиспользовать.
Как только начинают проявляться разного рода признаки хаоса, стоит задать себе вопрос, так ли эта граница проведена? И провести ее так, чтобы снова воцарил порядок
Даниил, подскажите. Сталкиваемся с большими проблемами с производительностью при размещении на карте большого количества полигонов в OL. Яндекс.Карты то же количество проглатывают без проблем, тут начинаются тормоза. Какие пути решения этой проблемы можете посоветовать?
Сторы на разных страницах не взаимодействуют. Если есть необходимость подключить вдруг какой-то стор, который используется на другой странице, он подключается в компоненте.
Есть сторы, которые юзают сторы из shared-модуля. Но это чаще всего исключение, чем правило. Главная задача сторов -- обеспечить взаимодействие модулей одного уровня.
Вы не так поняли идею. К бизнес-логике привязаны компоненты, которые "встраиваются" в layout. Пример лэйаута в тесте статьи, как и роут, который его использует. Так вот, сторы юзаются самими компонентами - header, table, footer
Layout -- просто шаблон, который наполняется этими компонентами, как и должно ему быть
На счет api. Да, был такой кейс однажды. Если я не путаю, обратились к другому модулю. Но, эта ситуация возникла скорее из-за попытки связать фронт и бэк в каких-то одних границах. Это было не обязательно, но так решили. Когда дошло дело до такого кейса, в итоге пошли на компромисс
Какие преимущества у данного подхода перед пиньей кроме того, что у нас нет внешней зависимости? Стор пиньи легко просматривать в средствах разработчика, поскольку они регистрируются, сразу видно, какие сторы в данный момент присутствуют на странице. Также стор пиньи легко выгружать из памяти. Как избавиться от этой конструкции? Однажды импортированный модуль такого дизайна остается в памяти на все время работы приложения
Ну конечно, каждая команда в итоге сама и решает, что есть что. Это возможно, когда ваши представления об абстракциях сформированы схожим образом. Но не факт, что с добавлением нового участника команды, эта гармония резко не нарушится. Надеюсь, этого не произойдёт.
Со сторами у нас организована выгрузка. Этим мы решаем проблему по памяти. Ну и чисто организационная составляющая -- в стор выносим только то, что реально нужно шарить. Где-то получается лучше, где-то хуже. Вариантов пока все равно не нашли.
Модуль shared именно отдельный модуль, поскольку его структура практически идентична всем остальным. Это переиспользуемая другими компонентами логика/ui-компоненты. По идее, никаких циклических зависимостей не должно быть, т.к. shared не может использовать никакие другие модули, а они его могут. В целом, предложение понятное. Надо покрутить его в голове.
Что касается границ. В общечеловеческом смысле проведение границ -- это отдельное искусство. Вторая логика, так сказать. Формулирование границ и ее реализация зависит от целей и некой системы ценностей человека. Возвращаясь к коду, мы границы провели так, поскольку нам это показалось удобным и отвечало нашим потребностям, представлениям о том, как было бы удобно работать с кодом. И в итоге мы убедились, что для нас это сработало. Когда модуль стал описывать раздел сайта, папка с роутами стала фактически его интерфейсом, или точкой импорта модуля, который позволял собирать все модули в одном месте -- создание роутера. Роут модуля уже импортирует компоненты-части страницы. Сердце приложения -- main.ts -- собирает модули в роуты и использует при создании vue-приложения. Переназови мы modulues в entrypoints, это, возможно, убрало бы некое противоречие, но сути бы не изменило.
Вынесение роутов из модулей побудило бы нас создать (если я вас правильно понял) какое-то одно место, где бы формировались роуты. Это ничем не отличается от того, что есть сейчас в классической. Это место пришлось бы также отдельно структурировать, чтобы все это не болталось в одном файле, а структура скорее всего повторяла бы структуру entrypoints. Либо я идею не так понял.
Вынести api в shared мы тоже рассматривали. Отказались от этого, увидев еще на старте надвигающийся ком методов, которые снова пришлось бы структурировать. В модулях они уже находятся там, где нужно. Так что, отказались от этой идеи.
Если я правильно понял, модулем вы предлагаете называть только бизнес-логику. Даже если он будет содержать ui-компоненты. Для меня модуль -- это некая максимально самостоятельная архитектурная единица. Грубо говоря, это то, что можно вынести в отдельный репозиторий (кстати тот же shared вполне мог бы стать общей либой для остальных модулей-репозиториев). Слишком намельчить в модуле и проект сразу становится сложно осознаваемым. Модулей станет очень много, а пользоваться ими все равно будут совершенно конкретные страницы.
Тесты. Тесты у нас только unit, лежат, как я показал в папке с компонентами (либо, когда у нас, скажем, папка /helpers, лежат в /helpers/__tetsts__) Моки специфичны для каждого теста. Особо тут нечего рассказать.
Спасибо еще раз за ответ. Подумаем над предложениями!
А можно узнать, что за приложения, которые не выглядели устаревшими и работали под иксами?
Я правильно понимаю картину? Сначала ты бьешься с ллм, чтобы она не накосячила с требованиями и реализацией, потом с тестами. После тебе надо всё нагенерированное просмотреть и скорее всего снова переписать. Все это в несколько итераций. Плюс, тебе надо таскать за собой целую вселенную промтов, чтобы ллм-ка тебе дала нужный результат, который все равно не очень надежный. При этом, она успешно работает с маленьким контекстом, там, где и ты вполне себе можешь без проблем справиться. А вот когда контекст становится большим, когда помощь ИИ действительно нужна, она тоже не справляется.
Nice...
"Нормально делай, нормально будет!" )) Модули же создаются не просто так. Это не просто какое-то там условное деление и раскладывание по папочкам. Если начинается хаос с импортами, это повод задуматься о границах модуля, а не отказываться от модульности или тем более запрещать их импорт.
В описанной архитектуре не хватает очень важной детали -- "признака модуля". Складывать код в shared не является преступлением само по себе. Пока какая-то часть переиспользуемого кода не оформилась по совокупности признаков в модуль ей самое место в общей папке. А вот когда таких кусочков становится много и их все можно отгородить какой-то категорией, это становится модулем. И да, ты можешь его переиспользовать.
Как только начинают проявляться разного рода признаки хаоса, стоит задать себе вопрос, так ли эта граница проведена? И провести ее так, чтобы снова воцарил порядок
Спасибо за ценную инфу!
На сайте https://yandex.ru/maps такая функциональность есть, значит может. Другое дело, это скорее всего платная фича со своим API. Видимо, что-то в этом духе: https://yandex.ru/maps-api/products/geosearch-api
Даниил, подскажите. Сталкиваемся с большими проблемами с производительностью при размещении на карте большого количества полигонов в OL. Яндекс.Карты то же количество проглатывают без проблем, тут начинаются тормоза. Какие пути решения этой проблемы можете посоветовать?
.
Выглядит так, будто вы предлагаете мне использовать ваш фреймворк
Если есть конкретный пример, буду признателен, если вы уточните, о чем речь. Пока не уверен, что правильно понимаю идею.
Сторы на разных страницах не взаимодействуют. Если есть необходимость подключить вдруг какой-то стор, который используется на другой странице, он подключается в компоненте.
Есть сторы, которые юзают сторы из shared-модуля. Но это чаще всего исключение, чем правило. Главная задача сторов -- обеспечить взаимодействие модулей одного уровня.
Вы это серьезно? ))))))) даже на первый взгляд есть пара значимых отличий.
Впрочем, каждому своё. Если вам так удобнее, настаивать не буду
upd: но самое главное "Зачем?" Чем самописный хук будет лучше стора пиньи?
store.$dispose();
Вы не так поняли идею. К бизнес-логике привязаны компоненты, которые "встраиваются" в layout. Пример лэйаута в тесте статьи, как и роут, который его использует. Так вот, сторы юзаются самими компонентами - header, table, footer
Layout -- просто шаблон, который наполняется этими компонентами, как и должно ему быть
Можете привести пример структуры такого модуля?
На счет api. Да, был такой кейс однажды. Если я не путаю, обратились к другому модулю. Но, эта ситуация возникла скорее из-за попытки связать фронт и бэк в каких-то одних границах. Это было не обязательно, но так решили. Когда дошло дело до такого кейса, в итоге пошли на компромисс
Какие преимущества у данного подхода перед пиньей кроме того, что у нас нет внешней зависимости? Стор пиньи легко просматривать в средствах разработчика, поскольку они регистрируются, сразу видно, какие сторы в данный момент присутствуют на странице. Также стор пиньи легко выгружать из памяти. Как избавиться от этой конструкции? Однажды импортированный модуль такого дизайна остается в памяти на все время работы приложения
Ну конечно, каждая команда в итоге сама и решает, что есть что. Это возможно, когда ваши представления об абстракциях сформированы схожим образом. Но не факт, что с добавлением нового участника команды, эта гармония резко не нарушится. Надеюсь, этого не произойдёт.
В больших проектах к этому так или иначе приходишь. 👍
Спасибо за ответ!
Со сторами у нас организована выгрузка. Этим мы решаем проблему по памяти. Ну и чисто организационная составляющая -- в стор выносим только то, что реально нужно шарить. Где-то получается лучше, где-то хуже. Вариантов пока все равно не нашли.
Модуль shared именно отдельный модуль, поскольку его структура практически идентична всем остальным. Это переиспользуемая другими компонентами логика/ui-компоненты. По идее, никаких циклических зависимостей не должно быть, т.к. shared не может использовать никакие другие модули, а они его могут. В целом, предложение понятное. Надо покрутить его в голове.
Что касается границ. В общечеловеческом смысле проведение границ -- это отдельное искусство. Вторая логика, так сказать. Формулирование границ и ее реализация зависит от целей и некой системы ценностей человека. Возвращаясь к коду, мы границы провели так, поскольку нам это показалось удобным и отвечало нашим потребностям, представлениям о том, как было бы удобно работать с кодом. И в итоге мы убедились, что для нас это сработало. Когда модуль стал описывать раздел сайта, папка с роутами стала фактически его интерфейсом, или точкой импорта модуля, который позволял собирать все модули в одном месте -- создание роутера. Роут модуля уже импортирует компоненты-части страницы. Сердце приложения -- main.ts -- собирает модули в роуты и использует при создании vue-приложения. Переназови мы modulues в entrypoints, это, возможно, убрало бы некое противоречие, но сути бы не изменило.
Вынесение роутов из модулей побудило бы нас создать (если я вас правильно понял) какое-то одно место, где бы формировались роуты. Это ничем не отличается от того, что есть сейчас в классической. Это место пришлось бы также отдельно структурировать, чтобы все это не болталось в одном файле, а структура скорее всего повторяла бы структуру entrypoints. Либо я идею не так понял.
Вынести api в shared мы тоже рассматривали. Отказались от этого, увидев еще на старте надвигающийся ком методов, которые снова пришлось бы структурировать. В модулях они уже находятся там, где нужно. Так что, отказались от этой идеи.
Если я правильно понял, модулем вы предлагаете называть только бизнес-логику. Даже если он будет содержать ui-компоненты. Для меня модуль -- это некая максимально самостоятельная архитектурная единица. Грубо говоря, это то, что можно вынести в отдельный репозиторий (кстати тот же shared вполне мог бы стать общей либой для остальных модулей-репозиториев). Слишком намельчить в модуле и проект сразу становится сложно осознаваемым. Модулей станет очень много, а пользоваться ими все равно будут совершенно конкретные страницы.
Тесты. Тесты у нас только unit, лежат, как я показал в папке с компонентами (либо, когда у нас, скажем, папка /helpers, лежат в /helpers/__tetsts__) Моки специфичны для каждого теста. Особо тут нечего рассказать.
Спасибо еще раз за ответ. Подумаем над предложениями!
Задайте конкретный вопрос, я отвечу