some time before I have created NPM package for transforming Debug.log messages from string to JSON object. Now I’m finishing browser extension version
TLDR: Do you want to help me beta test that extension? Register to beta test and I’d send you the beta version of the plugin for your browser (Chrome-like or Firefox)
Remember elm-debug-transformer? It was welcomed warmly but in time I have found few missing features and problems with it. It was forcing you to install yet another NPM package and init debug output directly to each of your projects, which can be helpful, but it was forcing anybody in the team to be familiar with the new scheme. Plus for the Chrome Custom formatters it needed each team member to have them enabled unless they would like to see crazy amount of metadata for each item in the Debug.log. Also it forced all team to develop on the same browser instead of those which they would prefer.
Now I’m finishing the web browser extension, which would insert the elm-debug-transformer into all pages you are working on without the need to spoil your project with yet another NPM package. Your project can stay clean of such magic and you can have your own settings on how to transform the Debug.log output.
Everything works for me and few of those, who were brave enough to install it But I would like to battle test it more before putting it into the wild, so I’d like to widen the circle of testers a bit.
Are you interested in such extension? Please, register to beta test and I’d send you the beta version of the plugin for your browser (Chrome-like or Firefox)
Thank you for your help, be safe and take care.
Tom
However when Debug.log is called right after the Elm page rendering (around init function, for instance), that first debug print is not handled by the extension (shown in default style).
After the page load settled, subsequent debug prints are correctly handled by the extension and formatted. Is it intrinsic limitation of browser extension? By that I mean, browser extensions are lazily loaded after the page load so they cannot intervene events that happened before they are loaded?
I would say so. The extension is injecting the page after it has been load so I’d say there can be delay between you start sending Debug.log straight away and console.log being hooked up. As oppose to the NPM package which is being initialized before Elm even starts. I’m new to the whole extension space, so maybe it is somehow possible, but I’m afraid that there still be some delay between page being loaded and extension kicks in.
Ok, so it has been almost 10 days for the plugin out in the wild and so far no major problems have risen which means that I can proceed with final touches and release it officially soon Thanks for all your help so far.
If you have anything regarding the plugin beta version (any feature requests/things to do better/something that was not clear to you) please write me the feedback on that with:
thanks to you all