Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vue3 Nuxt3 #41

Open
wants to merge 24 commits into
base: main
Choose a base branch
from
Open

Vue3 Nuxt3 #41

wants to merge 24 commits into from

Conversation

albertlast
Copy link
Contributor

@albertlast albertlast commented Dec 20, 2023

Vue2 ist eol
daher mein versuch das projekt auf vue3 hochzuheben.

vue2 -> vue3
nuxt2 -> nuxt3
bootstrap -> quasar
axios -> $fetch (ofetch)
jest -> vitest

function code csj nach esm überführt
backend (relay) wird von nuxt3 übernommen -> backend fällt weg

  • osm
  • pvgis

sind jetzt zwei getrennte endpunkte (damit auf ui seite ich weiß welches format zurück kommt)

+typescript an einigen stellen zwecks vereinfacherung der programmierung

Not fully working
@nick81nrw nick81nrw marked this pull request as ready for review December 20, 2023 08:24
@albertlast
Copy link
Contributor Author

also der pr ist noch nicht lauffähig, deswegen hatte ich ihn auf draft gesetzt

@mayrstefan
Copy link
Contributor

backend (relay) wird von nuxt3 übernommen -> backend fällt weg

D.h. die neue Anwendung kann nicht mehr statisch kompiliert werden, oder?

@albertlast
Copy link
Contributor Author

statisch kompiliert kenne ich nur in kontext von ssg,
daher verstehe ich die frage nicht.

@albertlast
Copy link
Contributor Author

albertlast commented Dec 22, 2023

vuetify wurde mir zu groß von der anwendung,
daher auf quasar gewechselt.

@albertlast
Copy link
Contributor Author

albertlast commented Dec 23, 2023

Da die test zuvor nicht sauber durchgelaufen sind,
war das ziel auf gleichen schiefenstand raus zu kommen,
wo das projekt gerade ist.

 Test Files  1 failed | 3 passed | 1 skipped (5)
      Tests  14 failed | 23 passed | 12 skipped (49)
   Start at  08:15:14
   Duration  1.81s (transform 1.06s, setup 78ms, collect 1.99s, tests 402ms, environment 1ms, prepare 468ms)

@albertlast
Copy link
Contributor Author

backend (relay) wird von nuxt3 übernommen -> backend fällt weg

D.h. die neue Anwendung kann nicht mehr statisch kompiliert werden, oder?

hab in der zwischen zeit versucht zu verstehen was dein frage bedeutet,
https://nuxt.com/docs/getting-started/deployment#static-hosting
verstehe ich schon so das es geht.

npm run generate

erzeugt zumindest die html seite wo dann das js eingebettet ist.
wie es dann mit backend call und cors aussieht bin ich aber gerade überfragt.

@albertlast
Copy link
Contributor Author

Bin ansich nicht mehr weit vom finalen ziel technisch es umzusetzen,
frage wäre ob ich nun versuche es gleich auszusehen zu lassen oder
in ein anderen pr um das thema man sich kümmert? @nick81nrw

@mayrstefan
Copy link
Contributor

wie es dann mit backend call und cors aussieht bin ich aber gerade überfragt.

Wir haben in der Anwendung zwei Calls die durch das Backend geschleust werden:

  1. Geocoding-API von OpenStreetMap um eine Adresse in Geokoordinaten umzuwandeln
  2. PVGIS-API

Das ganze hat auch zwei verschiedene Aspekte:

  1. Verschleierung der IP-Adresse des Nutzers. Dadurch leakt man keine IP an Drittanbieter (und IP-Adressen gelten als personenbezogene Daten). Der Drittanbieter sieht nur die IP des PVTool-Betreibers
  2. Umgeht das Problem mit CORS. Man hat selber in der Hand welchen Websites man den Zugriff erlaubt.

Wenn man sich die beiden Schnittstellen anschaut muss man beide Aspekte betrachten. Würde man die Schnittstellen direkt aus dem Browser per XHR abrufen sieht es wie folgt aus:

API Datenschutz CORS
OSM ✔️
PVGIS

Die OSM-API würde den Zugriff zulassen (dort ist * erlaubt). Man findet auf https://joint-research-centre.ec.europa.eu/photovoltaic-geographical-information-system-pvgis/getting-started-pvgis/api-non-interactive-service_en zu CORS folgende Information:

Warning: access to PVGIS APIs via AJAX is not allowed. Please, do not ask for changes in our CORS policy since these requests will be rejected by the system administrators.

Auf der Website befindet sich noch ein anderer Hinweis der nun allerdings zum Nachteil wird wenn wir die Requests durch den API-Proxy schleusen:

API calls have a rate limit of 30 calls/second per IP address. If you exceed this threshold, the service will refuse your call and return a "429 - Too Many Requests" HTTP status.

Aber das ist halt leider unausweichlich für diese API. Wäre noch ein cooles Feature für das PVTool wenn der Response Code vom Rate-Limit auch an die Client-Anwendung durchgereicht und verstanden wird.

@albertlast
Copy link
Contributor Author

albertlast commented Dec 23, 2023

wie es dann mit backend call und cors aussieht bin ich aber gerade überfragt.

Wir haben in der Anwendung zwei Calls die durch das Backend geschleust werden:

1. Geocoding-API von OpenStreetMap um eine Adresse in Geokoordinaten umzuwandeln

2. PVGIS-API

Das ganze hat auch zwei verschiedene Aspekte:

1. Verschleierung der IP-Adresse des Nutzers. Dadurch leakt man keine IP an Drittanbieter (und IP-Adressen gelten als personenbezogene Daten). Der Drittanbieter sieht nur die IP des PVTool-Betreibers

2. Umgeht das Problem mit CORS. Man hat selber in der Hand welchen Websites man den Zugriff erlaubt.

Wenn man sich die beiden Schnittstellen anschaut muss man beide Aspekte betrachten. Würde man die Schnittstellen direkt aus dem Browser per XHR abrufen sieht es wie folgt aus:
API Datenschutz CORS
OSM ❌ ✔️
PVGIS ❌ ❌

Die OSM-API würde den Zugriff zulassen (dort ist * erlaubt). Man findet auf https://joint-research-centre.ec.europa.eu/photovoltaic-geographical-information-system-pvgis/getting-started-pvgis/api-non-interactive-service_en zu CORS folgende Information:

Warning: access to PVGIS APIs via AJAX is not allowed. Please, do not ask for changes in our CORS policy since these requests will be rejected by the system administrators.

Auf der Website befindet sich noch ein anderer Hinweis der nun allerdings zum Nachteil wird wenn wir die Requests durch den API-Proxy schleusen:

API calls have a rate limit of 30 calls/second per IP address. If you exceed this threshold, the service will refuse your call and return a "429 - Too Many Requests" HTTP status.

Aber das ist halt leider unausweichlich für diese API. Wäre noch ein cooles Feature für das PVTool wenn der Response Code vom Rate-Limit auch an die Client-Anwendung durchgereicht und verstanden wird.

schon klar und auch gar nicht gegenstand der frage,
ich rede hier von cors zwischen pvtool frontend und backend.

das backend ist ja als solches vorhanden:
https://github.com/nick81nrw/PVTools/pull/41/files#diff-f3da8376ae9c6b07e5278efe113f36c2659592cb2e96253ef35f2fd5d8469868
https://github.com/nick81nrw/PVTools/pull/41/files#diff-cabf3eeff1f05a80d20e831b132f14093fd06d3ea2fc40cc9ac20ebd11eb53dd

@mayrstefan
Copy link
Contributor

backend (relay) wird von nuxt3 übernommen -> backend fällt weg

D.h. die neue Anwendung kann nicht mehr statisch kompiliert werden, oder?

hab in der zwischen zeit versucht zu verstehen was dein frage bedeutet, https://nuxt.com/docs/getting-started/deployment#static-hosting verstehe ich schon so das es geht.

npm run generate

erzeugt zumindest die html seite wo dann das js eingebettet ist. wie es dann mit backend call und cors aussieht bin ich aber gerade überfragt.

Genau das wollte ich mir heute mal anschauen. Wenn ich das auf deinem Branch probiere funktioniert das aber leider nicht:

ERROR  [nitro] [unhandledRejection] Cannot read properties of undefined (reading 'getSSRProps')
 at ssrGetDirectiveProps (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:215:40)
 at .nuxt/prerender/chunks/app/_nuxt/index2-3fc4c016.mjs:12120:38
 at renderComponentSubTree (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:425:9)
 at renderComponentVNode (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:371:12)
 at renderVNode (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:485:14)
 at renderComponentSubTree (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:440:7)
 at renderComponentVNode (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:371:12)
 at renderVNode (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:485:14)
 at renderVNode (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:489:9)
 at renderComponentSubTree (node_modules/@vue/server-renderer/dist/server-renderer.cjs.prod.js:440:7)

Setzt man in der nuxt.config.ts dann ssr: false wird es interessant:

  • es werden zwar statische Dateien generiert aber die Webanwendung zeigt einen 404 statt der Hauptanwendung (Impressum funktioniert aber beispielsweise)
  • verwendet man NODE_ENV="production" um die WARN-Nachricht zu vermeiden hat man ein Problem mit dem npm install. Es wird dann kein nuxt gefunden.

@albertlast
Copy link
Contributor Author

Die error message hab ich bei mir auch,
scheint aber kein produktiven einfluss zu habem.

@albertlast
Copy link
Contributor Author

Wenn die anwendung nicht im root liegt:
localhost/
sondern irgendwo tiefer müsste man in der nuxt config im app part the baseURL anpassen.
localhost/test/pv ->

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  ssr: false,
  modules: ['nuxt-quasar-ui', '@nuxt/test-utils/module', 'nuxt-gtag'],
  app: {
    head: {
      title: 'PVTool @AkkuDoktor - Berechne die Größe deines Speichers selbst',
      htmlAttrs: {
        lang: 'de',
      },
      meta: [
        { charset: 'utf-8' },
        { name: 'viewport', content: 'width=device-width, initial-scale=1' },
        { hid: 'description', name: 'description', content: '' },
        { name: 'format-detection', content: 'telephone=no' },
      ],
      link: [{ rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' }],
    },
    baseURL: '/test/pv/',
  },
  gtag: {
    id: process.env.GOOGLE_ANALYTICS_ID,
    initialConsent: false,
  },
  devtools: { enabled: true },
})

@mayrstefan
Copy link
Contributor

@albertlast irgendwas mache ich da noch falsch. Selbst mit deiner Musterkonfiguration und baseURL: '/', bekomme ich die statische Version nicht generiert:

#12 [builder 4/5] RUN npm ci &&     npm run generate
#12 26.26
#12 26.26 > postinstall
#12 26.26 > nuxt prepare
#12 26.26
#12 29.80
#12 29.80  ERROR  Error while requiring module nuxt-quasar-ui: Error: Cannot find module '/app/nuxt-quasar-ui'
#12 29.80 Require stack:
#12 29.80 - /app/index.js
#12 29.80
#12 29.81
#12 29.81  ERROR  Cannot find module '/app/nuxt-quasar-ui'
#12 29.81 Require stack:
#12 29.81 - /app/index.js
#12 29.81
#12 29.81   Require stack:
#12 29.81   - index.js
#12 29.81   at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
#12 29.81   at Function.resolve (node:internal/modules/helpers:187:19)
#12 29.81   at Function._resolve [as resolve] (node_modules/jiti/dist/jiti.js:1:251148)
#12 29.81   at resolveModule (node_modules/@nuxt/kit/dist/index.mjs:2239:29)
#12 29.81   at requireModule (node_modules/@nuxt/kit/dist/index.mjs:2244:24)
#12 29.81   at loadNuxtModuleInstance (node_modules/@nuxt/kit/dist/index.mjs:2472:90)
#12 29.81   at async installModule (node_modules/@nuxt/kit/dist/index.mjs:2438:47)
#12 29.81   at async initNuxt (node_modules/nuxt/dist/index.mjs:3702:7)
#12 29.81   at async loadNuxt (node_modules/nuxt/dist/index.mjs:3789:5)
#12 29.81   at async loadNuxt (node_modules/@nuxt/kit/dist/index.mjs:2584:19)
#12 29.81   at async Object.run (node_modules/nuxi/dist/chunks/prepare.mjs:56:18)
#12 29.81   at async runCommand$1 (node_modules/nuxi/dist/shared/nuxi.4fde776c.mjs:1648:16)
#12 29.81   at async runCommand$1 (node_modules/nuxi/dist/shared/nuxi.4fde776c.mjs:1639:11)
#12 29.81   at async runMain$1 (node_modules/nuxi/dist/shared/nuxi.4fde776c.mjs:1773:7)

@albertlast
Copy link
Contributor Author

@mayrstefan
also ich hab heute mal ins docker geschaut,
nuxt.config.ts sieht so aus:

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  ssr: false,
  modules: ['nuxt-quasar-ui', '@nuxt/test-utils/module', 'nuxt-gtag'],
  app: {
    head: {
      title: 'PVTool @AkkuDoktor - Berechne die Größe deines Speichers selbst',
      htmlAttrs: {
        lang: 'de',
      },
      meta: [
        { charset: 'utf-8' },
        { name: 'viewport', content: 'width=device-width, initial-scale=1' },
        { hid: 'description', name: 'description', content: '' },
        { name: 'format-detection', content: 'telephone=no' },
      ],
      link: [{ rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' }],
    },
    baseURL: '/',
  },
  gtag: {
    id: process.env.GOOGLE_ANALYTICS_ID,
    initialConsent: false,
  },
  devtools: { enabled: true },
})

dockerfile

FROM node:21.4.0-alpine3.19 AS builder
ARG APP_URL="localhost:8082"
ARG GOOGLE_ANALYTICS_ID
ARG NODE_ENV="development"
ENV APP_URL=${APP_URL}
ENV GOOGLE_ANALYTICS_ID=${GOOGLE_ANALYTICS_ID}
ENV NODE_ENV=${NODE_ENV}
WORKDIR /app
COPY . .
RUN npm ci && \
    npm run generate
FROM nginxinc/nginx-unprivileged:stable-alpine3.18
COPY --from=builder /app/.output/public /usr/share/nginx/html
EXPOSE 8080

hab es dann mittels den befehl gebaut:

docker build --tag 'pv_tool_new' .

kammen irgendwelche warning hoch und
dann mittels:

docker run -dp 8080:8080 --detach 'pv_tool_new'

gestartet und dann konnte ich die anwendung unter localhost:8080 erreichen,
backend funktioniert hier noch nicht,
weil es noch nicht gestartet ist in dem fall.

@mayrstefan
Copy link
Contributor

Ich musste bei mir noch drei Pakete in der Package.json ergänzen damit es funktioniert hat:

  • @nuxt/test-utils
  • nuxt-quasar-ui
  • nuxt-gtag

Erst als diese Module installiert waren konnte ich die Anwendung bauen.
@albertlast Kann es sein, dass bei dir durch ein vorheriges bauen der node_modules Ordner im Source-Verzeichnis vorhanden ist und in das Docker-Image kopiert wird? Dann sind die Module schon da und müssen nicht erst durch npm installiert werden. Kannst du die Anpassungen an den Package*-Dateien, der nuxt.config.ts und das Dockerfile in deinen Branch übernehmen? Dann müsste es sich wie das alte Frontend bauen lassen.

@albertlast
Copy link
Contributor Author

wenn du hier in github files rein schaust (/pvtools/package.json),
siehst du das die package bereits teil der package.json sind,
daher muss ich vermuten das bei deiner lokalen kopie irgendwas schief gelaufen ist.

@albertlast
Copy link
Contributor Author

Welche idee steckt hier hinter eigentlich,
dass die infrastruktur so komplisiert ist?
Man könnte es halt technisch gesehe nauf ein docker in dem nodejs läuft runter dampfen.

@stevleibelt
Copy link

@albertlast

Ich habe die Konversation gelesen und hoffentlich alles wichtige verstanden.
Im Projektverzeichnis liegt eine docker-compose.yml.template. Diese kannst du nutzen um den ganzen Stack (Frontend/Backend) zu starten, statt nur ein Docker-Container zu haben (und ich hoffe, ich hab das Projekt richtig verstanden).

Probiere mal docker compose up --build -d als Kommando aus. Damit baust du die Container (--build), startest alle Container (up) und packst den Stack in den Hintergrund (-d), so dass du die Shell weiter nutzen kannst.

Wenn dich die Logs interessieren, feuerst du hinterher ein docker compose logs -f ab.

@albertlast
Copy link
Contributor Author

Joa danke,
aber beantwortet halt meine Frage nicht,
wieso diese hohe komplexität.
Ein docker container würde doch auch reichen?

@mayrstefan
Copy link
Contributor

@albertlast Entschuldigung. Jetzt sehe ich erst meinen Fehler. Das Verzeichnis in dem ich es ausprobiert habe war ein clone von https://github.com/nick81nrw/PVTools/tree/vue3/ anstatt https://github.com/albertlast/PVTools/tree/vue3syntax - das ist leider nur ein Zwischenstand von deinem Branch. Aus deinem Branch kann ich den Docker-Container dann bauen.

Was aber nicht sauber funktioniert ist die Anwendung wie vorher als statisches HTML zu bauen. Da ist irgendwie das Styling kaputt. Außerdem werden die Backend-Calls gegen /api/osm bzw. /api/pvgis gemacht und es gibt einen 404 not found. D.h. die Vue3-Anwendung muss in dieser Form zwangsweise in einem Node-Prozess laufen. Das bringt uns wieder zu der Frage der Anwendungsarchitektur zurück: soll die Trennung zwischen Backend und Frontend aufrecht erhalten bleiben oder nicht.

@stevleibelt
Copy link

Ein docker container würde doch auch reichen?

Beim Thema Frontend und Backend scheint es auf dem ersten Blick so zu sein, da beide Container node:21.4.0-alpine3.19 nutzen.
Den Proxy-Container will man nicht von einer Dockerfile bauen, da man den nicht selbst betreuen möchte.
Beim Thema Frontend und Backend erachte ich die zwei Dockerfiles als sinnvoll, da man so jeden Teilbereich separat betreuen/austauschen kann.

Wer weiß, eventuell wird das Backend mal durch eine fastapi getauscht. Das geht mit der jetzigen dockercompose.yml recht einfach, da man sieht welcher Bereich welche Abhängigkeiten hat.

Anders herum gefragt, warum ist es dir so wichtig? Ob du nun docker up oder docker compose up aufrufst ist doch irrelevant.
An @mayrstefan und @albertlast als Frage gestellt.
Was würdet ihr wie umbauen wenn ihr gleichzeitig eine Trennung der Pakete von Frontend und Backend erhalten wollt?

Das Ziel der Backendcalls wird aktuell in der index.vue eingestellt.
/relay konnte ich in den geänderten Dateien nicht finden. Das könnte der Grund sein, warum die Backendcalls gegen /api/[osm|pvgis] geworfen werden.

Besten Gruß,
Stev

@albertlast
Copy link
Contributor Author

Das die backend calls gegen api gehen ist wie gesagt gewollt,
da ich davon ausgehe das die wenigsten hier hardcore programmierer sind und
deswegen der konfor gewinn gut ist, um das programmieren einfacherer fällt.

zur zeit hab ich ein stand erreicht,
der backend und frontend docker bauen lässt aber der composer build schlägt im frontend fehl.

man beachte das alle drei sachen (frontend, backend und composer) im pvtools ordner sind und
daher nicht das im root benutzen.

@stevleibelt
Copy link

@albertlast Was ist denn die aktuelle Fehlermeldung im beim Bauen vom Frontend?

@albertlast
Copy link
Contributor Author

Beim Thema Frontend und Backend scheint es auf dem ersten Blick so zu sein, da beide Container node:21.4.0-alpine3.19 nutzen. Den Proxy-Container will man nicht von einer Dockerfile bauen, da man den nicht selbst betreuen möchte. Beim Thema Frontend und Backend erachte ich die zwei Dockerfiles als sinnvoll, da man so jeden Teilbereich separat betreuen/austauschen kann.

Wer weiß, eventuell wird das Backend mal durch eine fastapi getauscht. Das geht mit der jetzigen dockercompose.yml recht einfach, da man sieht welcher Bereich welche Abhängigkeiten hat.

Anders herum gefragt, warum ist es dir so wichtig? Ob du nun docker up oder docker compose up aufrufst ist doch irrelevant. An @mayrstefan und @albertlast als Frage gestellt. Was würdet ihr wie umbauen wenn ihr gleichzeitig eine Trennung der Pakete von Frontend und Backend erhalten wollt?

In meiner persöhnliche Warnehmung ist Docker bereits ein zu komplexe lösung für das Problem,
hier dann noch eine trennung zwischen frontend und backend erzwingen für eine funktion die zur zeit nicht benötigt wird,
ist halt nur noch ein weitere komplexität steigerung für ein problem das es nicht benötigt,
daher die frage.

@albertlast
Copy link
Contributor Author

@albertlast Was ist denn die aktuelle Fehlermeldung im beim Bauen vom Frontend?

 => ERROR [frontend builder 4/4] RUN npm ci &&     npm run generate                                                                                                                                                                                                                                              21.8s 
------
 > [frontend builder 4/4] RUN npm ci &&     npm run generate:
21.32
21.32 > postinstall
21.32 > nuxt prepare
21.32
21.32 sh: nuxt: not found
21.32 npm notice
21.32 npm notice New patch version of npm available! 10.2.4 -> 10.2.5
21.32 npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.2.5>
21.32 npm notice Run `npm install -g [email protected]` to update!
21.32 npm notice
21.32 npm ERR! code 127
21.32 npm ERR! path /app
21.32 npm ERR! command failed
21.32 npm ERR! command sh -c nuxt prepare
21.33
21.33 npm ERR! A complete log of this run can be found in: /root/.npm/_logs/2024-01-04T07_09_12_171Z-debug-0.log
------
failed to solve: process "/bin/sh -c npm ci &&     npm run generate" did not complete successfully: exit code: 127

wenn ich den docker direkt baue läuft er durch

@stevleibelt
Copy link

In deinem Branch gibt es noch ein pvtoolsOld. In deinem pvtools gibt es eine Readme.md aber keinen Hinweis wie du den docker container baust.

Schaue ich mir Dockerfile.frontend unter pvtools an, sehe ich dort, dass du alles vom Verzeichnis pvtools in den Container kopierst (COPY . .).
Während es im originalen pvtools eine package.json gibt, fehlt die bei dir.
Kurzum npm ci kann nichts installieren, da es nicht weiß was es machen soll.
Wie baust du deinen Dockercontainer?

@albertlast
Copy link
Contributor Author

albertlast commented Jan 4, 2024

klar gibt es eine package.json in pvtools bei mir: https://github.com/nick81nrw/PVTools/pull/41/files#diff-5858518939b6f4929654e2a6fe4ffc812a0424c4e4d108369b9407080995c647
build command ist docker compose up --build -d

@albertlast
Copy link
Contributor Author

so habs wieder zum laufen bekommen,
aufgrund der komplexen vorgabe gibt es jetzt drei betriebsmodi:

  • 3 docker (frontend, backend, proxy)
    frontend ist statische nginx content
    backend läuft eine vollständige nodejs setup aber man kommt nur auf den api
    proxy davor, verteilt anfragen zwischen backend und frontend,
    somit verhindert es auch den zugriff auf frontend daten im backend
  • 1 docker (backend)
    da backend komplettes projekt umfang befindet,
    kann man es ihn auch einfach allein betreiben und somit läuft frontend und backend auf einen docker
  • pure nodejs
    somit kann man auch produtiv version halt auch direkt in eine nodejs umgebung laufen lassen

ungetestet aber edge side rendering sollte gehen: https://nuxt.com/docs/guide/concepts/rendering#edge-side-rendering

@stevleibelt
Copy link

@albertlast Schön, dass du alles zum Laufen bekommen hast.

Um mich zu erklären (warum ich die package.json nicht gefunden habe) ... ich habe mich auf dem Strukturbaum auf der linken Seite verlassen:

image

Besten Gruß,
Stev

@albertlast
Copy link
Contributor Author

die frage die halt noch offen ist,
wie weit soll ich mit dem pr und finalen design gehen?
würde halt ggf. das in einem eignen pr auslagern und schauen das technisch soweit der pr passend ist.

@albertlast
Copy link
Contributor Author

@nick81nrw ich warte hier noch auf eine antwort von dir.

@albertlast
Copy link
Contributor Author

technisch ist wie gesagt migrierung fertig, styling könnte noch notwendig sein,
aber das wäre aus meiner sicht ein eigenständiges thema.

@stevleibelt
Copy link

@albertlast schade, dass @nick81nrw gerade wenig Zeit hat (ihm sei es gegönnt und er wird Gründe haben).

Leider musst du dich so wohl noch in Geduld üben.

@nick81nrw
Copy link
Owner

Ich muss mich entschuldigen für die späte Rückmeldung. Krankheit und viel Arbeit kamen dazwischen. Ich gehe die PRs jetzt durch.

@albertlast
Copy link
Contributor Author

hab pr noch mal auf aktuellen stand gebracht

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants