Settings: allow picking a default tool

[argyleink]

current default tool is guides, but maybe a user wants to always start it up with style or a11y inspect.

rough list of tasks to complete this:

• line 50 of vis-bug.element.js
• line 129 of vis-bug.element.js
• follow what colormode.js did but make an option list of visbug tools
• import VisBugModel into extension js and map the tools from it
• call toolSelected(tool_choice) on visbug.element from extension code (like colormode does)

[whoisvadym]

@argyleink, I'd like to pick this one next. I believe looking into unrelated issues would give me a better overall understanding of the project

[argyleink]

sounds good 👍

this issue touches aspects of the chrome extension and how it integrates with the web component, def a different aspect of the tool as compared to the PR we just merged which dealt with selection and feature functions.

[whoisvadym]

@argyleink
I like to think about a bigger picture, and as usual, I went big on this one...

1. To implement this story we might need a mechanism to hook into the pre-injection phase and pass default values from the chrome store. This could help us with future stories where there'll be other variables that we might want to use to initialize visbug object before injection into the DOM.
2. Also, I've thought about introducing the state machine to the extension lifecycle that would help to organize extension lifecycle (pre-injection/injection/ejection) in a more declarative way. I have a WIP here and I'd really appreciate if you can take a look. It is a simplified implementation of the Finite State Machine inspired by Jake Gordon's library, and it can be reused in other cases where local state management is needed.

pros:

• Cleaner than the mix of loaded, injected states.
• Declarative
• Consistent state management API across the application

cons:

• In some cases requires more boilerplate code

3. • import VisBugModel into extension js and map the tools from it

While working on this one I've noticed that the current project configuration doesn't use Rollup for bundling /extension/ folder. If we want to use something like imports in those files there are a few ways to accomplish this:

• Extend the existing rollup config to use multiple inputs
• Create a separate rollup config file like rollup.extension.config.js to tackle with /extensions/ folder separately.

[argyleink]

lovely comments! state machines! i've spent a lot of time with those =)

1. you're right, there's currently no official initialization system where visbug receives things from chrome in a normalized way. chrome does communicate with visbug sending color settings, paths to local extension resources, etc, but none of these have been aligned to a single message system. visbug doesnt care when it get the settings, so aligning a message system is more of a devtools lifecycle task than much to do with visbug. could be valuable, but this area of the code isnt getting out of hand, unsure if a system needs created yet.
2. a statemachine managing injection/ejection lifecycle is nice, looks like you had fun! tests! but if we step back from the WIP PR, we turned a simple if/elseif/else into a state machine, that requires more mental load to understand than the previous version. while i like the tech and implementation, I don't think it's valuable for this codebase yet:
   1. new dependency
   2. new paradigm
   3. more LOC
   4. same exact behavior
3. here's a branch where i've done lots of the extension dir rollup work https://github.com/GoogleChromeLabs/ProjectVisBug/pull/205/files#diff-c726b82d57b5a94e9048bee862e1ddac, in case you want to use it for reference. that PR also sets up a proper message passing system using chrome postMessage. unsure when i'll get to revise it! had a bunch of fun making it though, proving out that visbug could have a "2nd screen" experience.

you still down to have this ticket? being able to choose a default tool with the same ux as a color would be nice. thoughts!?

i super value your insights and contributions. thanks for communicating so well.