Should we split the content.js code from background.js code? about ghosttext-for-chrome HOT 8 CLOSED

I think this is a good Idea when the lib.js keeps on growing, lets say if it exceed 500 lines of I will split it up? Currently it's much more comfortable having all in one file.

from ghosttext-for-chrome.

It's not an issue of size, rather of separation of concerns. What is called in the DOM doesn't need anything that's needed in the background, and viceversa.

I did a quick test on the branch libs-split-test, let me know what you think, it's going to need a bit more work, probably.

from ghosttext-for-chrome.

Whats about using sub namespaces like GhostText.Background, GhostText.Content… ?

from ghosttext-for-chrome.

That would make sense if there was a shared GhostText object, which there isn't in that test. All the content code is in content.js; lib.js is not loaded at all.

I'm doing this to avoid any possible confusion if we load methods that we can't use: e.g using .openConnection() in background.js (impossible)

from ghosttext-for-chrome.

Okey let's split it up but lates we should fix all bugs and implement all features for V1 first before we start refactoring.

from ghosttext-for-chrome.

I reorganized the code in content.js (c319bbb) and I've pulled a function from libs.js (ebd916e) to ready this. Content.js is now ready, the split can be done progressively as needed.

I tried to keep a similar style to lib.js, but I'm not sure how you define a static and a public/private function, so you might have to go in there and add a couple @comments.

from ghosttext-for-chrome.

Since you reorganized the content.js this might be right time moving the lib.js code to the background.js file?

from ghosttext-for-chrome.

I did that last time, but then I realized that options.html uses lib.js too, so we might just l leave it there.

If anything we could load lib.js as the background file, detect it and run GhostText.connectionHandler();, but it's not worth it I think.

from ghosttext-for-chrome.