Даниил, подскажите. Сталкиваемся с большими проблемами с производительностью при размещении на карте большого количества полигонов в 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__) Моки специфичны для каждого теста. Особо тут нечего рассказать.
Спасибо еще раз за ответ. Подумаем над предложениями!
Бледный, или, к примеру, тонкий или бедный, куда более информативный (прямолинейный) термин, чем анемичный. Все эти аллегории скорее размывают понимание, поскольку требуют сначала глубокого понимания идей, заложенной в них. Так что не соглашусь с комментарием
Скажу прямо, к вопросам доступности я отношусь пока довольно скептически. Складывается впечатление, что это скорее веяние моды, чем реальное понимание необходимости. "Так надо", "Это хорошие практики", "Все так делают". К тому же, часто люди, ратующие за доступность, сами мало чего в ней понимают (камень не в автора статьи). Больше того, не ясно, как без реальных устройств и тестов проверить эту самую доступность. Я много слышу от разработчиков рассуждений о доступности, однако ни бизнес, ни аналитика, ни тестирование никоим образом в этих терминах не рассуждают, ни денег, ни времени на это не выделяется.
И отдельно хочется уточнить статистику. Есть ли данные, сколько из тех 10% населения России являются постоянными пользователями интернета?
На сайте 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__) Моки специфичны для каждого теста. Особо тут нечего рассказать.
Спасибо еще раз за ответ. Подумаем над предложениями!
Задайте конкретный вопрос, я отвечу
Бледный, или, к примеру, тонкий или бедный, куда более информативный (прямолинейный) термин, чем анемичный. Все эти аллегории скорее размывают понимание, поскольку требуют сначала глубокого понимания идей, заложенной в них. Так что не соглашусь с комментарием
А почему это антипаттерн? Можете поделиться какими-то источниками, которые это обосновывают?
Спасибо за статью!
Скажу прямо, к вопросам доступности я отношусь пока довольно скептически. Складывается впечатление, что это скорее веяние моды, чем реальное понимание необходимости. "Так надо", "Это хорошие практики", "Все так делают". К тому же, часто люди, ратующие за доступность, сами мало чего в ней понимают (камень не в автора статьи). Больше того, не ясно, как без реальных устройств и тестов проверить эту самую доступность. Я много слышу от разработчиков рассуждений о доступности, однако ни бизнес, ни аналитика, ни тестирование никоим образом в этих терминах не рассуждают, ни денег, ни времени на это не выделяется.
И отдельно хочется уточнить статистику. Есть ли данные, сколько из тех 10% населения России являются постоянными пользователями интернета?
нет ли на примете полноценного проекта, написанного на rxjs?