Only Rerender "DAO Connected" Components

Offen

#3 erstellt am 27.3.2019 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 25/100

Issue-Typ: Refactoring
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: react, typescript
Bereich: frontend, performance

Rechercherichtung

Beginne mit der Überprüfung des für Arc.Config, DAO und DAO.Data beschriebenen Verhaltens der Komponentenabonnements, insbesondere wie Zustandsaktualisierungen von DAO erneute Renderings auslösen. Erfasse die vorgeschlagenen Metriken, bevor du entscheidest, ob die Optimierung weiterverfolgt werden soll; als erledigt gilt die Festlegung eines gemessenen, abgestimmten Umfangs für erneute Renderings ausschließlich von mit DAO verbundenen Komponenten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

hi-pri perf-enhancement

Only rerender components that are "DAO Connected".

This can be done through supporting a subscription model, where components that depend on additional contextual information (ex: , ).

For example, consider...

<Arc config={new Config("web3provider", "graphqlprovider")}>
  <View1 />
  <DAO address={"0x1234"}>
    <View2 />
    <DAO.Data>
      {data => (
        <View3 value={data.value} />
      )}
    </DAO.Data>
  </DAO>
</Arc>

Ideally, if Arc.Config's web3 provider changes, View1 & 2 shouldn't have to rerender, but View3 should because the data may be different. This can be partially achieved if DAO connect's the Arc.Config's subscriber list, which will cause it to be told to rerender if the config ever changes, but this only causes View1 to not be rendered. View2 would still be rendered because currently the data is stored within the Component's state (the DAO's state), which would cause View2 to still be rendered.

Going to leave this here for now, as it'll be interesting to come back to this after some metrics have been gathered, as I feel this may be premature optimization.

Vorherrschende Sprache: TypeScript
Sterne: 21
Forks: 9
PR-Merge-Kennzahlen: Keine gemergten PRs in 30 T.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus dOrgTech/arc.react

Bulk Context Consumption Offen

devexp-enhancement feature good first issue help wanted

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100

dOrgTech/arc.react#63 · Erstellt am 22.4.2020
Demo Application & Tutorial Offen

hi-pri

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100

dOrgTech/arc.react#55 · 20 Kommentare · Erstellt am 10.4.2020
Use Immutable.JS For Log Data Offen

low-pri

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100

dOrgTech/arc.react#43 · Erstellt am 28.6.2019
Complex multi-step queries Offen

low-pri

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 15/100

dOrgTech/arc.react#42 · Erstellt am 04.6.2019
[Storybook] Component Views - Drop Down Offen

low-pri quality-assurance ux-enhancement

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100

dOrgTech/arc.react#37 · Erstellt am 26.5.2019

Alle Issues in dOrgTech/arc.react