this looks really cool, I should start to learn how to code scripts
Comment has been collapsed.
nice explanation! thank you for making that simple to understand...
its something like a automation tool to make certain things taht you want to work that way when triggered (if I got it right).
that's a nice project here because I really do recognize how much productivity userscripts brings to this site.
Comment has been collapsed.
20 Comments - Last post 18 minutes ago by InSpec
71 Comments - Last post 43 minutes ago by Reidor
7 Comments - Last post 57 minutes ago by sensualshakti
1,775 Comments - Last post 1 hour ago by Shanti
28 Comments - Last post 1 hour ago by DiabLXIX
52 Comments - Last post 2 hours ago by BlazeHaze
24 Comments - Last post 3 hours ago by Fluffster
36 Comments - Last post 5 minutes ago by grez1
717 Comments - Last post 8 minutes ago by CelticBatman
434 Comments - Last post 24 minutes ago by Heitor112
1,578 Comments - Last post 25 minutes ago by Pyrocious
3,362 Comments - Last post 35 minutes ago by pizurk
103 Comments - Last post 56 minutes ago by eeev
1,865 Comments - Last post 1 hour ago by MeguminShiro
The (unofficial) SteamGifts Userscript API
You may have noticed that there are quite some Userscripts around here to enhance your SteamGifts experience. Most of them are listed in the great SG Addon Registry by Sighery. I myself contributed some of them, and also wrote some scripts just for myself without releasing them.
I noticed that there are some basic things that many scripts need, and everybody goes and re-invents the wheel by implementing it for themselves.
I thought it would be cool to have an API that handles all those basic stuff for you, that you can just @require. This way, the creative heads out there can focus on building cool addons without the need to rebuild the n-th version of "fetch this GA" or "check the wishlist".
So I went ahead and took all my scripts, extracted the reusable parts of it and bundled it in the (unofficial) SG Userscript API. I built it in a modular way, so you can choose the plugins you need for your script without the need to include a bunch of code that you'll never use. I really hope that coders out there will transform their reusable code into SG API plugins, so that the API will be more and more complete over time. Any contribution is more than welcome! Just make a pull request on GitHub! Also if you are missing a feature, please don't just ask for it and hope I will eventually implement it - just go ahead and build it yourself! You're a coder! :-)
While developing, I focused on compatibility with Tampermonkey and Greasemonkey, as they are the most popular script managers. If there are any imcompatibilites with other script managers, let me know.
Enough chitchat, let's cut to the chase.
Changelog
Quickstart
Include this in your header:
Now you can access SgApi using the
SgApi
object.Read the "How to use" section and the Module descriptions below to learn more about SgApi and it's capabilities.
Check out the Example Scripts to learn about the basic features or one of the scripts below to see SgApi in the wild:
How to use
To use SgApi, you first need to @require the Core Module:
If you want to use any plugins, e.g. the "Giveaway Tools", you need to require those, too. Plugins always only depend on the core module and never depend on each other, so you can mix them all you want, as long as you @require
sgapi.js
first.Make sure you NEVER require the head of a branch but ALWAYS use links to a specific version.
This is necessary because the script managers download and cache a @required resource ONLY ONCE. Globally. Any changes to that resource after that won't be reflected in your script (or any other script requiring that URL). So always make sure you only @require static resources that will never change.
Once required, you can access any SgApi feature via the global SgApi object, e.g.
The only exception is the use() function, which is not accessible via the SgApi object but from the global scope. You can use it to import functions from a namespace into your global namespace, like this:
jQuery
I would have loved to integrate a method in SgApi that handles the jQuery integration, so that it "just works". Unfortunately, I haven't found a "standard" way to expose jQuery for any SgApi user, since sometimes a side effect of one of the strategies may be wanted or unwanted by the script author.
The problem is, that Greasemonkey and Tampermonkey handle their sandboxing different, which causes compatibility problems between Firefox and Chrome. Usually, it works just fine in TM and is a pain in the ass in GM - also due to the fact that debugging in GM is nearly impossible.
These are the strategies known to me:
Long story short, here is a little guide on how to integrate jQuery in your scripts:
Guide to use jQuery in Userscripts
If somebody knows a way how to achieve a out-of-the-box solution - please let me know!
SgApi Modules
In the following I will explain the currently existing modules and outline what you can do with it. There will be some basic examples for each modules. For more extensive examples check the example scripts on GitHub. Just install them and play around a little bit. If you are a purist and only interested in the API docs, you can check those too, but they are a bit messy and only intended as API reference.
Module Overview
Module: Core
Module Name: Core
Examples: 1, 2
Documentation: Github
Include Code:
Core - Example
Core - Overview
Core - About
The Core module is the glue holding together the API. It's mandatory to @require and must be @required before any plugin. It also provides the Util package, that helps with some common tasks. The most interesting function in Util at the moment is
requireCss()
. The function links a remote css file, so that you won't have to encode the css in multiline strings anymore.You can also include your css file as a @resource and inject in at runtime. The upside of this strategy is, that the css will be cached by your script manager and won't require an additional request every time. You'll need to @grant GM_getResourceText for this feature. But remember: resource caching is - just like @require caching - forever and won't reflect changes to your remote resource. So you always need to use a versioned url!
While developing, you can use @resource with a file:// url to your local css file. These changes will be recognized, since the script manager won't cache it.
Please note that you can not link files from raw.githubusercontent.com by providing an URL to requireCss(), because GitHub prevents this by setting the 'nosniff' header. You can, however, replace 'raw.githubusercontent.com' in your URL string by 'rawgit.com'. Rawgit.com is a service that removes this header. Note that rawgit is a service on it's own and not afiliated with GitHub. Check https://github.com/rgrove/rawgit/wiki/Frequently-Asked-Questions for more details. For embedding CSS from your resources, you CAN use raw.githubusercontent.com, because in this case the code is embedded in the page (<style>[code]</style>) instead of linked (<link src='url'>).
Another interesting feature of the Core module is that it maintains a Registry of all Userscripts in the current page impression that incorporate SgApi. Every script that @requires SgApi is automatically registered. So, if your script for example has compatibility issues with another script, you could just do something like this (provided the other script uses SgApi, too):
If you intend to use this, have a look at the example.
Module: Settings
Module Name: Settings
Examples: 1
Documentation: Github
Include Code:
Settings - Example
Settings - Overview
Settings - About
When developing a script, there is always the point reached when the complexity of your script requires some configuration to stay flexible.
Since there is no way to hook into SGs settings it is a rather big effort to include some basic configuration capabilities.
Many devs decided that the cost/benefit ratio for this small feature is unsatisfying and included their settings in global variables in their code, which is not a nice solution either. Most users don't want to be bothered with tampering with the code, and with every update these settings are overwritten.
The SgApi Settings module offers a lean interface to manage your settings and handles all the UI stuff for you. You just need to declare your settings once and SgApi integrates your Settings into the SG Account page. All Settings are integrated in the sidebar in the section "Userscripts". Although it is possible to define a custom section for your Settings to reside in, for the sake of usability, it is not recommended. This way, the users don't have an unnecessarily cluttered sidebar and always know where to look if they want to change a setting from any Userscript.
The last parameter in a setting declaration is always an options object, which is - hence the name - optional. Using these options you can tweak the Settings UI and behaviour to fit your needs. Basic options, that are available for most types of setting are
description, visible, title,
andeditable
. Most setting types have dedicated additional options, like minValue and maxValue for numbers. Like always, check the docs for a complete example and more details.Once initialized, you can access your settings in your script using the get() function:
Check the docs for more details on the options or just install the example and play around a little bit. Don't forget that your script needs to @match /account/* for the settings to appear there.
By default, the settings are saved in the localStorage, so that no additional @grants are necessary. Keep in mind that localStorage can be accessed by any script on SteamGifts. So if you have sensitive data in your settings, e.g. an API key or something like that, it is highly recommended to initialize your Settings with the "useGmStorage" option. For that to work, you need to @grant GM_setValue, GM_getValue, and GM_deleteValue.
Module: Giveaway Tools
Module Name: Giveaway Tools
Examples: 1
Documentation: Github
Include Code:
Giveaway Tools - Example
Giveaway Tools - Overview
Giveaway Tools - About
The Giveaway Tools provide a handy interface to read Giveaway Data. It also extends the UI class, exposing the relevant jQuery queries. Currently, this module is read-only, meaning it does not provide any auto-enter features.
Module: Wishlist
Module Name: Wishlist
Examples: 1
Documentation: Github
Include Code:
Wishlist - Example
Wishlist - Overview
Wishlist - About
The Wishlist module lets you access your steam wishlist. It is most useful in combination with the "Giveaway Tools" plugin. It maintains a copy of your wishlist in the localStorage and synchs this cached copy automatically when SG syncs with Steam.
Because a sync may happen, you need to get your wishlist asynchronously
Module: Notifications
Module Name: Notifications
Examples: 1
Documentation: Github
Include Code:
Notifications - Example
Notifications - Overview
Notifications - About
The Notifications module lets you show messages to you users. They will be displayed at the top of the content div and look just like Bootstrap Alerts.
There can be always only one
Highlandernotification displayed. All other Notifications are queued and displayed when the previous one has been disposed.Comment has been collapsed.