creating a browser extension with quasar is harder than it should be

[julie777]

Currently to create a browser extension you have to create a quasar project and then add the bex parts with "-m bex". While this works, it doesn't make getting started with a browser extension easy.

A normal quasar project can be created and then immediately run with quasar dev.
It would be nice if there was a way to create a quasar bex project that also ran immediately with and example of all the parts actually there and usable. This includes a popup, a sidebar, an options page, a page for the extension and some simple communication. It is much easier to remove what isn't needed than to go through all the steps in the doc and try to get something that works.

One example of the unnecessary difficulty is that after creating a bex, then using quasar new page PopupPage I have to go and add it to the router and the manifest.json. Then I just go and add some text to the page and run the bex. The popup opens but doesn't display correctly because the generated page file has been generated to only work with a layout.

For someone new to creating browser extensions, and new to trying to use Quasar to do it this seems complicated and frustrating.

It would also be nice if the bex supported running with firefox web-ext run which starts the browser with a temporary profile and loads the extension.

I love Quasar and don't want to use Vue directly, but it often seems to be overly complicated at times to just do something simple.

Any thoughts?

[julie777]

I forgot to mention that it seems like bex mode is still primarily focused on creating a quasar app with support for a background script. Most browser extensions are not apps, but just extensions of the browser's functionality.

It seems like a bex template for quasar that isn't a Quasar app with bex added would be more useful, more concise, and much easier to start with.

[phive151]

This is exactly my situation right now. I am new to JS and TS, front end in general but when i heard about quasar it seemed like such a great solution. but the communication is so confusing and the documentation doesn't really give you a lot. For example the content script operates in the context of Dom manipulation. Cool, got it. But we have this super cool Dom script that communicates directly with the dom and everything else via the bridge. OK so use the dom file? well you can use the content script because it too has access to the bridge... wait whats the bridge? its the super cool way that everything can talk to everything else. OK cool so I don't need the Dom script?

I feel like I'm spinning my wheels for doing something that should be simple like changing options in a popup changing an element in the context of the web page. There's not a lot out there in regards to Quasar Bex.... I wish there was... but anyway.... I found this post looking for more examples / documentation and thought I'd throw in my 2 cents...

[phive151]

DISCLAIMER* I'm not smart so this is more of me being frustrated with my own ignorance... I'm sure.

[yusufkandemir]

Developing browser extensions is kind of a different world. So, it would be hard to think with the usual mentality. To me, BEX mode is more targeted towards people who know how to create web extensions, but want to do it better/faster/easier. You can also ship a browser extension complementing your existing website/app, within the same codebase. But, it's hard to get into if you don't have experience with browser extensions. So, some of the frustration is natural. That is not to say it has to be this way. Improving the docs with clear examples, redirecting to the related resources, helping devs to connect dots, etc. would help a lot to get into this.

To give some history and context: BEX mode didn't receive love for some time. The original creator of BEX mode, and a previous core team member, Allan Gaunt, stepped down a long ago. There was no dedicated maintainer for this mode. But, it still got important updates along the way. These days, it received a substantial upgrade.

The bex mode was reworked and released in app-vite v2 rc and app-webpack v4 rc:
https://quasar.dev/quasar-cli-vite/upgrade-guide#bex-mode-changes
https://quasar.dev/quasar-cli-webpack/upgrade-guide#bex-mode-changes

It should provide an overall better experience. The communication should be easier to understand now. Of course, since it's in the RC phase, the docs don't have dedicated pages for reworked BEX. Please give it a try and let us know what you think.

---

To address the confusing parts you mentioned and provide a pseudo-documentation:

The dom script got removed, now you can just use a content script for that purpose.

In the context of a browser extension, there are mainly three parts:

• background script: the "server" of the browser extensions (a general browser extension concept)
• content script(s): runs inside the website that runs in the browser. You can use these scripts to interact with the websites, collect info, make updates, etc.
• app/popup: the Quasar app which runs inside the popup and such. You can have pages, components, etc. inside it and use Quasar components inside. You can use $q.bex to interact with other scripts. So, for example, you can have a button in your UI(e.g. popup) that says "change colors". Then, you would send a message to a content script to interact with the active webpage, which perhaps injects some CSS code. You can also make it so that the background script listens for "bookmark created" event, then send a message to the app script, where you use the Notify plugin to display a notification within your UI(e.g. popup). So, all three things can communicate and interact with each other.

Different use cases:

• an extension that doesn't do anything specific in background or content scripts. This would be basically embedding a web app inside a browser extension popup. So, you would just write the Quasar app and don't do anything about communication, bridge, etc. This is not very useful as it's not supposed to be browser extension, but still a valid idea.
• an extension without any UI(popup, Quasar app, etc.). It could inject some code into the active website when clicking on the browser extension icon, or perhaps on a shortcut. You would mainly deal with the content scripts and the background script. This is not specifically a use case where you utilize all of what Quasar BEX provides, but it's still a totally valid use case.
• an extension that does a bit of both. Maybe you have a content script that collects some data from the web page, then you show that data in your UI(e.g. popup). Then, you could also allow clicking a button or similar, which in turn runs some code within the website, maybe removing the selected element.