Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Settings: allow picking a default tool #372

Open
5 tasks
argyleink opened this issue Aug 12, 2019 · 4 comments
Open
5 tasks

Settings: allow picking a default tool #372

argyleink opened this issue Aug 12, 2019 · 4 comments
Labels
🚀 deeper integration chrome/firefox protocol usage 🔥 enhancement New feature or request ⚡️ feature New tricks for the tool-palette good first issue 👍 Good for newcomers
Projects

Comments

@argyleink
Copy link
Member

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)
@argyleink argyleink added 🔥 enhancement New feature or request good first issue 👍 Good for newcomers ⚡️ feature New tricks for the tool-palette 🚀 deeper integration chrome/firefox protocol usage labels Aug 12, 2019
@whoisvadym
Copy link
Contributor

@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
Copy link
Member Author

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
Copy link
Contributor

whoisvadym commented Sep 2, 2019

@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
    • 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 argyleink added this to To do 🤞 in v1 Sep 5, 2019
@argyleink
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚀 deeper integration chrome/firefox protocol usage 🔥 enhancement New feature or request ⚡️ feature New tricks for the tool-palette good first issue 👍 Good for newcomers
Projects
v1
  
To do 🤞
Development

No branches or pull requests

2 participants