React - Wie lade und binde ich eine App in eine bestehende Webseite ein?

[ebody]

Hallo,

ich habe eine erste React App erstellt und u.a. dieses m.M.n. sehr empfehlenswerte Tutorial genutzt.

Jetzt möchte die App in eine bestehende Webseite (example.html) und in ein darin existierendes HTML Element mit der id="searchApp" einbinden und frage mich, ob ich es richtig verstanden habe, welche Wege es dafür gibt und was der beste Weg wäre.

Ich habe create-react-app verwendet, wodurch diese Ordnerstruktur generiert wird und einige Ordner und einige Dateien von mir ergänzt/gelöscht wurden.

my-app/
- node_modules/
- public/  
-- index.html
-- favicon.ico 
- src/
-- components/
-- App.css
-- App.js 
-- index.css 
-- index.js
- README.md
- package.json
- .gitignore

Ich würde jetzt nur den /src/ Ordner per FTP hochladen und in der index.js das Ziel Element von root in searchApp ändern:

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('searchApp')
);

In example.html würde ich diese Tags vor das </body> Tag einbauen:

<!-- React einbinden -->
<script src="https://unpkg.com/react@17/umd/react.production.min.js" crossorigin></script>
<script src="https://unpkg.com/react-dom@17/umd/react-dom.production.min.js" crossorigin></script>

<!-- Da ich JSX verwende -->
<script src="https://unpkg.com/babel-standalone@6/babel.min.js"></script>

<!-- Meine App oder Komponente -->
<script src="src/index.js"></script>

</body>

Wäre das soweit ein (möglicher) und guter Weg? Oder wäre npm run build besser, gleich gut, schlechter? Wenn ja warum?

Gruß ebody

[Raketenwilli]

Aus dem Film:

Ein Weg, dieses zu integrieren, ist:

1. Für die App einen “Starter“ für systemd zu schreiben. (ab „.service-Datei anlegen“). Falls Dein Server noch das alte init benutzt schau in /etc/rc3.d nach... (Das geht aber nur mit Root-Rechten!)
2. Den eigentlichen Webserver (hier den Apache) so zu konfigurieren, dass er den anderen Webserver „befragt“, also als Reverse-Proxy funktioniert:

ProxyPass "/movies/" "http://localhost:3001/movies"
ProxyPassReverse "/movies/" "http://localhost:3001/movies/"

Alternative: (lese im Handbuch nach, ob und wann Du das brauchst…)

<Location "/movies/">
  ProxyPass "http://127.0.0.1:3001/movies/"
  SetEnv force-proxy-request-1.0 1
  SetEnv proxy-nokeepalive 1
</Location>

Das geht freilich auch nur, wenn Du Rechte hast. Ansonsten frage mal Deinen Hoster, wie es bei ihm geht.

[Raketenwilli]

https://www.ionos.com/digitalguide/websites/web-development/nodejs-for-a-website-with-apache-on-ubuntu/

[dedlfix]

Tach!

React ist für die Client-Seite, das läuft im Browser. Dazu muss man nicht zwangsläufig irgendwas auf dem Server starten. Theoretisch reicht es, die mit dem für React üblichen Build-Prozess erstellten Dateien auf einen 08/15-Webserver zu laden. Mit React erstellte Anwendungen können aber mit den in Javascript üblichen Mitteln mit Servern kommunizieren. Was dort läuft ist aber kein React, sondern ein beliebiges für die Serverseite vorgesehes System, beispielsweise PHP oder NodeJS.

dedlfix.

[Random2356]

my-app/
- node_modules/
- public/  
-- index.html
-- favicon.ico 
- src/
-- components/
-- App.css
-- App.js 
-- index.css 
-- index.js
- README.md
- package.json
- .gitignore

Ich würde jetzt nur den /src/ Ordner per FTP hochladen und in der index.js das Ziel Element von root in searchApp ändern:

Das dürfte wahrscheinlich kaum funktionieren, da deine App ja sicherlich auch auf Code aus dem Verzeichnis node_modules zurückgreift.

Mit npm run build kriegst Du alles schön zusammengebaut, kannst das build-Ergebnis einfach in das HTML-Verzeichnis des Webservers kopieren und die so erstellte Seite muss keinen Code von externen Servern nachladen.

[Raketenwilli]

Mit npm run build kriegst Du alles schön zusammengebaut, kannst das build-Ergebnis einfach in das HTML-Verzeichnis des Webservers kopieren und die so erstellte Seite muss keinen Code von externen Servern nachladen.

Kann dann aber auch nicht aus Ressourcen des Servers (Datenbanken e.t.c.) zurückgreifen oder (ohne weiteres) Eingaben an den Server senden. Das heißt: Das Ergebnis ist eine mehr oder weniger statische Webseite mit JS.

Soweit dann zu „App“.

[dedlfix]

Tach!

Mit npm run build kriegst Du alles schön zusammengebaut, kannst das build-Ergebnis einfach in das HTML-Verzeichnis des Webservers kopieren und die so erstellte Seite muss keinen Code von externen Servern nachladen.

Kann dann aber auch nicht aus Ressourcen des Servers (Datenbanken e.t.c.) zurückgreifen oder (ohne weiteres) Eingaben an den Server senden. Das heißt: Das Ergebnis ist eine mehr oder weniger statische Webseite mit JS.

Das geht genauso wie es mit HTML und Javascript möglich ist, sprich zum Beispiel HTTPS-Requests mit fetch(). Webapps sind nichts anderes als HTML/CSS/JS.

dedlfix.

[Raketenwilli]

Tach!

Post!

Mit npm run build kriegst Du alles schön zusammengebaut, kannst das build-Ergebnis einfach in das HTML-Verzeichnis des Webservers kopieren und die so erstellte Seite muss keinen Code von externen Servern nachladen.

Kann dann aber auch nicht aus Ressourcen des Servers (Datenbanken e.t.c.) zurückgreifen oder (ohne weiteres) Eingaben an den Server senden. Das heißt: Das Ergebnis ist eine mehr oder weniger statische Webseite mit JS.

Das geht genauso wie es mit HTML und Javascript möglich ist, sprich zum Beispiel HTTPS-Requests mit fetch(). Webapps sind nichts anderes als HTML/CSS/JS.

Mag ja sein... aber erzeugt denn besagtes npm run build auch die serverseitigen Skripte in anderen Sprachen als JS?

Oder ist es doch nicht ganz so „einfach“ wie oben beschrieben?

Was unterscheidet eigentlich Deinen Satz „Webapps sind nichts anderes als HTML/CSS/JS“ von meiner Aussage „Das heißt: Das Ergebnis ist eine mehr oder weniger statische Webseite mit JS.“

[dedlfix]

Tach!

Mag ja sein... aber erzeugt denn besagtes npm run build auch die serverseitigen Skripte in anderen Sprachen als JS?

Ich kenne React nicht genauer, aber Angular als vergleichbares System. Client und Server sind üblicherweise separate Projekte. Deswegen erzeugt der Build des Client-Projekts normal nicht den Serverteil und umgekehrt. Der Server kann auch in einem ganz anderen Ökosystem entstehen (PHP/C#/Java/...) und seine eigene Vorgehensweise zum Erzeugen seiner Runtime haben.

Oder ist es doch nicht ganz so „einfach“ wie oben beschrieben?

Aus Sicht von React ist der Build-Prozess so einfach wie beschrieben. Wie gesagt, der Serverteil ist unabhängig davon. Er muss nicht einmal vorhanden sein. Die Webapp kann kann selbständig ohne serverseitige Datenhaltung arbeiten. Auch wenn sie ausschließlich fremde WebAPIs anspricht, braucht sie ebenfalls keinen eigenen Serverteil.

Was unterscheidet eigentlich Deinen Satz „Webapps sind nichts anderes als HTML/CSS/JS“ von meiner Aussage „Das heißt: Das Ergebnis ist eine mehr oder weniger statische Webseite mit JS.“

Die ausgelieferten Dateien sind üblicherweise fertig und werden nicht noch am Server zusammengebaut. Das ist statisch aus Sicht des Webserver, man braucht nur einen einfachen Webserver für die Client-App.

Da aber (zumindest ist es bei Angular so) das ausgelieferte HTML lediglich eine einzelne Seite und ein Grundgerüst ist, und der Rest erst durch das Javascript im Client aufgebaut wird, spricht man nicht von einer statischen Website. Beim klassischen "statisch" hat man mehrere HTML-Seiten, die miteinander verlinkt sind, und Javascript fügt meist nur Komfortfunktionalität hinzu. Das läuft idealerweise auch bei abgeschaltetem Javascript. Der Unterschied ist in etwa so wie auf dem Desktop zwischen Textdatei und Programm.

Dass du der WebApp absprichst eine WebApp zu sein, nur weil serverseitig kein Programm läuft, ist also so nicht richtig. Das wäre, wie wenn du einem Progamm für den Desktop absprichst ein Programm zu sein, weil es fertig kompiliert ist und nicht etwa zur Laufzeit vom Basic-Interpreter interpretiert wird.

Das Problem an deiner Antwort war (weswegen sie auch zurecht ein Minus kassiert hat), dass sie zwar zu einer serverseitigen NodeJS-Anwendung passt, nicht aber zu einer clientseitigen mit React.

dedlfix.