я не знаю как экономия, а вот это это дело будет работать при минификации js это большой вопрос.
Без точки запятой возможны не очевидные поведения перед какими-то операторами.
Спасибо за ответ. Да я примерно так и понял и в некоторых случаях действительно у меня есть свои интерфейсы в каждом слое.
Ещё есть один момент , у меня на у очень большое приложение , в котором около 10 модулей , каждый из которых расписан (а точнее рефакторится) по ддд. Это для того , чтобы в дальнейшем было все просто выделить на микросервисы.
Я заметил , что если делать интерфейс в каждом слое , то выходит очень много дублирования. Тоесть не сколько дублирование , а однообразный код и усложнение системы.
Я понимаю , что это более правильно , но в некоторых случаях приходится идти на компромиссы, ради скорости , ради команды.
Поэтому в некоторых случаях я все-же дёргаю инфраструктуру на прямую в других слоях (через интерфейс, которой находится в инфраструктуре).
Что касается гидратора, он улетел в отдельный пакет и стал как зависимость от проекта без адаптеров. Так-как все-же является собственной разработкой.
Илья Ростопка, этого можно добиться с помощью библиотек на js, которые будут его подгружать в самом низу страницы.
Но тут есть большое но, у пользователя будут блики дизайна сайта, что мне лично не нравится.
И снова тут вопрос идет об оптимизации уже оптимизированного. Там где-то я описывал вариант с http2 и мелкими файлами + CDN с друго-го сервака, чтобы еще в несколько потоков вписаться.
Но обычно такое вытворяют в редких случаях, когда реально есть существенная разница в том, что вы сэкономите байт.
DoubleWish, мы всеравно говорим о 220кБ в конце 2017 года, где скорость мобильного интерната вполне способна проглотить пару мб.
Но опять таки, если хочется заморочиться, тогда дробить на много мелких файлов и http2.
И если вообще овер хед, то вынести на отдельный сервак под CDN.
Учитывая если все кеши и сжатия включены, то это уже наверно будет максимум оптимизации. А еще возможно есть таски под тот-же GULP, через которые можно прогнать код и он его оптимизирует. Удалит лишние классы, что-то скомбинирует, что-то сократит.
Что касается инлайн подключения, это скорее всего влияет больше на юзабилити, чем на оптимизацию.
DoubleWish, если интересуют именно очки гугла, вам нужно пересмотреть архитектуру вашего css, сбилдить какой-то файл, типа хидер + то, что нужно, чтобы его корректно отобразить и отредерить его инлайново. КПД будет идти куда-то в 0, но очки получите.
В моем понятии инфраструктура это просто реализация репозиториев , сервисов м хелперов , она не вызывает другие слои кроме домена , так как зависит и оперирует сущностями.
yurygolikov, как инфраструктура не может вызывать домен , если она как минимум реализует интерфейсы , которые могут возвращать сущности. Для этого нужен тайпхинт.
"... домен знает об интерфейсе к инфраструктуре, который лежит на доменном уровне. "
Вот это уже другое дело.
У меня интерфейсы репозиториев лежат в домене, а реализация в ифре.
Изначально была идея вообще все интерфейсы держать в домене. Но если можно обращаться из любого слоя в ифру, то это упрощает жизнь.
А вот, что касается справа на лево, тут невозможно, чтобы инфра не знала о домена, так как во первых интерфейсы, а во вторых те-же репозитроии возвращают сущности, ну и тп.
