thank you for teaching me the name of this concept.. I use it all the time in an attempt to modernize my workflow despite the resctrictions of ExtendScript.. But i always glossed right over the term polyfill because i had no idea it was even related to what I was doing.
In case anyone else out there is frustrated with the lack of extremely helpful array prototypes, here are some that I include in my standard "utilities" file for every script I write:
Array.prototype.indexOf = function(a, b, c){
for (c = this.length, b = (c + ~~b) % c; b < c && (!(b in this) || this[b] !== a); b++);
return b ^ c ? b : -1;
}
Array.prototype.map = function(callback) {
arr = [];
for (var i = 0; i < this.length; i++)
arr.push(callback(this[i], i, this));
return arr;
};
Array.prototype.forEach = function(callback,startPos,inc) {
if(!inc)inc=1;
if(!startPos)startPos=0;
for (var i = startPos; i < this.length; i+=inc)
callback(this[i], i, this);
};
Array.prototype.backForEach = function(callback) {
for (var i = this.length-1; i >= 0; i--)
callback(this[i], i, this);
};
Array.prototype.filter = function(callback, context) {
arr = [];
for (var i = 0; i < this.length; i++) {
if (callback.call(context, this[i], i, this))
arr.push(this[i]);
}
return arr;
};
Additionally, i've always been frustrated by the idea of "collections" in illustrator that appear like arrays, but don't behave the same way.. For example, you can't set a variable for app.documents[0].layers and then use any of the above prototypes because technically they're not arrays.. One obvious solution is to just write a standalone function instead of a prototype.. but that sacrifices cleanliness IMO. So I created a standalone function called arrayFromContainer(parent, itemType) that allows me to pass in a parent and an item type and it will return a standard javascript array without any of the extra baggage of an illustrator collection, and allow me to chain together array prototypes.
function arrayFromContainer(container,crit)
{
var result = [];
var items;
if(!crit)
{
items = container.pageItems;
}
else
{
items = container[crit];
}
for(var x=0;x<items.length;x++)
{
result.push(items[x])
}
return result;
}
To me, the main benefit of this is that you can avoid runtime errors as a result of running a for loop in the wrong direction... The most obvious example is trying to delete certain layers out of your document in a loop. If you do a normal for loop, like this:
for(var i=0;i<layers.length;i++)
{
if(layers[i].name.match(/(print|proof)/i))
{
layers[i].remove();
}
}
This will almost certainly fail (unless there aren't actually any layers to remove). So you have to remember to run the loop backwards. Not a huge deal, but something i've run up against way too many times.. Using arrayFromContainer, you can manipulate/remove/add items to/from a document without disrupting your loop. You can use a loop to add or delete items but it will never break your script because you're only processing the array of items you created which doesn't change length like collections do.
And you can easily chain the above array prototypes to the end of the arrayFromContainer function.. So, to get an array of layer names, you can use
arrayFromContainer(doc, "layers").map(function(a){return a.name});
instead of:
var layerNames = [];
for(var i=0;i<doc.layers.length;i++)
{
layerNames.push(layers[i].name);
}
but... the pies de resistance.... avoiding writing explicit loops like this allows you to keep your variables in scope without declaring new variables inside a loop, which is known to increase the frequency of MRAP/PARM errors. I used to have a big block of variable declarations preceding every loop so that I could merely assign the variable inside the loop without declaring it. Something like this:
var ppLen = ppLay.layers.length;
var pieceLen, curLay, curSize, curCoords, thisPiece;
var curVb;
for (var ma = 0; ma < ppLen && result; ma++) {
curLay = ppLay.layers[ma];
curSize = ppLay.layers[ma].name;
pieceLen = curLay.groupItems.length;
if (!coords[curSize]) {
errorList.push("Could not find placement data for " + curSize + ".");
continue;
} else {
for (var p = 0; p < pieceLen; p++) {
thisPiece = curLay.groupItems[p];
if (thisPiece.name === "") {
unnamedPieces.push(thisPiece);
continue;
} else if (!coords[curSize][thisPiece.name]) {
errorList.push("Could not find placement data for " + thisPiece.name + ".\nThis piece has been skipped.");
continue;
}
curCoords = coords[curSize][thisPiece.name];
curVb = getVisibleBounds(thisPiece);
thisPiece.left = curCoords[0] - (curVb[0] - thisPiece.left);
thisPiece.top = curCoords[1] + (thisPiece.top - curVb[1]);
}
}
}
The result of this is that whatever function contains this logic has its scope cluttered up with variables that will only ever be used inside the loop.. (this problem is addressed in modern javascript with "let" which keeps the variable in block scope).
using the above array.prototypes, you can declare your variables inside the scope of the callback function you pass in, so they'll never interfere with anything else in the parent function, and they aren't technically being declared insid the loop so we're safe from most MRAP/PARM issues.
1 Correct answer
12
Replies
AdChoices