pushred
commented
10 years ago Another newer example that's popped up: https://chrome.google.com/webstore/detail/ember-inspector/bmdblncegkenkacieihfhpjfppoconhi
Also I had some issues when I originally tackled this, see: http://stackoverflow.com/questions/14545942/avoiding-duplicate-developer-tool-panel-instances
Since writing preprocessors involves changing the context of a resource’s response it’s necessary to constantly preview that response in the process. Currently the only way to do that is to load a page’s context as JSON, track down the resource, and find the affected regions. The use of a browser extension such as JSON Formatter certainly helps by providing code folding, syntax highlighting, etc. But it’s necessary to reload the entire context many times in the process of this development and getting back to the same region of the JSON can be tedious.
This process was much better while using Storyteller Editor, it’s Inspector JSON component with it’s ability to remember the state of the inspector even when it’s contents change. This along with autoupdating whenever changing the content of a function or a resource was a highly productive combination.
It would be great to be able to use Inspector JSON while developing Solidus sites. One method for doing this could be to offer it on a dedicated route as we once did in Storyteller as
.context. Another option could be developing a browser extension, such as a Chrome Developer Tools panel as has been done to some success elsewhere for offering insight into the backend.Examples:
Good run through of some others here.
Another problem that both platforms share is error logging. In Storyteller they were surfaced in a
storytellerobject within the context. Not very intuitive but it was ultimately supposed to be surfaced into the editor UI anyway. Solidus offers good logging at the server level which is certainly workable. But bubbling these errors up into wherever the context is being previewed would be even better and round out some basic developer tools.