|
|
|
|
|
|
|
Tausend Fehler drin, aber ich hasse dich trotzdem
|
|
|
|
|
|
|
|
|
|
|
Deine Mutter hatte auch einen Fehler drin.
Ich bin übrigens auch pro Streams. Gepostet beim streamen in den Lokus.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 06.07.2021 12:09]
|
|
|
|
|
|
|
|
|
Entwickelt hier jemand viel mit react? Wollte gerne wissen wie sie es bei Webapps handhaben wenn man in einem tieferen Punkt in der app ist. Zb Website.de/dashboard/projects/23 und dann die Seite neu lädt das nicht nur die Daten des Projekts mit der ID 23 geladen werden sonder auch Daten die in den routen davor on demand geladen wurden und jetzt zusätzlich benötigt werden. Z. B das man sieht wieviel Projekte man hat.
Ich hoffe derjenige der sich angesprochen fühlt weiß was ich miene. 
|
|
|
|
|
|
|
|
|
|
|
Also zumindest bei Ember werden die Hooks der einzelnen Routen von oben nach unten geladen.
Also bei 1/2/3 laufen nacheinander die Hooks von 1, 2 und dann 3. Das muss ja auch so, weil es ja sein kann, dass schon in einem der oberen Hooks festgestellt wird, dass der Nutzer da gar nicht sein soll. Dann kann er redirected werden, noch bevor die tieferen Hooks versuchen, irgendeinen Kram zu laden.
/ Äh, also ich würde jetzt erwarten, dass das, was Du beschreibst, einfach passiert. Bei Ember isses so.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 06.07.2021 21:10]
|
|
|
|
|
|
|
|
|
Ich glaube das ist in ember anders.
Wenn ich alle Projekte auf der /projects Route lade wenn die Komponente gemountet wird dann ist es in einer tieferen Route ja nicht vorhanden weil die Seite für die /projects nie gemountet wurde.
|
|
|
|
|
|
|
|
|
|
|
Das ist aber ganz schön kacka. 
Ist doch klar, dass ich, wenn ich in /route1/route2 rumhänge, will, dass beim Seitenneuaufbau auch der Hook von route1 durchlaufen wird.
/ Aber sorry, dann kann ich wohl nicht weiterhelfen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 06.07.2021 21:48]
|
|
|
|
|
|
|
|
|
Kannst du mir vielleicht Details zu diesen ember hooks geben? Vielleicht läßt sich das ja anders umsetzen.
Aber ja das ist blöd und das ist was mir (neben authentifkation) das Hirn brät
|
|
|
|
|
|
|
|
|
|
|
Hmm, das ist alles Framework, man macht da selbst in der Regel nicht wahnsinnig viel. Der Router ruft halt von oben nach unten (bzw. außen nach innen) ne Reihe von Methoden in den einzelnen Routen auf. Im model "hook" werden die Daten für die Route geladen. Gibt drum rum noch einige andere, die man für verschiedene Sachen nutzen kann. Aber das Prinzip ist immer dasselbe: Es geht von außen nach innen, und wenn irgendwo was schief geht, kann man das nach oben hochreichen, so dass dann z.B. die Elternroute eine Möglichkeit bekommt, einen Fehler beim Laden der Daten in der Kindroute zu handlen.
Vielleicht hilf es Dir, mal den Quelltext vom Ember-Router anzuschauen, wie der das macht, falls Du was ähnliches nachbauen musst. Aber ich kann's mir einfach beim besten Willen nicht vorstellen, dass React das nicht kann - da würde ja praktisch jeder Reload zu Problemen führen?
|
|
|
|
|
|
|
|
|
|
|
mhh.. Ddie frage ist doch warum?
Wenn man /projects/23 aufruft, wieso muss man dann die Daten von /projects haben?
Und wenn man von /projects/23 zu /projects wechselt ist das doch das Gleiche, als wenn man von /dashboard zu /projects wechselt.
(Abgesehen, davon, dass das eigentluich /projects und /project/23 sein müsste und sich dann die Frage erübrigt )
edit: und naja... sonst halt einfach alles Lazyloading machen. Beim 1. Zugriff ohne daten gibts halt ne leere Liste mit nem status:"loading" und irgendwann wechselt das in ne gefüllte Liste :-o
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Noch_ein_Kamel am 06.07.2021 22:06]
|
|
|
|
|
|
|
|
|
Es gibt viele Situationen wo man solche Daten Verzweigungen braucht.
Ich lasse mich von dem ember gedöns inspirieren. Ich habe theoretisch schon eine Idee um eine Art Daten Wasserfall zu ermöglichen.
|
|
|
|
|
|
|
|
|
|
|
Jetzt rein von den URLs her hätte ich auch gesagt, dass dich von dem Parent jetzt gerade nicht mehr allzu viel interessieren dürfte, denn du bist ja gerade beim Child-Knoten.
Sicher dass du nicht eher sowas wie /projects?selected=23 oder sowas willst, spricht dich eigentlich weiter auch im parent-Kontext bewegst?
Ansonsten bin ich bei React erst verzweifelt als sie irgendeine State-Management-Library eingebunden haben, die zwar "conventional" im Namen hatte, aber über irgendwelche Magic-Strings funktionierte. Was eine Kackscheiße.
|
|
|
|
|
|
|
|
|
|
|
Stell dir einfach vor das man in der Detail Ansicht von einem Projekt Personen zu dem Projekt zuweisen kann. Diese Daten der Personen werden aber an einer andern Stelle geladen. Z. B im dashboard wo man nach dem login landet.
react hat Ansich kein state Managment library mit dabei (über flux reden wir nicht).
Es gibt dann ja sowas wie redux oder MobX
Ich habe grad was rumgesucht bezüglich dieser Ember Model Geschichte und sowas hat react einfach nicht. Da wurde ich auf sowas wie ApolloJS hingewiesen .. naja ich setze erstmal die Idee um die mir im kopf rumschwirt, ist aber etwas blöd das man zu diesem tehma nichts findet ...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von X-Tender am 06.07.2021 23:26]
|
|
|
|
|
|
|
|
|
| | Zitat von Noch_ein_Kamel
mhh.. Ddie frage ist doch warum?
Wenn man /projects/23 aufruft, wieso muss man dann die Daten von /projects haben?
Und wenn man von /projects/23 zu /projects wechselt ist das doch das Gleiche, als wenn man von /dashboard zu /projects wechselt.
(Abgesehen, davon, dass das eigentluich /projects und /project/23 sein müsste und sich dann die Frage erübrigt )
edit: und naja... sonst halt einfach alles Lazyloading machen. Beim 1. Zugriff ohne daten gibts halt ne leere Liste mit nem status:"loading" und irgendwann wechselt das in ne gefüllte Liste :-o
| |
Weil in der Elternroute Daten geladen werden können, auf die alle Kindrouten Zugriff brauchen - und die beim Wechsel zwischen Kindrouten dann entsprechend auch nicht wieder angefragt werden müssen.
Daten, die mit den Kindrouten nix zu tun haben, haben da natürlich nix verloren, aber wenn es die gibt, ist wahrscheinlich auch die verwendete Hierarchie nicht sinnig.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von X-Tender
Stell dir einfach vor das man in der Detail Ansicht von einem Projekt Personen zu dem Projekt zuweisen kann. Diese Daten der Personen werden aber an einer andern Stelle geladen. Z. B im dashboard wo man nach dem login landet.
| |
Also entweder kann die übergeordnete Komponente die Daten als Attribut an die Kind-Komponenten weitergeben - oder falls die Detail-Ansicht nicht teil des Dashboards ist, das Laden der Daten davon abkoppeln sodass beide das erledigen können?
|
|
|
|
|
|
|
|
|
|
|
React selbst macht an sich keine Vorgaben was wann bei welcher Route geladen wird. Man legt das selbst fest mit Hilfe der Routing Komponenten und der Verschachtelung der Komponenten. Wenn du die Details-Komponente in die Überblick-Komponente reinschachtelst dann laufen die Hooks von beiden. Kann mir aber nicht vorstellen warum man alle Daten laden sollte wenn man nur eine einzelne Detailansicht anzeigen möchte.
Was mich eher wurmt ist dass häufig State eben nicht nur über die URL abgebildet werden kann. Wenn ich ein mehrstufiges Anmeldeformular habe und der User bei Schritt 2 die F5 Taste drückt dann lande ich je nach URL Schema ggf zurück auf Schritt 1 oder auf Schritt 2. Was mach ich aber mit den bereits eingegeben Daten bevor F5 gedrückt wurde? Persistieren im Browser Local Storage oder irgendwo auf dem Server (falls passende API vorhanden). Da habe ich selbst noch dran zu knabbern. Der Kram den ich gebastelt habe läuft aber vielleicht mach ich das falsch und steuere alles vom Beifahrersitz aus
|
|
|
|
|
|
|
|
|
|
|
|
Ich hatte verstanden, dass er das so gemacht hat? Also Detailseite als Kind der Übersichtsseite. Hätte mich auch echt überrascht, wenn da nicht beide Hooks laufen würden.
|
|
|
|
|
|
|
|
|
|
|
Danmn würde aber der Router immer auf die Übersichtsseite zeigen und die mit der Detail-ID Parametrisieren.
Aber dann gäbs ja das Problem nicht
| | | Was mich eher wurmt ist dass häufig State eben nicht nur über die URL abgebildet werden kann. Wenn ich ein mehrstufiges Anmeldeformular habe und der User bei Schritt 2 die F5 Taste drückt dann lande ich je nach URL Schema ggf zurück auf Schritt 1 oder auf Schritt 2. Was mach ich aber mit den bereits eingegeben Daten bevor F5 gedrückt wurde? Persistieren im Browser Local Storage oder irgendwo auf dem Server (falls passende API vorhanden). Da habe ich selbst noch dran zu knabbern. Der Kram den ich gebastelt habe läuft aber vielleicht mach ich das falsch und steuere alles vom Beifahrersitz aus | |
Zentralisiertes State-Management. Vor 2 Jahren war da Redux state of the art. Ich habs immer manuell gemacht bzw. das basiert alles auf Flux https://github.com/facebook/flux/tree/master/examples/flux-concepts mit einem zentalen Store der den Zustand der App abbildet und dann holen sich die einzelnen Komponenten von da ihre Daten und geändert wird nur über definierte Actions im zentralen Store.
Dann kann man wenn man es denn braucht auch den Store im local-/sessionStorage zwischenspeichern und wenn man F5 drückt wieder daraus laden.
|
|
|
|
|
|
|
|
|
|
|
Und wenn man die URL frisch aufruft ohne jemals da gewesen zu sein dann muss man es ja laden 
Ich benutze Redux immer noch in Verbindung mit "Immer" um die Mutationen vom state zu vermeiden ohne sich zu verrenken.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Noch_ein_Kamel
Danmn würde aber der Router immer auf die Übersichtsseite zeigen und die mit der Detail-ID Parametrisieren.
| |
But why? Das ergibt doch ne furchtbare URL.
Navigation ist Teil der Elternroute, Detailseite ist Kindroute.
/ Das Inhaltsverzeichnis braucht Daten der Elternroute. Die müssen immer geladen werden, wenn eine Kindroute von außerhalb (!) angesteuert wird (also auch Refresh), aber nicht, wenn zwischen Kindrouten gewechselt wird.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 07.07.2021 9:01]
|
|
|
|
|
|
|
|
|
Meine Grundidee (was wahrscheinlich nicht MEIN Idee ist sondern der "Way to go" ist) Das man drauf achten muss das man keine Router macht der alle Routen hällt sondern sie von Komponente zu Komponente weitergibt und dort dann granular geroutet wird. z.b.
DO NOT (Pseudocode):
| |
| Code: |
<Route url="/dashboard" componente="Dashboard" />
<Route url="/dashboard/projects" componente="Projects" />
<Route url="/dashboard/projects/{projectId}" componente="ProjectDetail" /> |
|
Sondern:
App.jsx
| |
| Code: |
<Route url="/dashboard" componente="Dashboard" /> |
|
Dashboard.jsx
| |
| Code: |
<Route url="/dashboard/projects" componente="Projects" /> |
|
Projects.jsx
| |
| Code: |
<Route url="/dashboard/projects/{projectId}" componente="ProjectDetail" />
|
|
In jeder der einzelnen Komponente wird bei componentDidMount die entsprechenden Daten (soweit nicht existent im global store) geladen.
Wenn in der Projects.jsx z.b. keine Projects im store sind (null) dann
1. lade die projekte
2. render solange nichts solange der datensatz für "projekte" null ist. Erst dann wird gerendert wo auch die Route drin ist. Dann checkt er erst (oh es ist ja eine ID mit angehängt, also gehe ich mal in die ProjectDetails).
Dort angekommen hat er 1. alle Projekte (für was auch immer, ist egal) und lädt dann auch via componentDidMount die daten für das Projekt mitder ID XYZ.
Klingt das ansatzweise logisch?
|
|
|
|
|
|
|
|
|
|
|
Glaub schon.
Ist projects denn wirklich eine subroute von dashboard? Und wenn ja, bist Du sicher, dass Du beide getrennt voneinander brauchst?
Also, jetzt nur anhand der URLs würde ich nämlich eher sowas vermuten:
dashboard
projects/xx
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 07.07.2021 11:29]
|
|
|
|
|
|
|
|
|
Ich sehe das auch eher so, dass man
/dashboard
/projects
/projects/{projectId}
trennt
Aber wenn die ProjectDetail das Projekt mit der ID 700 rendern möchte lädt die Projects Komponente alle Projekte? Normalerweise sind doch APIs für Listen paginiert und ggf. per Parameter beliebig sortierbar. Wenn man dann immer alles lädt können sich da doch viele Details anhäufen. Ist es dann nicht effizienter das einzelne Objekt zu laden?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von NI-Xpert
Aber wenn die ProjectDetail das Projekt mit der ID 700 rendern möchte lädt die Projects Komponente alle Projekte? Normalerweise sind doch APIs für Listen paginiert und ggf. per Parameter beliebig sortierbar. Wenn man dann immer alles lädt können sich da doch viele Details anhäufen. Ist es dann nicht effizienter das einzelne Objekt zu laden?
| |
Ja, ich würde dann für die Navigation (wo man pro Record vllt nur 1-2 Felder braucht) halt ne eigene API anbieten. Lazy Loading brauchst Du dann aber wahrscheinlich eh, alleine schon, weil 700 Divs auf einmal ins DOM stecken schon eine schlechte Idee ist. Auf der Webseite, die ich geposted habe, kann sich davon jeder überzeugen.
/ Das sind halt zwei völlig verschiedene Zielstellungen für dieselbe Ressource. Die eine ist es, dem User eine möglichst große Anzahl sehr vereinfachter Repräsentationen der Ressource anzuzeigen (Übersicht, Navigation, Liste, whatever) und die andere ist es, dem User eine einzige, aber beliebig komplexe Repräsentation anzuzeigen. Diese beiden Fälle mit derselben Repräsentation abzubilden ist glaube ich nicht zielführend.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Ameisenfutter am 07.07.2021 14:18]
|
|
|
|
|
|
|
|
|
Richtig, du requestest dir das aus den einzelnen endpoints zusammen, entweder als promise chain im router oder halt auch lazy an punkt xyz zur runtime, z.b. wenn die Dropdown-Menü component von der projekt-Liste im UI öffnet.
Das würde ich halt davon abhängig machen, wie wichtig die Daten für die Erstbedienung der Seite sind und auch wieviel overhead du an der Stelle produzierst.
Du kannst dann den state im local storage cachen und dann ein stale while revalidate (swr) pattern einbauen. Und die api endpoints kannst du ja auch cachen.
Was du wann und wofür nutzt, ist halt komplette Einzelfallentscheidung.
Wenn deine App nicht öffentlich frequentiert ist und es da einfach auch nicht heiß her geht, brauchst du da nicht overengineeren und ziehst dir einfach alles naiv im router.
Falls du einfache Lösungen suchst is Next/Nuxt oder ein derivat als framework für den Bedarf gut aufgestellt, diese Frameworks geben für die router configuration ja Strukturen vor.
Oder du baust dir einen fetcherservice für diverse views - und da definierst du halt welche endpoints genau du fetchen willst.
Wenn du dir Gedanken ums network budget machen musst oder die App an der Stelle nicht performant genug lüppt, kannst du das immer noch optimieren.
Aber API endpoint ist halt != view url.
Wenn dir die view auf /dashboard/projects/project/700 die projects mitladen/nachladen soll, pingst du mehrere endpoints an - dafür musst du ja nicht direkt die api selbst überladen -> die /dashboard/projects/project/700 route sollte halt nur den view state ansteuern und nicht 1:1 den endpoint wieder spiegeln. Einem Service sagst du dann „gib mir alle Daten für project/details auf project 700 und der service klaubert es dir aus dem Cache und von den endpoints api/dashboard/$id, api/projects und api/projects/$project id zusammen dann lutscht du es als State in deine components.
Oder du spielst mit graphql rum, gibt auch graphql Abstraktionen für rest-apis.
Whatever floats your boat.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Tenz am 08.07.2021 11:10]
|
|
|
|
|
|
|
|
|
Will das Thema auch nicht weiter vertiefen aber falls es jemanden interresiert. Meine Theorie funktioniert in der Praxis bestens.
Im Grunde Routen Komponenten/Routenweise verschachteln, keine monolith router bauen. Und dann in der Route entsprchend schauen "Habe ich alle Daten um möglicherweise den nutzer weiter zu routen, dann render ich z.b. die <Route> komponenten. Sonnst daten laden (wie auch immer). Und dann die <Route> rendern, dann geht man wenn benötigt ein level tiefer und da geht das spiel von vorne los.
So hat man einen schönen Daten/Routen Wasserfall.
Falls jemand interesse am code hat:
https://github.com/X-Tender/react-auth/tree/test/nested-data-loading
Ab dem commit "Add Redux packages"..
|
|
|
|
|
|
|
|
|
|
|
|
Ich hab das jedenfalls mal zum Anlass gebunden, in meiner Navigation die 200+ Buttons lazy zu rendern. Macht schon nen Unterschied.
|
|
|
|
|
|
|
|
|
|
|
Cool dass du zeigst was du machst. Wo genau hast du denn den Waterfall implementiert, also welcher Teil ist bei dir dafür zuständig, dass er Projects als dependencies für Projects fetched und dann erst das Project selbst? So wie ich das lese, passiert das ja nicht über den Router bei dir sondern in der pages/Projects.just über den useselector auf den Store der dann erst mal den Dispatch feuert — das passiert ja gleichzeitig mit dem anderen dispatcher, bzw. halt nur nicht weil er vorher rendert. Also in sofern isses ja fast unabhängiges lazy loading, bzw. schon eng gekuppelt an die konkrete logik deiner Projects page und kein Waterfall.
Halte ich auch durchaus für den richtigen Ansatz, ist im Prinzip das lazy loading von components.
Ich verchecke da aber deinen waterfall und die Steuerung davon rein über routes, ist das schon in den commits dabei?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Tenz am 11.07.2021 21:41]
|
|
|
|
|
|
|
|
|
| | Zitat von Tenz
Cool dass du zeigst was du machst. Wo genau hast du denn den Waterfall implementiert, also welcher Teil ist bei dir dafür zuständig, dass er Projects als dependencies für Projects fetched und dann erst das Project selbst? So wie ich das lese, passiert das ja nicht über den Router bei dir sondern in der pages/Projects.just über den useselector auf den Store der dann erst mal den Dispatch feuert — das passiert ja gleichzeitig mit dem anderen dispatcher, bzw. halt nur nicht weil er vorher rendert. Also in sofern isses ja fast unabhängiges lazy loading, bzw. schon eng gekuppelt an die konkrete logik deiner Projects page und kein Waterfall.
Halte ich auch durchaus für den richtigen Ansatz, ist im Prinzip das lazy loading von components.
Ich verchecke da aber deinen waterfall und die Steuerung davon rein über routes, ist das schon in den commits dabei?
| |
In der App.jsx ist nur Projects drin:
<Route component={Projects} path="/projects" />
In der Projects.jsx werden erst die Projekte geladen und solange die noch nicht geladen sind wird nur "LOADING" angezeigt:
https://github.com/X-Tender/react-auth/blob/test/nested-data-loading/src/jsx/App/pages/Projects.jsx#L32
Erst wenn das geschehen ist wird die Project Route in Projects.jsx eingebunden, die dann wiederrum über getProject das Projekt lädt und solange "loading project" anzeigt:
https://github.com/X-Tender/react-auth/blob/test/nested-data-loading/src/jsx/App/pages/Project.jsx#L32
|
|
|
|
|
|
|
|
|
|
|
|
ja wie gesagt, das passiert ja über den useselector auf den state der sich dann die daten holt, aber hat mit der aufteilung der route und mit childroutes an für sich ja nichts gemein - deshalb frag ich
|
|
|
|
|
|
|
|
|
|
|
Jo, besser hätte ich es auch nicht wiedergeben können. (vom Kamel, blöder zwischenposter  )
Es wird der Route entlang immer geladen (wenn benötigt). Das würde dann auch funktionieren wenn die Route noch länger wäre und auf dem Weg dahin noch mehr Daten gebraucht werden.
Componenten werden nicht lazy geloaded. Da würde das Konstrukt anders aussehen, würde aber am sonstigen Rest nichts ändern.
Ist jetzt nicht Rocket science aber ich hatte bislang Probleme dieses Problem zu lösen, dem ist jetzt nicht mehr so.
Ist natürlich auch nur ein Ansatz unter vielen denke ich. Interessant wäre ob jemand eine andere Idee hätte.
/Nachtrag wegen zwischenposter.
Ja doch das hat schon was mit dem aufteilen der Route zu tun. Weil ich nicht direkt zu /projects/project/1 gehe sondern erst zu /projects werden die Daten zuerst geladen bevor ich ihn weiter zu /project/1 gehen lasse weil ich dort die Daten von /projects brauche. Dh wenn ich auf der Detail Seite ja bin ich nach einem Page reload sicher sein kann das ich in der Route alle Daten habe als ob ich von / auf einzeln durchklicken würde.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von X-Tender am 11.07.2021 22:07]
|
|
|
|
|
|
| Thema: Software-Entwicklung 0 ( new SammelThread() ) |
![AUP [smith] 29.07.2010](./avatare/upload/U1066026--zeratul.png)
