This PR attempts to improve the user experience in the live demo found at http://blog.alexwendland.com/angular-json-tree/ In particular, this PR aims to improve the timing and frequency at which the user is shown an error message while editing the JSON text.
It includes two notable changes. Most importantly, the try... catch... block for attempting to parse the JSON string is now only called 1.5 seconds after the user finishes typying. This is achieved by "debouncing" the try-catch code (i.e. calling it after a timeout, while replacing inprogress timeouts with new ones with each call). Secondly, the try... catch... block is now called after a user types a key, instead of when the string changes: it replaces the watch with an ng-keyup event.
Motivation and Context
The goal of this change is to only show the user an error message when it is useful and not distracting.
Currently, at http://blog.alexwendland.com/angular-json-tree/, each key stroke in the editor that does not result in properly formatted JSON immediately shows the user an error message. This means that if a user types a new line, they can be repeatedly shown error message until they are done typing.
With this PR, the user is only shown an error message after they are finished typing. This removes the distracting display of error messages while the JSON is being edited, while still providing the user with useful info for correcting the errors once they are ready to read it.
I believe this will be helpful for developers who are using the demo to help try to decide whether this directive is a good fit for their project. Also helpful for developers who are using the demo to functionally test (i.e. in the browser) any changes they might make to the code.
How Has This Been Tested?
Functional testing in the browser. I'd be happy to add tests, but thought it might create unnecessary overhead for the demo.
Screenshots (if appropriate):
Before:
After:
Types of changes
[ ] Bug fix (non-breaking change which fixes an issue)
[x ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
Checklist:
[x ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] My change requires a change to the test suite.
Description
This PR attempts to improve the user experience in the live demo found at http://blog.alexwendland.com/angular-json-tree/ In particular, this PR aims to improve the timing and frequency at which the user is shown an error message while editing the JSON text.
It includes two notable changes. Most importantly, the
try... catch...block for attempting to parse the JSON string is now only called 1.5 seconds after the user finishes typying. This is achieved by "debouncing" the try-catch code (i.e. calling it after a timeout, while replacing inprogress timeouts with new ones with each call). Secondly, thetry... catch...block is now called after a user types a key, instead of when the string changes: it replaces thewatchwith anng-keyupevent.Motivation and Context
The goal of this change is to only show the user an error message when it is useful and not distracting.
Currently, at http://blog.alexwendland.com/angular-json-tree/, each key stroke in the editor that does not result in properly formatted JSON immediately shows the user an error message. This means that if a user types a new line, they can be repeatedly shown error message until they are done typing.
With this PR, the user is only shown an error message after they are finished typing. This removes the distracting display of error messages while the JSON is being edited, while still providing the user with useful info for correcting the errors once they are ready to read it.
I believe this will be helpful for developers who are using the demo to help try to decide whether this directive is a good fit for their project. Also helpful for developers who are using the demo to functionally test (i.e. in the browser) any changes they might make to the code.
How Has This Been Tested?
Functional testing in the browser. I'd be happy to add tests, but thought it might create unnecessary overhead for the demo.
Screenshots (if appropriate):
Before:
After:
Types of changes
Checklist: