Denioo

const role = vm.roles.find(r => r.id === roleId)
const name = role ? role.name : undefined  // если не найдет по айдишнику, то role будет undefined

const newArray = vm.roles.filter((item: {name: string}) => item.name === 'SOME NAME STRING');

если я правильно понял то можно реализовать таким образом, то есть в метод .filter() передаем функцию, с типизацией, где указываем что у нас в объекте есть поле name: string, ну и потом что бы функция фильтр внесла элемент в новый массив мы должны в переданной функции вернуть булево значение, то есть true/false, если будет true то элемента удовлетворяет текущим параметрам и будет добавлен в новый массив и наоборот

findIndex ждет функцию в качестве параметра. Если в массиве мы ищем индекс элемента, у которого поле name совпадает со значением в переменной name, то нужно
vm.roles.findIndex(item => item.name == name)

Серверная часть стандартного лендинга или визитки только обрабатывает формы - отсылает что-то куда-то (например, формы обратной связи, рассылки). Все остальное - фронтенд. Сможете такое сделать, уже хорошо.
Вот и выходит, что для простых вещей достаточного одного js и совсем чучуть php, да и то не всегда.

Если хотите чего-то свежего, попробуйте node.js.
Очень удобно писать и читать код, написанный на одном языке для бекенда и фронтенда.
Заказы на node.js есть, но не так чтобы прям очень много. Но они есть, и хорошо оплачиваются.

Но, конечно же php все еще остается любимым сыном веба. Очень много всего на нем написано. Полезно будет узнать хотя бы основы.
Много заказов на фрилансе требуют работы с CMS, а многие из них написаны на php. Если хотите брать заказы такого профиля, а их довольно много, придется разбираться как в самом языке (если задача требует), так и в устройстве систем.

Но вот не смотря на всю важность и актуальность php, если учить глубоко, я бы лучше учил node.js.

Мне кажется, сейчас не обязательно быть швецом-жнецом и учить все-все. Часто бекендом и фронтендом занимаются разные разработчики. Вы вполне можете не учить ничего, кроме js, ну и html, css, шаблонизаторов, сборщиков, библиотек и фреймворков)))

Что-то типа этого (ваши ветвления мне не совсем понятны, поэтому возможно вам придется скорректировать мой пример):

var query = QueryOver.Of<UserRoleMember>()
    .Where(x => x.User.Id == userAlias.Id);

if (_queryParams.RoleId != null)
{
    query = query
        .Where(x => x.AppRole.Id == _queryParams.RoleId)
}

if (_queryParams.BranchId != null)
{
    query = query
        .Where(x => x.Branch.Id == _queryParams.BranchId)
}

var result = query.Select(x => 1);
filteredUsers = filteredUsers.WithSubquery.WhereExists(result);

Сначала идет ТЗ. Потом - протоколы взаимодействия. А потом - уже все равно, хоть одновременно и веб и фронт. Это в сферическом идеале.

Обычно работа идет параллельно. Фронтендер, если не готов бэк, может делать запросы к файлам на сервере, предварительно записав туда информацию. Если работа фронта стоит без бэка, фронт просит бэк сделать нужный метод, сам принимается за другой.
Никто никогда время не тянет, а то бы теряли громадные деньги.
В компании тебе все объяснят и о фронте ты думать практически не будешь.

Никакой стандартной последовательности нет.
Разработка может происходить параллельно и в любом порядке. В некоторых случаях, когда верстка делается на шаблонах, разработчики backend могут даже и не видеть frontend до момента первого запуска.

Как договоритесь. Главное - чтобы работа шла эффективно.
В одном проекте сначала полгода можно пилить бек, потом за недельку фронт, в другом наоборот, в третьем нужна постоянная коммуникация и держать друг друга в курсе каждый день, и изменения могут быть первичны и в беке и во фронте.
Это если в команде хороший профессиональный уровень и взрослые люди, которые понимают зачем они там собрались. В реальной жизни можно встретить всякое, вплоть до истерик по поводу кто кому чего "должен" - и пока вы в конкретную команду не попадете, не узнаете заранее.

Так же есть разные специалисты - если это хороший фуллстек, и проект позволяет, то ему не составит труда пойти во фронт и бек и сделать сразу все что нужно. Если это монорепа это может быть вообще один коммит.

Так же есть разные методологии и подходы, например не разделение на фронт и бек команды а разделение на фича-команды. Когда одна команда пилит сразу и фронт и бек и что там еще нужно чтобы выкатить фичу в релиз.