suprematic / khroma Goto Github PK

There's no reason for a user to have to to #js on every function parameter for get-views, since they'll always be called from Clojure code and aren't likely to feed off JS data. Lets do a clj->js to the parameter.

Just merged the 0.1.0 changes into master, updated changelog.

There's something that I'm ambivalent about.

storage has a get function where, on result, I'm keywordizing the keys. This makes sense at first blush, since I'd expect a ClojureScript user is more likely to use keywords as a map's key, but it has the disadvantage that it's making assumptions. If a user wants to set a key that's a string, why should it return it as a keyword?

I'm not entirely sure what's a workable alternative, though. If we knew we were saving entire objects (key-value pairs) I could just use transit-cljs and convert the whole thing, but that doesn't seem workable when the user can just request a few keys (that can be strings or keywords).

Of course we can always just leave as is - we keywordize values on get, and assume anyone who wants more fine grained control over what goes in and out of local storage shouldn't be using the storage straight up, but a fuller Javascript database. I just thought I'd start a discussion before assuming my use case is the general one.

Thoughts?

Hi,

I've bumped the version on master to 0.0.3 - might be good to do a Clojars release before we start tinkering with event name changes, so that the latest "stable" additions are published.

Firstly, thanks for your work on this project - it's extremely useful. I'm curious if you have support for Chrome's webRequest API at this point in time, and if you do, if there might be a usage example of that. I couldn't find much after digging around in the source a bit.

Thanks!

Both get-tab and get-active-tab are returning a map with the tab information, instead of just returning the object. This seems unnecessary, since we will always return a single value, and I think we should stick as close to the API as possible.

Re-evaluate for 0.2.0.

As far as I could understand so far it is only possible to use runtime/send-message or runtime/connect to send messages to the background-script, but I can't send any messages dedicated to a specific tab.

I think we would need wrappers for chrome.tabs.connect and/or chrome.tabs.sendMessage to fulfill this task.

Please correct me if I am wrong and there is some way.

khroma function naming could improve to help more clearly indicate when a function has a one-time result (for instance, current-window) and when it is a listener for events. This is the sort of change that's better done early on, before the API can be reasonably considered stable.

Let's consider runtime/connections as an example. While it receives events on connect, the name is not consistent with the convention used on the tabs namespace, where listener functions are post-fixed with -events.

I'd suggest rename all event listeners to be prefixed with on-, to more clearly indicate what they are. This means we'll end up with runtime/on-connection, tabs/on-tab-updated, tabs/on-tab-removed, etc.

Alternatively, we could just follow the tabs example and postfix -events, so we'd have runtime/connection-events.

Thoughts?

tabs/get and tabs/get-active should be explicit enough. Mark as deprecated.

Hi guys, I'm new to chrome extension development. What I'm trying to work with is a very simple example to get the current active tab. What I have done so far is :

• Set tabs permissions in manifest file
• in content cljs I have this

(defn init []
  (go
    (let [ch (t/get-active-tab)
          t (<! ch)]
      (console/log t))))

But I got this error

// Uncaught TypeError: Cannot read property 'call' of undefined
var inst_7813 = khroma.tabs.get_active_tab.call(null);