You should pick either passing in all the variables as arguments, or fully using closure - doing a mix of both is confusing, and is going to be the reason for your bug - you have two different cacheArray variables, and you're not assigning the inner one to the outer one.

What does alldates.txt contain?

If it's already an array then you can just do:

var cacheArray = JSON.parse(string).map
	(function(item){
		return item.replace(/100315/,'$&/thumbs');
	});

If the Object.values is needed you can still use map:

var cacheArray = Object.values(alldatesobj).map
	(function(item){
		return item.replace(/100315/,'$&/thumbs';
	});

The $& means whatever is matched (pretty much everyone else uses $0 or \0 but JS has to be awkward).

Also, on a general note, you can't trust console.log in modern browsers - they do not tell you a variable's value at the point when you're logging it but have started looking it up after - you need to use console.log(JSON.stringify(variabletolog)) to freeze it and get a correct report.

Quote:  Yeah that works! (bounce)

I had read about the map function, but according to some folks somewhere on the internet, it should not be needed and costs more cpu cycles (or something).
 
It's an array with key-value pairs, keys are 4-digit dates (mmdd), values are image names (*.jpg) used to display a specific new image each day here:
http://designartcraft.com/photo/afbp.htm and randomly here:
http://designartcraft.com/photo/random.html


The purpose of all this is to cache thumbs (same names, in "/thumbs") for offline.

I'm slowly trying to get up to speed on modren javascript syntax without relying on jquery (which doesn't work in service workers). Long ways to go, obviously.

Thanks!

 

> it should not be needed and costs more cpu cycles (or something).

The same can be said for anything that isn't assembly language.

There's no situation where map is necessary - it can always be replaced with a loop - but there's plenty of situations when it makes code easier to understand and work with, and that should generally be the primary concern for the first iteration of any code. (Which isn't to say always use map - it's possible to misuse just like any construct - but don't be afraid to use it when suitable.)

Performance matters when you can show the difference - if a web script takes half a second to run, then absolutely spend some time to identify and optimise the slowest aspect (and that's not always the most obvious one), but if its 38ms vs 35ms then it's less likely to matter.

> I'm slowly trying to get up to speed on modren javascript syntax without relying on jquery

I recently decided to write a jquery-free library for scattering images, and it's interesting to see what's now possible and how browser vendors have still managed to over-complicate simple tasks.

I found MDN to be the best resource, although sometimes you need to know what to look for first - definitely useful for getting the right polyfills if you want to support older browsers whilst still using modern methods.

I'm using MDN quite a lot. Explanations are sparse, useful examples rare, and there's an assumption of underlying familiarity with syntax that can make it pretty difficult to follow.

What is polyfill?

It's the thick paste you use on walls to smooth over cracks.

It's also when you re-implement native functionality from newer browsers in JavaScript for the benefit of older browsers - see for example the Array.prototype.map polyfill.

> Explanations are sparse

I prefer the term concise - no need to dredge through unnecessary waffle to figure out what something does.

> useful examples rare

Possibly. On most sites I tend towards going straight to the examples because the explanations are waffle, but don't need to with MDN.

> there's an assumption of underlying familiarity

That'll be because it's mostly a reference.

There is a JavaScript Guide which appears very comprehensive, but looking at a few pages it does a horrific job of explaining stuff and has some terrible examples, so, yeah... that sucks. :/