А я на этом дерьме написал проект на 100К строк. Миддлвару использовал только для CSP. Она там вообще чисто чтоб было, а проку ноль. Rest маршруты тупо декорировал функциями с логированием, авторизацией и прочими делами. А вот с тем, как код пересекает границу сервер-клиент я дофига проблем словил. Так что второй раз пожалуй ни для чего серьезного я nextjs не возьму
Вы рассуждаете по ООП-шному и как будто хотите склеить два разноплановых подхода ООП-шными принципами.
Я примерно понимаю на чем стоит ваша аргументация, поправьте если я неправ, что применение FoodMenuClient.live() дефолтным значением аргумента плохо тем, что о существовании live имплементации становится известно модулю (не классу) и он начинает от нее зависеть. В этом нет никакой проблемы, так как в сниппетах кода из статьи конечно же не полный production-grade пример как скомпоновать зависимости. Полная картина может быть несколько сложнее, но принцип тот же. В ней не используются классовые View, Presenter, Interactor или что там еще можно придумать в качестве ООП-like архитектуры.
Любая высокоабстрактная ООП архитектура в итоге заканчивается классами с реализацией, но создает неповоротливость, большое кол-во бойлерплейта. В функциональном мире, созданию абстракций отводится меньше значения так как атомарность логики компенсирует связность, не требует сложных подходов к подмене имплементаций, инъекции зависимостей и тд. То есть формально передача зависимости аргументом функции это тоже DI, но инъекция через аннотацию всё таки на другой стороне архитектурного спектра.
При таком проектировании, всё исходит из идеи, что View - функция от State (что и представляет собой Compose). А State - кусочек иммутабельных данных без логики. Логика с зависимостями от компонентов с версткой отделяется созданием двухэтажных компонент: FoodMenuLogicComposable + FoodMenuLayoutComposable. К этому прилагается тонкая View модель реагирующая на события и обрабатывающая их в Клиентах. Вот и вся архитектура. Под клиентами может быть масса других частей: кеши, база, неворкинг и тд и тп скрытых под своими клиентами. Компонуются плюс-минус тем же способом по принципу фрактала - множество треугольничков имеют похожую форму, но в составной объект может принимать любые формы. То есть при необходимости перекомпоновки под новые требования атомарные компоненты перекомпонуются на раз-два.
Суть DI заключается в разрыве прямой связи между реализациями сущностей, что достигается прокидыванием зависимостей в объект извне самого объекта.
Разрыв связи, о котором вы пытаетесь сказать это Dependency Inversion. Суть его в том, чтобы изменить направление зависимости: Получатель зависимости зависит от ее абстракции, а не реализации.
Инъекция зависимости к этому не имеет отношения. В примере зависимость закрыта своим интерфейсом и создается за пределами объекта-приемника, с масштабируемостью тут никаких проблем нет. А вот создавать единый граф и протягивать его сквозь приложение - подход действительно плохой, по той же причине, по которой андроидеры ругаются на глобальные объекты предлагаемые SDK.
Чтобы понять и верно построить архитектуру в принципах, о которых говорит автор, нужно придерживаться нескольких правил: модуляризация всего, зависимости без состояния, дробление функционала сложных зависимостей на атомарные подзависимости в высококомпозируемых функциях, использование статического инстанцирования (все объекты, какие возможно в рамках здравого смысла, а таких должен быть минимум, создаются на статическими при старте приложения).
Большие кодовые базы UI (~1,5 млн строк) прекрасно живут с этим подходом. Попробуйте! Уверен, вам понравится простота, от которой поначалу будет казаться, что где-то должен быть подвох.
Это дискуссионный вопрос. Я с вами согласен, фишинг - проблема. Но фишинг - это мимикрия под то, чему вы доверяете. Вариации дизайна точно не пытаются пользователя обмануть. Если вы посмотрите на формы входа различных сервисов, вы заметите что кнопки входа через Google, Яндекс и других провайдеров соответствуют мягким гайдлайнам (тот же Яндекс предлагает варианты на выбор), но стилизованы под дизайн продукта. Мы же не говорим о проблеме фишинга авторизации гугла.
У телеги есть прописанные гайдлайны, все что не по ним это уже от лукавого
Честно говоря, не видел чтобы у телеги были какие-то ясные гайдлайны на этот счет, поделитесь ссылкой где они прописаны.
их надо уважать даже если кнопка не вписывается в ваш интерфейс
так никто не делает, просто потому что тут нечего уважать. Много iOS приложений строго следует Apple Human Interface Guidelines? Или на Андроиде все под копирку используют Material Design? Конечно нет. Если кнопка синяя с фирменным самолетиком телеграма с надписью «Войти с Telegram», этого достаточно, чтобы юзер идентифицировал функцию кнопки. А опасность фишинга меньшая из тех, что я привел в статье.
А я на этом дерьме написал проект на 100К строк. Миддлвару использовал только для CSP. Она там вообще чисто чтоб было, а проку ноль. Rest маршруты тупо декорировал функциями с логированием, авторизацией и прочими делами. А вот с тем, как код пересекает границу сервер-клиент я дофига проблем словил. Так что второй раз пожалуй ни для чего серьезного я nextjs не возьму
Вы рассуждаете по ООП-шному и как будто хотите склеить два разноплановых подхода ООП-шными принципами.
Я примерно понимаю на чем стоит ваша аргументация, поправьте если я неправ, что применение
FoodMenuClient.live()дефолтным значением аргумента плохо тем, что о существовании live имплементации становится известно модулю (не классу) и он начинает от нее зависеть. В этом нет никакой проблемы, так как в сниппетах кода из статьи конечно же не полный production-grade пример как скомпоновать зависимости. Полная картина может быть несколько сложнее, но принцип тот же. В ней не используются классовые View, Presenter, Interactor или что там еще можно придумать в качестве ООП-like архитектуры.Любая высокоабстрактная ООП архитектура в итоге заканчивается классами с реализацией, но создает неповоротливость, большое кол-во бойлерплейта. В функциональном мире, созданию абстракций отводится меньше значения так как атомарность логики компенсирует связность, не требует сложных подходов к подмене имплементаций, инъекции зависимостей и тд. То есть формально передача зависимости аргументом функции это тоже DI, но инъекция через аннотацию всё таки на другой стороне архитектурного спектра.
При таком проектировании, всё исходит из идеи, что View - функция от State (что и представляет собой Compose). А State - кусочек иммутабельных данных без логики.
Логика с зависимостями от компонентов с версткой отделяется созданием двухэтажных компонент: FoodMenuLogicComposable + FoodMenuLayoutComposable. К этому прилагается тонкая View модель реагирующая на события и обрабатывающая их в Клиентах. Вот и вся архитектура. Под клиентами может быть масса других частей: кеши, база, неворкинг и тд и тп скрытых под своими клиентами. Компонуются плюс-минус тем же способом по принципу фрактала - множество треугольничков имеют похожую форму, но в составной объект может принимать любые формы. То есть при необходимости перекомпоновки под новые требования атомарные компоненты перекомпонуются на раз-два.
Разрыв связи, о котором вы пытаетесь сказать это Dependency Inversion. Суть его в том, чтобы изменить направление зависимости: Получатель зависимости зависит от ее абстракции, а не реализации.
Инъекция зависимости к этому не имеет отношения. В примере зависимость закрыта своим интерфейсом и создается за пределами объекта-приемника, с масштабируемостью тут никаких проблем нет. А вот создавать единый граф и протягивать его сквозь приложение - подход действительно плохой, по той же причине, по которой андроидеры ругаются на глобальные объекты предлагаемые SDK.
Чтобы понять и верно построить архитектуру в принципах, о которых говорит автор, нужно придерживаться нескольких правил: модуляризация всего, зависимости без состояния, дробление функционала сложных зависимостей на атомарные подзависимости в высококомпозируемых функциях, использование статического инстанцирования (все объекты, какие возможно в рамках здравого смысла, а таких должен быть минимум, создаются на статическими при старте приложения).
Большие кодовые базы UI (~1,5 млн строк) прекрасно живут с этим подходом. Попробуйте! Уверен, вам понравится простота, от которой поначалу будет казаться, что где-то должен быть подвох.
Это дискуссионный вопрос. Я с вами согласен, фишинг - проблема. Но фишинг - это мимикрия под то, чему вы доверяете. Вариации дизайна точно не пытаются пользователя обмануть. Если вы посмотрите на формы входа различных сервисов, вы заметите что кнопки входа через Google, Яндекс и других провайдеров соответствуют мягким гайдлайнам (тот же Яндекс предлагает варианты на выбор), но стилизованы под дизайн продукта. Мы же не говорим о проблеме фишинга авторизации гугла.
Честно говоря, не видел чтобы у телеги были какие-то ясные гайдлайны на этот счет, поделитесь ссылкой где они прописаны.
так никто не делает, просто потому что тут нечего уважать. Много iOS приложений строго следует Apple Human Interface Guidelines? Или на Андроиде все под копирку используют Material Design? Конечно нет. Если кнопка синяя с фирменным самолетиком телеграма с надписью «Войти с Telegram», этого достаточно, чтобы юзер идентифицировал функцию кнопки. А опасность фишинга меньшая из тех, что я привел в статье.
Хехе, передам дизайнеру ) к счастью, преимущества собственного дизайна в том, что его можно менять )