Robur

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

Можно и так, можно и в 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 положил в глобальный объект какой-то.

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

Если вы поставите маску /32 - у вас там будет только один хост в сети а надо минимум 3 - ваш сервер, роутер, и broadcast. Так что сеть может быть как максимум /30. И хостеру придется для каждого пользователя такую сеть создавать и в каждую выставлять роутер по дефолту.
При публичных IP смысла в этом нет - вы все равно будете способны их точно так же пропинговать, ровно как и любой другой адрес в интернет, зато адреса расходуются впустую.

^(?:мини)\s([^]+)?
поиграться и проверить можно тут https://regexr.com