ChromeDevTools / debugger-protocol-viewer

DevTools Protocol API docs—its domains, methods, and events
https://chromedevtools.github.io/devtools-protocol/
Other
862 stars 173 forks source link

Use eleventy to statically generate protocol docs #130

Closed TimvdLippe closed 4 years ago

TimvdLippe commented 4 years ago

This updates the protocol viewer to use Eleventy to statically generate the docs. Since we don't have any actual interactive elements, the usage of web components made little sense for these parts. The search functionality remain web components, as these are by nature dynamic.

It has been a lot of tweaking and the commit history shows the overall process. However, for reviewing I suggest locally building and checking out the output on http://localhost:8000/devtools-protocol/

E.g. npm i && npm run build && open http://localhost:8000/devtools-protocol/

Some features:

  1. Statically generate, achieving 100 on LightHouse performance
  2. Removed a lot of unnecessary JavaScript and significantly reduced the overall size of the website
  3. Use flex-grid for parameters section for improved responsiveness (woohoo!)
  4. Rewrite search components to use lit instead of Polymer
  5. Fix references to hashes. E.g. http://localhost:8000/devtools-protocol/tot/Profiler/#method-disableRuntimeCallStats will now correctly deeplink again
  6. Typing any alphanumerical character will automatically start the search.
  7. Use markdown for the index page, rather than HTML for easier editing.
  8. Use rollup with terser for a small JavaScript build.
  9. Ensure that tabbing throughout the page is consistent, including showing the pound signs when inspecting a method/event/type
  10. Small accessibility tweaks in terms of color contrast

CC @paullewis

Closes #109 Fixes #99

TimvdLippe commented 4 years ago

1 annoyance: If the user is selects a result from a search that is on the same page, then the page doesn't properly scroll into the view. I haven't been able to figure out how to force the page to scroll to the correct location.

TimvdLippe commented 4 years ago

And just as I posted it and did some more debugging I figured it out: I was listening for keydown instead of keyup. As such, the value I was reading from the input element was the old value, not the new value. Now that should all be working again 🎉

paulirish commented 4 years ago

wow. this is pretty awesome. and fast.

god, static sites are so beautiful.

3 things i noticed so far. but yeah i'm pretty on board with merging this. feels good.


1 annoyance: If the user is selects a result from a search that is on the same page, then the page doesn't properly scroll into the view. I haven't been able to figure out how to force the page to scroll to the correct location.

scrollIntoViewIfNeeded() with a scrollIntoView() fallback ?

nice keyboard fuzzysearch.. but small bug on the event capturing. just tried cmd-up for pageup and the input field intercepted on cmd and broke it.

in search results, can events get prefixed with their domain?

TimvdLippe commented 4 years ago

wow. this is pretty awesome. and fast.

god, static sites are so beautiful.

3 things i noticed so far. but yeah i'm pretty on board with merging this. feels good.

1 annoyance: If the user is selects a result from a search that is on the same page, then the page doesn't properly scroll into the view. I haven't been able to figure out how to force the page to scroll to the correct location.

scrollIntoViewIfNeeded() with a scrollIntoView() fallback ?

I will defer this one to a follow-up CL, as I need to do more investigation. It's a minor issue luckily.

nice keyboard fuzzysearch.. but small bug on the event capturing. just tried cmd-up for pageup and the input field intercepted on cmd and broke it.

Fixed.

in search results, can events get prefixed with their domain?

Fixed.