Nikita

const [ active, setActive ] = useState(null);
const item = test.title[active];

const onClick = e => setActive(e.target.dataset.id);

Кнопки:

{Object.keys(test.title).map(n =>
  <button key={n} data-id={n} onClick={onClick}>{n}</button>
)}

Выбранный элемент:

{item && <div>{item.title} ---- {item.category}</div>}

Например так или так

Когда гораздо проще сделать так:
MyObject::myMethod();

Если myMethod не влияет на внутреннее состояние объекта (изменяет members) - то так и надо делать (static).
Пример статических:
User::getStatusList() -- возвращает список возможных статусов для всех пользователей
User::findById() -- ищёт в базе по ID и возвращает нового пользователя

Пример нестатических:
$user->setName('xxx'); мы работаем только с текущим пользователем
$user->delete() мы работаем только с текущим пользователем

Исключения и есть современный способ реакции программы на ошибки, которые приводят к бессмысленности дальнейшего её выполнения. Соответственно, если у пользователя недостаточно средств для перевода, дальнейшее выполнение программы не имеет смысла, необходимо прервать её выполнение выбросив исключение. Когда этого механизма не существовало использовали коды ошибок.

Вы также всегда имеете возможность посмотреть популярные open-source решения и убедиться какой точки зрения придерживается сообщество.

Laravel это мозг, сердце, печень, почки. Ты их не видишь, но они есть (почти всегда). Бутстрап – лицо, кожа, волосы. Ты их видишь, но смысла в них без сердца немного. Потому что они связаны. Как печень работает, так и кожа-рожа выглядит. Как мозг работает так и человек себя ведет. Так же и с сайтом. Например, форма авторизации вк. Ты ее видишь. Кнопочки, цвета, формы. Это типа Bootstrap. Когда ты вводишь свои данные и нажимаешь кнопку отправить они улетают в Ларавел на сервер. Он эти данные получает и начинает проверять. Если то, если это, какой телефон, телефон ли и т.д. Это программист написал логику в Ларавеле на php. Ты эту логику не знаешь и не видишь, но она командует парадом, Bootstrap и всеми действиями юзера на сайте.

Бросать исключение или возвращать коды ошибок/успеха?

Бросать исключение.

Является ли исключением то, что метод не может выполнить свою задачу?

Конечно же.

Но узнать является ли сумма(amount) корректной по-хорошему можно только в браузере/GUI или в Domain слое в самом методе transferMoney().

К фронту не должно быть доверия, данные обязательно нужно проверять.
Аргументы метода лучше проверять И на тип И на граничные значения. Например ваш amount по идее должен быть float + больше, или равен 0. Если amount таковым не является - бросайте исключение. Логика выше должна была это отсечь, еще на этапе валидации данных запроса.

В transferMoney() нужно извлечь данные пользователя(который пересылает деньги) из БД и проверить есть ли у него такая сумма.

Если ваш метод непосредственно имеет дело с кошельком пользователя - проверка в нем должна быть обязательно. Если же этот метод - только посредник, подобную проверку можно сделать в другом месте.

Получается в методе transferMoney() есть одна причина неудачи, а что если добавится ещё одна причина, например, пользователю запрещено временно пересылать деньги?

Тот же комментарий, что и про баланс.

Поскольку они ожидаемые, то бросать исключения не логично.

Почему же? Логика выше сможет обработать ваши ожидаемые исключения и через множественный catch определить, что не так. Это вполне нормально, и даже удобно.

В случае если бы была одна причина неудачи, то можно было бы просто вернуть false.

Очень хреновая практика. Как вы определите в вызывающем коде, что пошло не так? Что "false"? Баланса не хватает, нельзя делать покупки, или Меркурий в ретрограде?

возвращать что-то на подобии [false, $error] и [true, null]

Для php - это очень кривой подход. По двум причинам:
1. Вы расширяете интерфейс метода, просто так.
2. Вы нагружаете вызывающий код дополнительными обвязками проверок, опять же просто так.
В этом нет смысла так как есть механизм try-catch, который отлично решает это задачу.
Вот пример, допустим ваш transferMoney($amount, User $recipient) должен возвращать объект транзакции, пусть его сигнатура будет:
transferMoney(float $amount, User $recipient): Transaction
Вызывающий код знает, что он обязан в конце получить транзакцию, а если что-то пойдет не так - будет исключение, нет смысла в дополнительных проверках, а что если первый элемент массива false, а что если он true, но второй элемент не null, а что если второй элемент не тот, что ожидалось, а что если первый элемент - строка, и т.д.

transferMoney() не должен подстраиваться под слой повыше, в нём не должно быть никаких предположений, что пользователь введёт что-то правильно или неправильно, он просто должен ожидать только валидные данные, если они неправильные, то это исключительная ситуация.

Верно

То есть transferMoney() выбросит исключение, которое подымется до Controller'a, и на основе которого Controller отправит 400 Bad Request и причину неудачи.

Угу

Или всё таки первый подход к проблеме лучше(первый абзац)?

Первый подход - это путь боли, ошибок и отчаянья.

Вот вам еще чтива: https://github.com/index0h/php-conventions

Я думаю, человек спрашивает про операторы ветвления.
То есть нужен тернарный и его сокращённые формы: элвис, и объединения с null

(условие) ? значение 1 : значение 2; // если условие, то вернем значение 1, иначе значение 2
$var ?:  значение 2; // если $var не пустое, то вернем его, если нет - то значение 2
$var ??  значение 2; // если $var существует, то вернем его, если нет - то значение 2

Все просто.
undefined и null это 2 специальных типа данных. они равны только друг другу при == (не строгом сравнении) и не равны ничему более.
NaN - то есть not a number(не число).(Я думаю все и так ясно). Появляется при ошибки в вычислениях.
let num = "Hi" * 12;
console.log(num) // NaN
Можешь почитать:
https://learn.javascript.ru/types
https://learn.javascript.ru/type-conversions

палка же. если условия удовлетворяют и вам важно доверие от клиентов.

Вопрос, как всегда, поставлен жутко неграмотно, так сказать, по деревенски: без какого бы то ни было видения перспективы, хотя бы на 5 лет вперёд.

Изучать какой-либо современный фреймворк ради *карьеры* - несусветная глупость. 5 лет назад ларавеля не было, а симфони и зенд были в таком виде, что мы бы сейчас обплевались. При том что различия между современными версиями довольно минимальны.

Это, я не знаю, как спросить "хочу быть столяром, какую отвёртку мне изучать, крестовую или шлицевую?".

Изучать, ради карьеры, надо столярное ремесло целиком. В данном случае - программирование. Принципы, на которых устроены фреймворки. Одного этого хватит на те же лет 5. Зато потом не будет проблемы адаптироваться к неизбежным изменениям.

А если считать пределом мечтаний клепание говносайтов на некоем идеальном фреймворке на все времена, то может так случиться, что через 5 лет к условным "ларавельщикам" будут относиться так же, как сейчас к вордпрессникам.

И кстати для изучения принципов симфони подходит лучше

Да - и конечно же, все ответы туда же.
Один решил меряться количеством скачиваний. Ну если судить по такому критерию, то все перечисленное - букашки, которые копошатся под подошвами Вордпресса, с его присными темами и плагинами.

Да, и самое главное я тоже забыл сказать. Коллега xfg в самую точку написал в комментарии:

Фреймоворк - это на самом деле тонюсенькая прослойка над приложением. Это, по сути, система подай-принеси, принять запрос с фронта и отправить ответ. А что именно будет в ответе - решает не фреймворк, он здесь уже не при делах.

Очень на эту тему прочищают мозги доклады и видео Дмитрия Елисеева. У него на сайте как раз появился доклад с PHP Russia 2019, который я горячо рекомендую.

На ту же тему был и доклад Томаша Вотрубы, кстати. Что фреймворки, по сути, можно менять как перчатки, при желании. И у него есть даже инструмент для этого. Но в данном случае речь не об инструменте а о том, что фреймворк- далеко не главная часть приложения, и упираться в изучение фреймворков это все равно что в изучение отверток.

облако - это гибкое управление инфраструктурой.
автоматическое создание нужных инстансов когда они нужны (и удаление их когда они не нужны) с автоматическими балансерами; изменение параметров сервера налету; беспроблемная миграция между разными локациями; всякие сервер-лесс'ы/и т.п./т.д.
трендово: потому что люди лепят этот термин зачастую даже не понимая что он значит.
по факту: хомякам вообще без разницы.