Robur

похожи

Если прямо вот так сидят и не хотят переходить - то вводить более строгие правила по обновлению/добавлению библиотек и ноды.

что я бы сделал:
1. составить список проблем.
2. понять какие действия приводят к этим проблемам. Например обновление библиотек/добавление новых
3. написать как можно проверить что эти действия в каждый конкретный момент не сломали все. Например "если вы обновили библиотеку, то надо проверить что все нормально и в винде и на линуксе"
4. подумать как эти проверки сделать удобно. Может быть прикрутить в CI сборку под обе платформы на каждый коммит где затронули package.json, или обновлять либы только в отдельной ветке и просить проверить на другой платформе, и после этого только мержить.

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

В идеале конечно если проверка на то что все собирается под обеими платформами будет автоматическая после каждого коммита.

Либо фильтруете books перед map
books.filter(...).map(...)

или выводите null вместо элементов если книгу показывать не надо:

{books.map((book, index) => (IsHidden(book) ? null : <Card>

Но мне кажется что это костыль. Как правильно решить эту задачу ?

поставить loading = false при начале загрузки картинок, и после загрузки поставить его в true. Как именно - зависит от того как вы их грузите.
так как загружаются они видимо где-то еще, то loading вам придется хранить в стейте приложения, а не компонента.

Очевидно что модули у вас в проект не подключились.
какая версия ReactNative?

но у меня нет тех папок которые в примере !Например settings.gradle

Если бы это было правдой у вас вообще бы ничего не запускалось

вот тут посмотрите: https://gist.github.com/nandorojo/c641c176a053a9ab...
Если верить тому что там написано, надо просто путь к файлу передать в xhr. Я не проверял.

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

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

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

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

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

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

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