Каким образом?
const identity = getIdentity()
if(identity !== null && profile.id === identity.id) {
return <a href="/profile/edit">Редактировать профиль</a>
}А если он зашел просмотреть чужую страницу, как гость и написать ему (кнопка написать находится на странице пользователей)
const identity = getIdentity()
if(identity !== null && profile.id !== identity.id) {
return <a href="/message...">Написать сообщение</a>
}Как понять серверу и клиенту, что на сервере нам надо отдать данные, которые разрешены только для гостя или для администратора
насчет облака и "сами смогут" - возможно у нас разные програмисты и заказчики, я пока таких не встречал))
Есть ли смысл сделать фреймворканезависимую атхитектуру, используя такое тяжелое решение, как Laravel?Есть. Деление на слои это вообще не про фреймворки. Если Вы считаете обратное, тогда почему вам в сущность User сразу не кидать Request. Доставать из него нужные данные и сохранять в базу. Но почему-то так не делают. Потому что нижний слой не должен зависеть от верхнего. Сущность - это Ваша модель бизнеса. Если поместить туда вещи от фреймворка, то тогда это может вводить в заблуждение. Так же это ненужная зависимость. Предположим вы прокинули Request сразу в User. Тогда при любом изменении контракта Request - вам придётся менять это во всех сущностях. Так же Request есть в Web, но нет в Console. Кроме того ваши данные вообще могут быть загружены по API из стороннего сервиса через Guzzle. Тогда фреймворк ваш вообще ни каким боком не упал. Или вы захотите выделить систему Auth в микросервис. Если вы программировали изначально зависимую систему, то вам это будет сделать сложно. К тому же есть и другие проблемы. Вот Yii2 перестал развиваться. Yii3 ещё не вышел. И вы стали ограничены в развитии. Чтобы перейти на новый фреймворк - вам нужно отвязать ваш код от фреймворка, затем перенести на новый фреймворк и уже там накинуть инфраструктуру на ваш код. Описал сумбурно и точечно, но суть должна быть ясна.
По сути из всего прекрасного функционала Laravel будем использовать только руты, но при этом тянуть с собой всю эту обузу, в виде лишнего кода, как я понимаю.Вам никто не запрещает использовать не только рауты. Сделайте свою обётрку и вам вообще не важно какая там зависимость. Этот же Mailer в проекте будет иметь MailerInterface в качестве контракта и реализацию LaravelMailer, SymfonyMailer, UnisenderMailer и так далее.
В этом случае вам стоило бы ещё отметить в проектах какого масштаба стоит применить столь громоздкую архитектуру, а в каких лучше обойтись средствами фреймворка. Предполагаю, что для такого архитектурного решения должна быть жесткая необходимость.Если проект будет жить больше года и в нём не пару строк кода, то лучше сразу применять. Она вообще не громоздкая. Вам так кажется. Вам будет проще жить с этим. Будет меньше ошибок. Представьте контроллер на 15 строк кода или на 1500. Тут вам решать. Жёсткая необходимость заключается в развитии. Если оно есть - это уже ваш критерий. Единственное вам может казаться что она громоздкая только потому что вы плохо в ней ориентируетесь и мало что знаете про это. По таким суждениям тогда и не нужны лишние библиотеки, вроде Psalm, PHPUnit, Rector, Deptrac, PHP CS Fixer и так далее. Зачем вообще себя утруждать писать лишний код в тестах, какую-то типизацию делать в проекте)) Слишком громоздко… И так сойдёт.
$user->status = 'active' и пользователь стент активирован. И разработчику плевать о том, какую логину переходов из статуса в статус вы заложили. Например, для User вы можете поставить условие, что пользователя можно активировать только в том случае, если его почта подтверждена. Для этого в методе activate() вы добавляете проверку подтверждения. Если не подтвердил - выбрасываем исключение. Таким образом ваша система и сущность User всегда соблюдает бизнес требования. Вы защищены от вмешательств через публичные поля. Кроме того в этом же методе activate() можно опубликовать событие для другого модуля, который пришлет приветственное письмо с дальнейшими инструкциями. Если изменять статус напрямую ничего этого не будет.