You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using ECharts to render data can be trivial sometimes yet still relatively easier, compared with injecting charts into GitHub pages by a browser extension. A major issue we face is that page navigation on GitHub doesn't always behave in the same way, at least in an observer's perspective. Sometimes a page navigation triggers a page reload while sometimes it doesn't. Additionally, forward/back buttons to revisit a page seems to hit some kind of cache and the pages seem to be restored instantly without a network request.
An extension content script runs in an isolated world(it has own variables and cannot access to host page's) but shares the same DOM tree with its host page. So everything we inject to GitHub pages will be a part of the DOM tree and if JavaScript running on GitHub pages chooses to not reload page but instead removes some DOM nodes and replaces them with others(e.g. Code tab → Issue tab), the injected components are also removed. However, the injected components are expected to show themselves again when users navigate back to pages they live, so re-inject code is needed.
But in which point we should re-inject and by which way the process can be as graceful as possible? Please see #548. I give some words there to explain the underpinning technique turbo and I think it's kind of reverse engineering work and by studying how turbo works I feel more sense of certainty.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Meeting
Agenda
1. Metrics
2. Reverse engineer on GitHub
Using ECharts to render data can be trivial sometimes yet still relatively easier, compared with injecting charts into GitHub pages by a browser extension. A major issue we face is that page navigation on GitHub doesn't always behave in the same way, at least in an observer's perspective. Sometimes a page navigation triggers a page reload while sometimes it doesn't. Additionally, forward/back buttons to revisit a page seems to hit some kind of cache and the pages seem to be restored instantly without a network request.
An extension content script runs in an isolated world(it has own variables and cannot access to host page's) but shares the same DOM tree with its host page. So everything we inject to GitHub pages will be a part of the DOM tree and if JavaScript running on GitHub pages chooses to not reload page but instead removes some DOM nodes and replaces them with others(e.g. Code tab → Issue tab), the injected components are also removed. However, the injected components are expected to show themselves again when users navigate back to pages they live, so re-inject code is needed.
But in which point we should re-inject and by which way the process can be as graceful as possible? Please see #548. I give some words there to explain the underpinning technique turbo and I think it's kind of reverse engineering work and by studying how turbo works I feel more sense of certainty.
Beta Was this translation helpful? Give feedback.
All reactions