We need review these two POCs and determine how to take them forward to achieve the end goals for Dojo 2 developer experience. @edhager has started a review of the devtool poc and added an issue with some ideas for future enhancements
The current diagnostics package is currently responsible for wrapping relevant Dojo 2 modules which involves hooking into aspects of the lifecycles. This approach is functional but has potential drawbacks in terms of maintainability and requiring knowledge of private package internals. One potential alternative would be to include the required hooks within each package behind a flag.
Potential Ideas (may already be in Ed's enhancement list):
Re-render highlighting
Live widget tree
Performance statistics (specifically when RAFs overruns)
Live Event logs with filtering and categories (including Dom events)
Inspect specific widget(s) and see live events relating to it
Make the widget tree look more like the dev tools elements view (i.e. inline attribute/properties)
Updating properties via the widget tree that triggers a these to re-render
Click through to functions on the widget (and map to source code)
Detection for what features the devtool supports that the app is using (i.e. shouldn't show the stores icon if the application is not using stores)
Ideally we're looking for simply being able to install the dev extension and run the build with the devtool flag set to true.
Epic
Dojo 2 has a requirement to provide an elegant, simple to use development tool that can be activated externally for any Dojo 2 application.
There is an existing POC for a devtool extension that leverages a secondary package for adding the diagnostics information required.
We need review these two POCs and determine how to take them forward to achieve the end goals for Dojo 2 developer experience. @edhager has started a review of the devtool poc and added an issue with some ideas for future enhancements
The current diagnostics package is currently responsible for wrapping relevant Dojo 2 modules which involves hooking into aspects of the lifecycles. This approach is functional but has potential drawbacks in terms of maintainability and requiring knowledge of private package internals. One potential alternative would be to include the required hooks within each package behind a flag.
Potential Ideas (may already be in Ed's enhancement list):
Ideally we're looking for simply being able to install the dev extension and run the build with the devtool flag set to true.