solidusjs / devtools-solidus Goto Github PK

When the inspected tab changes, the plugin should refresh the page context JSON while preserving the expanded/collapsed state of the tree.

Currently when the inspected window finishes loading (after a navigation event, including refresh), I am attempting to update the Inspector JSON object with inspector.view(pagecontext); but that seems to break the Inspector JSON object. (It won't expand and collapse).

I also need to figure out how to preserve the expanded/collapsed state. I think there was a way to do something similar in Storyteller, but I'm having trouble finding that.

If I visit another page I can no longer expand sections of the context.

Looks like the way I handled getting the context doesn't account for query strings, which, among other possible problems, means that the parameters object is not accurate in the inspector.

I'm not sure if the Chrome Tabs API will give information about the query string or not. It seems odd that it wouldn't, but I don't immediately see anything regarding query strings in the Chrome Tabs API documentation.

If I undock my devtools and re-dock it, the contents of the Solidus panel disappears. Refreshing the parent page brings back log activity, but resuscitating the inspector requires closing the page tab and opening a new one.

Surface server-level errors into DevTools so that users can debug more quickly.

Also mentioned in solidusjs/solidus#61

It doesn't make sense for the Solidus devtools to run on a non-Solidus page, so we need a way to check if a page is a Solidus page before the Solidus devtools runs on it. The Grunt, Facebook React, and other devtools extensions do similar checks and don't run on pages that aren't using those tools.

There are a lot of ways we can check if a page is a Solidus page. @pushred and I had discussed using the page's x-powered-by headers. Currently that header shows Express, but we could potentially change that to be more specific to Solidus. The downside of this approach would be that it requires a second XMLHttpRequest to check the headers with JavaScript. Since we have to request the page's JSON object anyway, maybe we could just check that route and make sure that it's a Solidus object before running the rest of the DevTools. That would save a request and wouldn't depend on us changing the headers.

Another option could be whether or not a page has a Solidus object, though @pushred had mentioned that the pages may not be served with a Solidus object in the future.

Perhaps a meta tag in the HTML head would be another workable option to consider.

Certain stages of development involve a lot of navigation between pages, i.e. when setting up routes and navigation links. Currently state is preserved on a per-page basis, which generally is a good idea I think, considering working with different sites, etc.

We may want to consider trying to normalize state between pages when working within a single site (and window session) however, such that when navigating between pages expanded/collapsed sections of the context are consistent. Currently there's some extra time required here when building out pages to expand certain sections I'm working with across pages.

Obviously any variations in the context between pages would cause some issues here, but generally the objects are pretty consistent at least with stock root sections and certain resources, etc.

I've tried to be fairly thorough in writing meta data for both the plugin and repo, but before we release version 1, that meta data should be reviewed for thoroughness. The plugin meta data should be updated for the Chrome Web Store and it should probably include some screenshots. Some more info should be included in README.md too. I don't want to make the README and more lengthy or wordy than necessary, so it would be good to discuss in this issue what things might need to be included in that.