Persotr27

Я думал об обратной миграции, с некста на какой-нибудь другой сср, главная проблема возникает с роутером. Его переписывание может занять много времени. При этом вероятно потребуется переработка многих компонентов проекта, потому что некстовый роутер ориентируется на файловую систему, и не умеет делать роутинг внутри компонента.
Как альтернативу могу предложить рассмотреть стандартный раектовский SSR, его можно на любом Node.js фреймворке сделать, например на экспрессе, это займет меньше времени вероятно. И еще можно попробовать After.js, он почти такой же как Next.js, но использует react-router, поэтому должно быть проще.
И использование styled-components может сильно замедлять скорость обработки страницы на сервере. Если делаете SSR, стоит либо оптимизировать код этих компонентов, либо отказаться от них в пользу аналогичных библиотек без рантайма, вроде linaria или astroturf

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

Не боги горшки обжигают. Часто всякие советы - "среднее по больнице", хотите - пробуйте,в крайнем случае - откажетесь! Но мне кажется, что вам может понравиться))

Можете пояснить, как вы можете знать весь этот стек, не имея никакого опыта реальной (коммерческой) разработки?

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

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

Большинство отличий -
1) Используются не теги а react-native components (например View = аналог дива, Image = аналог img)
2) Есть некоторые правила и исключения, например некоторые css стили не работают/работают по другому и есть новые. Например View по стандарту уже flex с flexDirection: column (хотя div пустой изначально)
3) Для доступы к нативным компонентам используются модули сообщества/facebook, например нативная navigation
4) Есть конечно же и другие отличия, например свои методы по типу alert, которые надо импортировать, вибрация, подключение к сети, типы клавиатур и т.д.

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

https://jsfiddle.net/vkorotenko/0adrwbLo/

Простейший вариант

https://codepen.io/5h4dy_s/pen/ZEOMBoX

В php есть функция nl2br, которая ставить теги br
В js такой функции нет, но есть кастомная функция, регулярка, которая делает почти тоже самое.


Источник

Просто примените к div-блоку, где вставлен текст CSS свойство white-space: pre-wrap;

htmlbook.ru/css/white-space

Прокидывать запросы через свой бэкенд, и хранить ключ на сервере

Есть два способа.
1) Как уже написали все пропускаешь через свой прокси бекенд и на нем хранишь ключи. Не самый лучший способ потому что затратный и при этом требует соблюдения некоторых правил. a) на твоем бекенде должен быть отключен CORS и работать он должен на том эе домене что и фронт, иначе смысла от этой возни - 0 , б) смысл это все затевать есть только в том случае если в API к которому ты стучишся с ключем нет возможности настроить ограничение по Origin запроса.

2) Не знаю к какому API ты пытаешся достучаться, но Google API, AWS API, github имею возможность настроить ограничение по Origin, этим ключем можно воспользоваться только с твоего сайта.

Как это можно предостеречь и не допустить?

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

Sortable.js - очевидно же!
демо
ES2015+
mixin