Алексей Варфоломеев

В ру сегменте такое называется "Барыжничество". Достаточно много людей этим промышляют.
Берут на западе заказы за 1к$, и сливают на русские биржи за 500$ - разницу в карман.

Везде советуют лочить jivosite adblock-ом, фильтр свой создаете с таким параметром *jivosite.com* должно работать. Обратите внимание на домен! Именно .com! Можно и .ru запихать туда, заодно.
Ну и в хостс тоже с .com пропишите, как вариант.

Вопрос конечно больше вкуса, но все же SASS в синтаксисе SCSS
Из плюсов могу сказать:
- Самый богатый функционал (ИМХО)
- CSS - это валидный SCSS
- Многие библиотеки написаны сегодня на нем, что позволяет подгружать их по частям или использовать на уровне миксинов и функций
- Возможность переопределить загрузку import'ов
- Возможность писать функции на языке сборки - в большинстве случаев не надо, но все же полезно
- Единое ядро на C и байндинги ко множеству языков

Vue Native это обертка над React Native.
NativeScript это отдельный кроссплатформенный фреймворк который дает доступ к нативным компонентам платформы. И оба эти инструмента это не WebView.
NS использует движок V8 JavaScript для Android и JavaScriptCore для iOS. RN использует только JavaScriptCore
для обеих платформ. NS может в JS, TS, Angular и в этом году добавили официальную поддержку Vue за счет интеграции с плагином nativescript-vue
Можно в playground'e пощупать.

С RN я не работал, как и с VN, но мне интересно развитие NS.
В общих чертах RN и NS похожи, но отличаются архитектурой взаимодействия с родными модулями платформ.
NS работает c API интерфейсом платформы непосредственно в движке JS, отправляя вызовы и конвертируя данные на лету. При компиляции все XML компоненты передаются на собственные компоненты Android и iOS перед упаковкой в ​​двоичный файл платформы. В оф.документации все расписано
Есть хорошая статья в блоге NS, где они разбирают серию статей от Airbnb об опыте с RN.

Считаю что NativeScript недооценен сообществом, годный продукт.

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

mike153: пробовал все варианты. Nextcloud - это форк Owncloud. По сути, одно и то же, хоть и NC считается более продвинутым и вообще вся опенсорсная тусовка туда ушла. Поэтому пишу о нём. Всё исключительно на правах IMHO. Плюсы:
- Самый главный - это работа с файлами именно в файловом варианте. То есть, если предположить, что "всё упало", вы можете подключить диск с рухнувшего сервера к любому линуксу и вытащить инфу из /var/www или где она там у вас храниться будет. Также можно подключать внешние хранилища, то есть, предположим, есть у вас на сервере папка с фильмами и музыкой - их можно просто подключить в NC.
- CardDAV, CalDAV из коробки.
Минусы:
- Тормозит всегда, рандомно, в любой момент времени. Независимо от того Apache или Nginx, MySQL или MariaDB, тормозит на любом софте.
- Интерфейс - УГ, ШГ

Теперь о Seafile. Плюсы:
- Турбореактивный просто. Работает очень быстро.
- Интерфейс очень приятный.
- Продвинутое версионирование.
- Умеет открывать docx, odt, xlsx и т.д. без дополнительного софта. Но без редактирования. Если нужно редактирование - нужен отдельный Document Server от Collabora или Onlyoffice.
- PRO-версия бесплатна для 3-х пользователей, но смысла особого нет, т.к. enterprise-фишки заключаются в 1. полнотекстовому поиску по документам с помощью elasticsearch, у которого просто чудовищное потребление ресурсов 2. двух-факторной авторизации 3. и что-то там ещё, не особо нужное дома
- Есть клиенты для всех основных платформ
- Устанавливать можно как вручную по мануалу на сайте, так и воспользовавшись установочным скриптом, который сам всё сделает.
Минусы:
- Файлы хранятся в собственном формате, как это правильно называется? - на уровне блоков, что ли. Доступ к инфе только через веб-интерфейс, WebDAV, ну и приложения для синхронизации. То есть, вся информация в Seafile на диске представляет просто кучу мала из папок и файлов, которые нельзя так просто взять и использовать - нужен ещё дамп базы данных. То есть, в случае проблем с системой, достать информацию будет затруднительно. Но выход есть - seaf-cli - это безгуёвый клиент для синхронизации. Смысл в том, что на сервере, на котором крутится Seafile, дополнительно можно установить seaf-cli, натравить его на директорию, и он в эту самую директорию будет складывать синхронизированную копию инфы основной базы Seafile, причём в виде нормальных файлов, которые можно расшаривать как угодно, бэкапить и т.д. Минус решения с seaf-cli в том, что нужно вдвое больше дискового пространства для хранения инфы.
- Ну и как следствие такой организации файлов - невозможность подключить внешние хранилища, в отличие от тёплого лампового Nextcloud.

В общем, лично я остановился на Seafile.

Или используйте старый xhr (новый fetch тоже норм). В общем, тут суть в том, что ваш вопрос больше о том, как сделать асинхронный запрос в React. Все просто: храните начальное состояние и флаг загрузки в стейте. При запросе обновляйте. Реакт сам все отрисует при изменение стейта.

Пример (код с одной из глав нового учебника, если интересно инфа в профиле)

class App extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      data: [],
      isLoading: false,
    }
  }
  componentDidMount() {
    const xhr = new XMLHttpRequest();
    xhr.open('GET', 'http://localhost:3000/data.json', true); // замените адрес
    xhr.send();
    this.setState({ isLoading: true })

    xhr.onreadystatechange = () => {
      if (xhr.readyState !== 4) {
        return false
      }

      if (xhr.status !== 200) {
        console.log(xhr.status + ': ' + xhr.statusText)
      } else {
        this.setState({
          data: JSON.parse(xhr.responseText),
          isLoading: false,
        })
      }
    }
  }
  renderProducts() {
    const { data, isLoading } = this.state
    if (isLoading) {
      return <img src='/i/preloader.gif' alt='загружаю...' /> // рисуем прелоадер
    } else {
      return data.map(item => {
        // я здесь отрисываю все через другой компонент, вы же можете просто рисовать сразу верстку для начала
        return <ProductCard key={item.id} name={item.name} price={item.price} quantity={item.quantity} />
      })
    }
  }
  render() {
    return (
      <div className='App'>
        <div className='product-list'>
          {this.renderProducts()}
        </div>
      </div>
    )
  }
}

Вариантов немного, конечно же NFS, но есть возможность повеситься при обращении к файловой системе (причем на очень продолжительное время), когда она (NFS) недоступна например из-за отсутствия связи.
Со своей стороны я бы такого не делал, а поставил бы какой нибудь CDN сервис типа S3, куда и бросал бы файлы. Например minio https://www.minio.io
Вот еще один интересный проект, немного не S3, но по архитектуре довольно прикольный - https://github.com/chrislusf/seaweedfs

Ну всем известная WOT от Wargaming использует много Python.

Вот их канал на ютубе Wargaming CIS, очень много питона.

Дело в том, что метод click создает событие click, которое имеет свойства screenX и screenY, то есть должно происходить на "видимом" экране. Работа через Selenium не меняет того факта, что браузер и все скрипты на странице работают с неким "видимым" экраном. Иначе одной строкой на js можно было бы легко выявить весь обман и отсутствие живого человека по ту сторону браузера.
Но find_elements_by_xpath возвращает все соответствующие данному xpath элементы дерева в независимости от их реальной видимости. При этом невозможно вызвать click на элементе за пределами "видимого" экрана.
Частично решить эту проблему можно путем вызова scrollIntoView на элементе перед click. Но у этого метода тоже могут возникать проблемы с элементами, у которых (или у их родителей) style="display:none".