These are chat archives for bluefin-octopusdeploy/chrome-extension

May 2016
Matt Richardson
May 15 2016 05:54
I'm thinking of doing some refactoring...
1) move 2.x stuff into a specific 2.0 folder (2.x?) so that it matches the 3.0 folder structure a bit better
2) move nanoajax, mixpanel, underscore etc into a src/lib folder (to emphasise that they are 3rd party)
3) pull the 'update step template' background stuff into its own file and out of metrics.js
Matt Richardson
May 15 2016 06:01
4) change the analytics messages to be a specific message type, rather than overloading the other message
what do you think?
David Roberts
May 15 2016 06:46
Yes to all those. I've been thinking similarly for a while.
At some point if also like to go back through a lot of it to see if we could make it user more angular. Not sure how to inject it without user clicking a button or link. The goal would be to share this code with the server side plugin that I'm going to start on again.
As for the refactoring let's go ahead and do those in separate pull requests, to help make sure we don't miss anything.
Matt Richardson
May 15 2016 08:06
I was thinking a good first step for the server side plugin was to inject some code that detects if the user is running chrome and if so, checks if the extension is loaded, and if not, puts a banner up to recommend installing it.
That way, orgs who use it have some consistency
Matt Richardson
May 15 2016 08:25
Part of the challenge of using the angular stuff for things like the filters is that you need to modify existing a
modify existing angular views, which might be too difficult.
It works well for the couple I've done as they are new views, really, not modification of existing ones.
Might be possible though - not sure.