Robur

нормально.
Нет особой разницы как вы выводите список, через map или как-то еще. Если вам нужно вывести все эти 20? компонентов - вы их должны вывести и основные тормоза у вас будут не во время работы .map а во время рендеринга этого всего на страницу и обновления потом. Используйте стабильные Id, если сильно переживаете.

О производительности надо беспокоиться когда что-то начинает тормозить. Ну или хотя бы тогда когда вы сделали профилирование и что-то вам там не понравилось.

Если прямо очень-очень хочется сделать все максимально оптимально - возьмите mobx и mobx-react с его бесплатной оптимизацией из коробки, и разбейте все на достаточно мелкие объекты и компоненты.

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

Возможно, но судя по вопросам вам еще во многом предстоит разобраться. Вряд ли вам кто-то будет тут писать конфиги nginx и вебпака.
Гуглите react/vue production build.
и скорее всего еще пригодится роутинг в аппах, history api и как настроить nginx чтобы он по всем роутам которые есть в приложении отдавал нужный js, а при обращении к css/картинкам - отдавал их.
еще есть codesplitting, чтобы грузились только нужные части приложения но для начала сделайте все одним js файлом, чтобы понять как оно все работает.

Вашему фронтендщику стоит посоветовать сначала изучить как это делается а потом огород городить.
но судя по тому что вы вместо него это выясняете, его все устраивает а вас - нет.

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

Не очень понятно что значит "запрос для входа пользователя" и "запрос для входа менеджера" -
у вас предполагается что пользователь будет нажимать на разные кнопки "войти как менеджер" и "войти как пользователь" или что?

Нормально так:
Кнопка для логина - одна.
запрос аутентификации - один.
сервер отвечает ошибкой или успешным ответом. Сама сессия ставится кукой, эта кука по хорошему должна быть httpOnly и из js кода не доступна. С ней работает исключительно бэкенд и так как хочет.
Аппа из ответа сервера (в body) либо сделав отдельный запрос (типа /currentUser) понимает что это за пользователь - менеджер или обычный и сохраняет это куда-то себе. В случае реакта это с большой вероятностью стор. Можно в localStorage чтобы при перезагрузке читать сразу оттуда.

Дальше аппа просто смотрит в стор в нужные моменты чтобы понять что пользователю показывать что нет.
Все права на запросы бекенд разруливает на основе сессионной куки которая приходит с каждым запросом автоматически. То есть сессии как таковой фронт вообще никак не касается - его дело - вызывать login/logout, получить от бэка инфу о текущем юзере и правильно обрабатывать 401.

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

Можно и так, можно и в reducer, или actions. Действия с данными делать надо там где это уместно, а уместность зависит от того что именно вы делаете.

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

Можно.
Apollo в своем кэше может хранить все данные приложения относящиеся к серверу (фактически это все кроме состояния UI и еще пары мелочей типа сессии пользователя)

Так что в mobx просто становится меньше смысла, но совсем он не пропадает - если вам нужно зачем-то шарить состояние компонент друг между другом.

Ребята в Apollo предлагают его же использовать как стор и обращаться к локальному состоянию с помощью gql так же как и к удаленным данным. Не уверен насколько такой подход реально удобен в работе с состоянием компонентов, но возможность добавить какие-то локальные свойства к данным весьма неплоха.
вот тут можно почитать: https://www.apollographql.com/docs/react/essential...

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

"вообще" соглашения такого нет, да и вообще каких-то общих практик за пределами рекомендованного в доках довольно мало.

вам поможет https://reactjs.org/docs/react-component.html#stat...
но на самом деле вам нужно использовать props напрямую, в state хранить только то что может поменяться в процессе работы самого компонента при неизменных пропсах

Законно, по крайней мере пока еще не запретили, но возможно мы к этому когда-нибудь придем.
Храните как вам удобно - интерфейсы бывают разные, если это вообще глобальные - то в один файл в корне, но таких на самом деле обычно мало и больше тайп-конвертеры.
Чаще всего интерфейсы описывают какие-то сущности, кладите их туда же где и код который отвечает за эти сущности.
Например если у вас есть стор и в нем какие-то данные описанные интерфейсами - кладите рядом с данными и экспортируйте оттуда.
Если есть апи которое возвращает данные и для этих данных есть интерфейсы - кладите рядом с апи. И так далее.
Можно прямо в файлах с логикой, можно рядом в файле чисто с интерфейсами. Мне удобнее все в одном - так как если что-то меняется в интерфейсе то обычно меняется вместе с логикой.

так же как и vue.
подключаете js в котором инициализация реакт - приложения в нужный контейнер.
Данные туда можно передавать по разному, я бы просто в js положил в глобальный объект какой-то.

Смысл может быть а может и не быть.
Если у вас компонент состоит только из одного тега и все - то конечно нет смысла.
Если есть хотя бы две вещи связанные друг с другом, например тег+стиль, или тег+код - то уже есть смысл.

render() {
  return (
    <ul>
     {this.state.items.map((item, idx) => <li className={`style-${idx%3+1}`}>{item}</li>}
    </ul>
  );
}

Надеюсь вы поймете о чем я