So, I don come again.

Y'all know how I preach about project based learning? Well, recently, I just don't understand this trend of chrome extensions. The market for this thing seem to be booming like mad now. Especially now wey AI don dey power almost everything on the internet.

I know a lot of people do not like js and frontend, well, no be me!
While we can do alot on the backend, business logic and stuff. I think I understand now more than before, people really want to see the beauty of messy backend and how do you put it to them without html, css and javascript?
Anyways, I don't care. So, I decided to finally try out chrome extension development and I must say, it's a simple as it is fun. Right now, I be newbie for the trend. I be total olodo and i am hoping to learn more from my oga's wey see road wella for here.

I was able to achieve this in the first 24 hours of my learning process, had to still leave sha oo to do other works that put food on the table. But then, I must say it has been really fun and I am looking to doing more here. While this is a side project and a work in progress, I don't mind getting more insight on how to improve it especially with the new manisfest v3 which is totally different from the previous versions.

I'd love y'all to educate me more on the chrome API and its usage.

As for the styling, well... there was no design inspiration as everything was brough out exactly as it is in my head. Animation and transition would be added eventually. I think this is a great project to add to my portfolio.

Please, share your thoughts. We all dey learn. Backenders, I know how difficult it is to share project ideas and progress because of the project nature. I dey do backend too and e no make sense to dey show wetin dey happen behind behind. So, make I use this frontend dey clean mouth.

That wan sef dey!!!


https://www.youtube.com/watch?v=SUPG7Oc6BYA

Modified:
As usual, I like color scheme. So i made it both light and dark mode compatible using the prefers-color-scheme css media property.

Are you building a with REACT or Vanilla?

Glad to see this, I will follow this thread so I can throw some Chrome extension contributions.

But at least you know the Chrome extension architecture.

great job regardless.

What's the ext about?

LikeAking:
What's the ext about?

ChatGPT Integration

Paystack:
Are you building a with REACT or Vanilla?

Vanilla!

qtguru:
Glad to see this, I will follow this thread so I can throw some Chrome extension contributions.

But at least you know the Chrome extension architecture.

great job regardless.

Exactly my intention and I hope to learn more from you.

The chrome architecture seem quite simple but not all straightforward.
With the new v3 manifest and it's APIs

I want to really understand how to use node modules with the service worker. As we know chrome extensions SW isn't as it's web counterpart.

Let say in a situation where someone is bundling out a very complex extension.

niel63:


Exactly my intention and I hope to learn more from you.

The chrome architecture seem quite simple but not all straightforward.
With the new v3 manifest and it's APIs

I want to really understand how to use node modules with the service worker. As we know chrome extensions SW isn't as it's web counterpart.

Let say in a situation where someone is bundling out a very complex extension.

Let me share some info here

ContentScript is injected into the host page, it can modify the host page's DOM but cannot modify the code and is also subjected to CORS issues. It can call some chrome.api sendMessage etc

Popup is the main extension you see on the toolbar, CORS does not apply to it, and it can call much more chrome.api than ContentScript

Background Worker has no DOM in it, but it has full access to all the chrome.api

Message Passing => This allows cross-communication between contentScript => Popup or Background Worker. e.g ContentScript cannot use the Notification or Tab API, so you need to sendMessage to Background Worker to call chrome.apis

Background workers has no concept of DOM, so depending on what you want to do, running node_modules in the background worker might be a bad idea, since it has no document object in it.

You can use React to create a Web extension and bundle the code in ContentScript and Popup. Background worker is only for request or chrome.api so it can simply listen to chrome.runtime.sendMessage event and trigger the code based on the event type


I hope that makes sense.

Take this code it's built in React/TypeScript and Redux for Chrome extension, cjchika and I wrote it for a client, but it's not a big deal to share
githubDOTcom/dojoVader/chrome-extension-development/tree/main/CSV_Reader

qtguru:


Let me share some info here

ContentScript is injected into the host page, it can modify the host page's DOM but cannot modify the code and is also subjected to CORS issues. It can call some chrome.api sendMessage etc

Popup is the main extension you see on the toolbar, CORS does not apply to it, and it can call much more chrome.api than ContentScript

Background Worker has no DOM in it, but it has full access to all the chrome.api

Message Passing => This allows cross-communication between contentScript => Popup or Background Worker. e.g ContentScript cannot use the Notification or Tab API, so you need to sendMessage to Background Worker to call chrome.apis

Background workers has no concept of DOM, so depending on what you want to do, running node_modules in the background worker might be a bad idea, since it has no document object in it.

You can use React to create a Web extension and bundle the code in ContentScript and Popup. Background worker is only for request or chrome.api so it can simply listen to chrome.runtime.sendMessage event and trigger the code based on the event type


I hope that makes sense.

This is very insightful, but I hope you know the term "background worker has been renamed/changed to service worker in the new manifest (This means that, you don really tey for this chrome extension journey... moving forward, they are dropping support for other versions.)" but then, i'd like to know the limitation of the content script. On a very basic level, I understand the content script responds to web urls/path to which you want it to work on... right?

Does this mean that using the content script is a better approach to developing really complex chrome extensions? Especially when you need to communicate with API? and of course, working with node modules.


I started out with Vanilla JS just to get the concept of it all, but I will eventually switch to svelte or react. Me just wan know the real koko first.

qtguru:
Take this code it's built in React/TypeScript and Redux for Chrome extension, cjchika and I wrote it for a client, but it's not a big deal to share
githubDOTcom/dojoVader/chrome-extension-development/tree/main/CSV_Reader

Thank man!

I see you're using webpack. I actually used browserify in my extension. Both actually do almost same thing.
Is there any extra advantage to using webpack? I wan know everything for this jouney... I miss one work like that worth about $4k. I was just looking like mumu when they were saying things i did not understand. That's why I have been asking you about building complex extensions.

The market now na large market.

Modified:
For some doubting thomas' you can actually be a bounty hunter on replit. And they have alot of cool side projects you can quickly work in all tech stacks. Most good projects are based on AI and ML

my bosses

here's my understanding of chrome extensions architecture so far.

manifest.json - this is where all metadata about the extension and permissions needed are decleared

content scripts - js that runs on pages specified can modify the dom and have limited access to chrome api.

service workers - js that runs in the background when needed, have full access to chrome api and no access to the dom

popup and action - this is all about how the extension is displayed on chrome and function ran whenever the chrome icon is clicked

Tobedated:
my bosses

here's my understanding of chrome extensions architecture so far.

manifest.json - this is where all metadata about the extension and permissions needed are decleared

content scripts - js that runs on pages specified can modify the dom and have limited access to chrome api.

service workers - js that runs in the background when needed, have full access to chrome api and no access to the dom

popup and action - this is all about how the extension is displayed on chrome and function ran whenever the chrome icon is clicked

You're on the right track. Don't forget about the options page too...

niel63:


This is very insightful, but I hope you know the term "background worker has been renamed/changed to service worker in the new manifest (This means that, you don really tey for this chrome extension journey... moving forward, they are dropping support for other versions.)" but then, i'd like to know the limitation of the content script. On a very basic level, I understand the content script responds to web urls/path to which you want it to work on... right?

Does this mean that using the content script is a better approach to developing really complex chrome extensions? Especially when you need to communicate with API? and of course, working with node modules.


I started out with Vanilla JS just to get the concept of it all, but I will eventually switch to svelte or react. Me just wan know the real koko first.

ContentScript only has access to the DOM, but to call API, you can send the URL via sendMessage to the Service worker, fetch the response, and then use chrome.tabs to send it back to ContentScript. I am working on fixing the Svelte Devtool chrome extension, the original author abandoned it, so incase anyone is looking to work on something chrome extension related.

yeah but vanilla is good for now, take care

I Started learning too some days ago after seeing one of my boss post about it as a means of freelancing and I would like it if this thread gets really invested in as my Bosses have already been doing.
My question is can we agree that an extension is also a website on its own cos I believe it also uses most frontend languages and the manifest.json for it's purpose.

Maxxim:
I Started learning too some days ago after seeing one of my boss post about it as a means of freelancing and I would like it if this thread gets really invested in as my Bosses have already been doing.
My question is can we agree that an extension is also a website on its own cos I believe it also uses most frontend languages and the manifest.json for it's purpose.

It's a website technically. The popup is html+css

qtguru:


ContentScript only has access to the DOM, but to call API, you can send the URL via sendMessage to the Service worker, fetch the response, and then use chrome.tabs to send it back to ContentScript. I am working on fixing the Svelte Devtool chrome extension, the original author abandoned it, so incase anyone is looking to work on something chrome extension related.

yeah but vanilla is good for now, take care

Thanks again baba.

qtguru:


ContentScript only has access to the DOM, but to call API, you can send the URL via sendMessage to the Service worker, fetch the response, and then use chrome.tabs to send it back to ContentScript. I am working on fixing the Svelte Devtool chrome extension, the original author abandoned it, so incase anyone is looking to work on something chrome extension related.

yeah but vanilla is good for now, take care

Please can I contribute to the project with the little I know?🤲🏾

qtguru:


It's a website technically. The popup is html+css

Okay, thanks