Получается если в ProductList добавить Id он станет сущностью, а без I’d он value object) Можно его конечно и добавить, если на проекте понадобиться хранить одновременно несколько ProductList, в данном случае в этом нет нужды.
разве по определению entity должен иметь id? ProductList может иметь собственные методы, гетеры и сеттеры, любые другие поля, помимо массива продуктов.
"Вторичные порты используются ядром приложения для доступа к внешним службам." - тут имеется в виду (внешние службы) тоесть - браузером апи, пользовательские действия (изменение состояния приложения), возможно стоит перефразировать, изменить формулировку для большей понятности?
может так:
Вторичные порты используются ядром приложения для доступа к внешним службам браузера, а также пользовательским действиям взаимодействующим с состоянием приложения.
А как подключение к БД является входящим для приложения?
в данном случае это получение данных из мне, поэтому первичный порт
Получается, что наше приложение стучится в браузер?
Да есть сложности с пониманием, сам долгое время думал что все это избыточно) время разработки увеличивается, разработчики адаптируются 1-2 недели. По итогу мы имеем независимость от бизнес логики или бекенда в нашем случае, тоесть до создания сущиностей на том же бекенде, можно оперировать замотанными данными, так как у нас свои независимые сущьности, подгонять данные из вне под себя через dto в адаптерах. Менять бекенд если захотим. Также приложению не придётся страдать в будущем, от внешних изменений, мы просто переписываем или заменяем первичный адаптер.
для этого есть миксин , если не нужно работать со шрифтом. для шрифтов используется
согласен это решает проблему непонятных размеров, а если например необходимо изменить базовый шрифт страницы пишем в body, думаю стоит дописать это в статье, но что мы получим по факту? ведь по сули используем те же px в миксине, а визуально нечего не меняет. можете дать комментарий?
по поводу rfs тут наверное останусь при своем мнении, так как мы делаем размеры шрифта зависимыми от размера экрана. что может создать проблемы с восприятием чтения читателем ну и дизайну это уже не соответствует, я понимаю что настроить rfs по разному и ограничить размеры, опять же если дизайну это не противоречит и дизайнер это закладывает то welcome.
Еще как стоит. В бытность мою работы на фрилансе и галере веб-студии мне приходили макеты только для десктопа, при необходимости самому допиливать мобилку. Даже если и есть мобильные макеты, вы все-равно предлагаете отказаться от rem/em/%?
em - очень плохо, пришли новые правки, мы например меняем размер шрифта родителя и едут шрифты внутреннего контента. Тут думаю все понятно.
про rem можно если вы сможете дробно подлить все размеры
Единица rem задаёт размер относительно размера шрифта элемента <html>.
например базовый шрифт 16px
h1 - 38px
h2 - 20px
h3 - 18px
16 собственно 1 rem
тогда
h1 - 2.37rem
h2 - 1.25rem
h3 - 1.125rem
если для вас норм писать такие значения и потом в них не путаться, то ок,
или например придется изменить базовый шрифт в<html> для конкретной страницы, то все ваши h1 h2 h3 поедут и не будут соответствовать дизайну.
Почему стоит избегать? Опять же, тот же бутстрап позволяет атомарно пересобрать свою сетку просто импортируя к себе нужные scss файлы и дальше вот те примеры по изобретению велосипеда не нужны от слова совсем.
немного изменил описание для понятности
В прожектах у которых все элементы кастомные с возможностью принимать любую логику и формы, используя bootstrap и прочие ui системы, вы скорее всего будете обвязывать их дополнительными обертками и костылями, при этом неся за собой неиспользуемый функционал в виде js и style кода. Поэтому в проектах с индивидуальным визуалом рекомендую этого избегать и кастомизировать все под свои нужды. Часто в том же bootstrap бывает много того, что нам не нужно использовать и мы часть вырезаем а другую кастомизируем. Еще проблемы могут быть при изменении ui библиотек используемых в фраемворках. Если bootstrap или любые длугие ui системы легко применять под ваши договоренности и не требуется сложная кастомизация, вы можете использовать его без каких либо проблем.
часто приходилось видеть в проектах кастыли над бустрапом, поэтому такое мнение.
Дизайнер как раз должен учитывать ситуацию переполнения контента, и не задавать паддинги не вижу смысла по причине ниже
"ситуацию переполнения контента" - согласен, тут от проекта к проекту все может быть по разному
тогда можно пойти след путем
допустим высота кнопки по дизайну 48px, а шрифт 16px задаем след стили, предполагая что кнопка может быть c переносом шрифта в 2 строки
max-height: 64px; // высота кнопки + высота шрифта
min-height: 48px;
padding: 8px 16px;
font-size: 16px;
обычно это кейс редкий (текст кнопки в 2 строки) , но если и делать такое, то наверное следующим путем. Опять же неправильное вставание иконки или лоадера могут сломать высоту равную 48px. Поэтому я думаю если и использовать это для конкретного места, то писать дополнительный класс. Если по дизайну минимальная высота допустим 48px, а высота может быть любой то max-height вовсе не нужен, но в своей практике такое не встречал.
2 токена мы получаем только при запросе на обновление токенов, например api/refresh
в последующем в запросах на сервер передаем в заголовке только Access .
Также мы должны обезопасить себя от передачи refresh в куках. Потому сморим чтобы pach=api/refresh было у refresh cookie, и на все запросы кроме api/refresh мы ее не отправляли
Если и auth-провайдер, и сервисы - наши (см ветку выше), то нам refresh token
Получается когда токен будет скомпрометирован, мы сможем бесконечно им пользоваться?
запрашиваем у него access token и используем в заголовке запросов к сервисам. Этот access token просто держим в памяти,
"просто держим в памяти" - Тоесть при каждой перезагрузке станицы мы делаем refresh?
Refresh-токен держим в памяти, никуда не записываем для безопасности.
вы наверное имели в виду Access - токен ?
Вообще идея с тем чтобы хранить Access в памяти мне искажаться вполне приемлемой, Спасибо) но это тоже уязвимость, так как данные можно получить. Использовали уже данный подход? на каких проектах?
Если дизайнеры и верстальшики не будут придерживаться определенных "рамок" как вы говорите, а точнее сказать договоренностей, будет вакханалия и рост сложности поддержки в верстке, что и приведет к возможному переписыванию сайта. "это так не работает." - обычно в крупных компаниях это так и работает.
за бездумное использование !important я бы вводил смертную казнь или принудительное кастрирование
где вы увидели бездумное использование important в моих примерах?
использование important для атомарных классов - это адекватное ращение, так как из за специфичности селекторов без important будет проблемы
даже сам bootstrap 5 и многие другие фреймворки используют important
Ваша идея реализуема только в приделах какой-то конторки которая клепает сайт (возможно дорвеи) пачками
Приведенные мной наработки зарекомендовали себя на достаточно крупном проекте. Если договоренностей не будет, это скорее и будет не поддерживаемый код в "приделах какой-то конторки которая клепает сайт "
Получается если в ProductList добавить Id он станет сущностью, а без I’d он value object) Можно его конечно и добавить, если на проекте понадобиться хранить одновременно несколько ProductList, в данном случае в этом нет нужды.
По 2 варианту: когда А получит дубликат ключа в сундуке, он увидит что замок чужой или его нет.
В вашем примере между 1 и 2 пунктом, вы упускаете что Б вешает свой замок. Следовательно в 4 пункте у вас будет замок от Б и вы нечего не откроете
разве по определению entity должен иметь id? ProductList может иметь собственные методы, гетеры и сеттеры, любые другие поля, помимо массива продуктов.
Большое спасибо) исправил свои недочеты в статье про использование px и высоту элементов, дополнил и дописал уточнения.
Действительно, для шрифтов лучше rem или rfs по необходимости.
Наверное стоит исправить, согласен думаю - "Внешние системы"
"Вторичные порты используются ядром приложения для доступа к внешним службам." - тут имеется в виду (внешние службы) тоесть - браузером апи, пользовательские действия (изменение состояния приложения), возможно стоит перефразировать, изменить формулировку для большей понятности?
может так:
Вторичные порты используются ядром приложения для доступа к внешним службам браузера, а также пользовательским действиям взаимодействующим с состоянием приложения.
в данном случае это получение данных из мне, поэтому первичный порт
вызывает внешние службы, браузерное апи
Да есть сложности с пониманием, сам долгое время думал что все это избыточно) время разработки увеличивается, разработчики адаптируются 1-2 недели. По итогу мы имеем независимость от бизнес логики или бекенда в нашем случае, тоесть до создания сущиностей на том же бекенде, можно оперировать замотанными данными, так как у нас свои независимые сущьности, подгонять данные из вне под себя через dto в адаптерах. Менять бекенд если захотим. Также приложению не придётся страдать в будущем, от внешних изменений, мы просто переписываем или заменяем первичный адаптер.
согласен это решает проблему непонятных размеров, а если например необходимо изменить базовый шрифт страницы пишем в body, думаю стоит дописать это в статье, но что мы получим по факту? ведь по сули используем те же px в миксине, а визуально нечего не меняет. можете дать комментарий?
по поводу rfs тут наверное останусь при своем мнении, так как мы делаем размеры шрифта зависимыми от размера экрана. что может создать проблемы с восприятием чтения читателем ну и дизайну это уже не соответствует, я понимаю что настроить rfs по разному и ограничить размеры, опять же если дизайну это не противоречит и дизайнер это закладывает то welcome.
Понял, спасибо)
Большое спасибо за комментарий)
em - очень плохо, пришли новые правки, мы например меняем размер шрифта родителя и едут шрифты внутреннего контента. Тут думаю все понятно.
про rem можно если вы сможете дробно подлить все размеры
Единица
remзадаёт размер относительно размера шрифта элемента<html>.например базовый шрифт 16px
h1 - 38px
h2 - 20px
h3 - 18px
16 собственно 1 rem
тогда
h1 - 2.37rem
h2 - 1.25rem
h3 - 1.125rem
если для вас норм писать такие значения и потом в них не путаться, то ок,
или например придется изменить базовый шрифт в
<html> для конкретной страницы, то все ваши h1 h2 h3 поедут и не будут соответствовать дизайну.немного изменил описание для понятности
В прожектах у которых все элементы кастомные с возможностью принимать любую логику и формы, используя bootstrap и прочие ui системы, вы скорее всего будете обвязывать их дополнительными обертками и костылями, при этом неся за собой неиспользуемый функционал в виде js и style кода. Поэтому в проектах с индивидуальным визуалом рекомендую этого избегать и кастомизировать все под свои нужды. Часто в том же bootstrap бывает много того, что нам не нужно использовать и мы часть вырезаем а другую кастомизируем. Еще проблемы могут быть при изменении ui библиотек используемых в фраемворках. Если bootstrap или любые длугие ui системы легко применять под ваши договоренности и не требуется сложная кастомизация, вы можете использовать его без каких либо проблем.
часто приходилось видеть в проектах кастыли над бустрапом, поэтому такое мнение.
"ситуацию переполнения контента" - согласен, тут от проекта к проекту все может быть по разному
тогда можно пойти след путем
допустим высота кнопки по дизайну 48px, а шрифт 16px задаем след стили, предполагая что кнопка может быть c переносом шрифта в 2 строки
обычно это кейс редкий (текст кнопки в 2 строки) , но если и делать такое, то наверное следующим путем. Опять же неправильное вставание иконки или лоадера могут сломать высоту равную 48px. Поэтому я думаю если и использовать это для конкретного места, то писать дополнительный класс. Если по дизайну минимальная высота допустим 48px, а высота может быть любой то max-height вовсе не нужен, но в своей практике такое не встречал.
исправил недоработку в статье, спасибо)
тоесть нам придется заново авторизоваться каждый раз? ведь после обновления страницы он будет утерян, не совсем понятен этот момент
любой сторонний js код на сайте сможет это прочесть
2 токена мы получаем только при запросе на обновление токенов, например api/refresh
в последующем в запросах на сервер передаем в заголовке только Access .
Также мы должны обезопасить себя от передачи refresh в куках. Потому сморим чтобы pach=api/refresh было у refresh cookie, и на все запросы кроме api/refresh мы ее не отправляли
Получается когда токен будет скомпрометирован, мы сможем бесконечно им пользоваться?
"просто держим в памяти" - Тоесть при каждой перезагрузке станицы мы делаем refresh?
вы наверное имели в виду Access - токен ?
Вообще идея с тем чтобы хранить Access в памяти мне искажаться вполне приемлемой, Спасибо) но это тоже уязвимость, так как данные можно получить. Использовали уже данный подход? на каких проектах?
Если дизайнеры и верстальшики не будут придерживаться определенных "рамок" как вы говорите, а точнее сказать договоренностей, будет вакханалия и рост сложности поддержки в верстке, что и приведет к возможному переписыванию сайта. "это так не работает." - обычно в крупных компаниях это так и работает.
где вы увидели бездумное использование important в моих примерах?
использование important для атомарных классов - это адекватное ращение, так как из за специфичности селекторов без important будет проблемы
даже сам bootstrap 5 и многие другие фреймворки используют important
посмотрите исходный код
https://github.com/twbs/bootstrap/blob/main/dist/css/bootstrap-utilities.css
Приведенные мной наработки зарекомендовали себя на достаточно крупном проекте. Если договоренностей не будет, это скорее и будет не поддерживаемый код в "приделах какой-то конторки которая клепает сайт "
Большое спасибо за комментарий, все по делу. Моя первая статья)
"Не расшифровать, а декодировать" - исправил
"Как же так? Чуть выше было сказано, что токен храним в http-only cookie" - тут действительно недоработка с моей стороны,
вижу следующие варианты:
1) access-token храним без http-only, и для записи в header запроса используем js, но тогда создаем уязвимость, что не очень.
2) вовсе не использовать заголовок для передачи access-token, оставляем его cookie
что скажете по поводу 2 варианта?