Kappy

web worker

хозяину ничего не нужно делать, он открывает приложение и фоткает прилавок с ценниками

Так ничего или всё таки нужно)
проблема-то здесь как раз таки в этой самой "цифровизации" которой нет в голове у людей, а не в том что никто такой сервис еще не придумал.

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

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

Дальше идёт собственно проблема "открываются новые бизнеса каждый месяц" в одном и том же месте. Кто это будет актуализировать? Опять же либо люди которых надо заставить как-то отметить что точка уже закрылась, либо новый хозяин точки должен подтвердить что он теперь тут и получить доступ к управлению данными чтобы заполнить новые. А если нового хозяина еще нет, а если новый про ваше приложение не в курсе и т.д.
На выходе куча мертвых точек которые никто кроме вас не собирается актуализировать.

В общем все проблемы от людей так или иначе. И либо вы сами будете все это заполнять(2ГИС например сам всё собирает), либо будет архив местячковых закрытых точек.

ап
всё что упомянуто так или иначе есть в гугле/яндексе. И там не обязательно быть хозяином даже чтобы добавить новую точку на карту, вот только кому это надо?
У гугла так вообще глобальная программа контрибуторов/"местных экспертов" где их всячески пинают и заставляют заполнять карты за ачивки. И работает это у гугла только потому что аудитория у гугла можете себе представить какая. Опять же там где оно никому не надо гугл карты тоже пустые.

Вот есть статья под CSS
Habr
А точнее вот эта часть

background-image:  url("media/fishing.svg"), url("media/mermaid.svg"), url("media/sea.png");  
    background-position: top right 10px, bottom left, top left;
    background-repeat: no-repeat, repeat-x, repeat-x ;

static getDerivedStateFromProps(props, state) {
  if (props.data !== state.data) {
    return {
      data: props.data,
    };
  }

  return null;
}

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

Проще всего для всех ссылок задать один общий класс classи стилизовать его.
Да и зачем вообще разные классы, если стили должны бить одинаковые?

querySelectorAll возвращает массив(точнее коллекцию элементов), и вы массиву пытаетесь назначить событие.
Событие нужно назначать каждому элементу массива

const modalBtns = document.querySelectorAll('.modal-btn li');
modalBtns.forEach(b=>b.addEventListener('click', openModal));

Все зависит от задачи. Если надо показывать страницу по другому пути, то используйте роутер, если нет, то state.

next(); должен в колбеке/then асинхронной функции вызываться

БД ещё не вернуло значения (только отправило), а next() уже сработал

router.get('/', function(req, res, next) {
  someaction({query}, (error, data) => { // тут от БД зависит, может быть через промисы
    if(data) next();
  })

}

Может ли опыт на React Native считаться одновременно опытом на обычном React? Они настолько похожи?

Я бы сказал, процентов на 60. Там нет CSS в традиционном понимании и свои правила раскладки, но то, что касается JS вполне транслируется в браузер - архитектура приложения, паттерны React и т.п. Система сборки там тоже своя и нет заморочек браузерного рендеринга.

Есть и такая, но, скорее всего, вы видели вот это: this.state = {...props}

Тогда не нужно будет писать this.state.props.foo, можно будет обращаться через this.props.foo.

На мой взгляд, это плохая практика и так можно делать только в некоторых очень ограниченных сценариях.

this.state = {...props}

1. data.goals[0].gs_id
Использование подобных, небезопасных конструкций считается плохим тоном.
2. Используйте в state ключ состояния загрузки.

export default class Forma extends React.Component {
    constructor(props) {
        super(props);

        this.state ={ data: {}, isFetching: true, error: null };
    }

    componentDidMount() {
        fetch('http://localhost:3001')
            .then(response => response.json())
            .then(result => this.setState({data: result, isFetching: false }));
            .catch(e => {
              console.log(e);
              this.setState({data: result, isFetching: false, error: e }));
            });
    }

    render() {
        const { data, isFetching, error } = this.state;
        
        if (isFetching) return <div>...Loading</div>;

        if (error) return <div>{`Error: ${e.message}`}</div>;

        return <h1>{data.goals[0].gs_id}</h1>;
    }


}

умных слов понаписали в вопросе, а сам вопрос простой) если хотите оптимальный по современным меркам вариант - используйте graphQL, если сложно или нет желания, старый добрый rest api.
А статьи на русском уважающий себя разработчик читать не будет, он будет читать источники ;-)

• Можно вынести эту папку в отдельный репозиторий и подключать как модуль git
  
• Можно запустить локальный npm-репозиторий и публиковать туда эту библиотеку компонентов