|
Raskolnikov2089 posted:Urgh. Long day What Sedro said. Here's a visual confirmation: http://jsfiddle.net/tr6abac4/10/ You'll notice that, in at least chrome, you can get it to display DIFFERENT THINGS based on WHEN you inspect the object. If you load that link, then "open up" your object before pressing the button, you'll see the initial values. If you then press the button, you'll see a 2nd log with the updated values while the first log still shows the "old" ones. If you reload and do not "drill down" into the array in the console and immediately press the button, the first log will show the updated "new" values as well! This is because it's lazily getting the state of the stuff in the array only when you ask for it. That's why the console will give you the "correct" value when you specified myArray[0].amount: it went and looked up the value at that moment.
|
# ? Feb 18, 2015 01:02 |
|
|
# ? May 16, 2024 10:28 |
|
Lumpy posted:What Sedro said. Here's a visual confirmation: http://jsfiddle.net/tr6abac4/10/ That is so cool. Thank you guys.
|
# ? Feb 18, 2015 02:07 |
|
code:
is frequently found in my scripts.
|
# ? Feb 18, 2015 02:13 |
|
Raskolnikov2089 posted:That is so cool. Thank you guys. An interesting side effect is that printing an object to the console will prevent it from being garbage collected (depending on the browser)
|
# ? Feb 18, 2015 05:14 |
|
is this annoyingcode:
PleasureKevin fucked around with this message at 20:09 on Feb 18, 2015 |
# ? Feb 18, 2015 20:05 |
|
PleasureKevin posted:is this annoying The first passes the (anonymous) function which calls replaceImages() to spread(). The second passes whatever is returned by replaceImages() to spread(). These are very different things. e: That is, spread() here wants a function to be passed into it. replaceImages(article, meta) isn't a function - it's a function call, and it returns something else (possibly null) which is what gets passed into [fixed]spread()[fixed]. Newf fucked around with this message at 20:26 on Feb 18, 2015 |
# ? Feb 18, 2015 20:19 |
|
You probably meant to do this:JavaScript code:
|
# ? Feb 18, 2015 20:22 |
|
JavaScript code:
|
# ? Feb 18, 2015 20:28 |
|
Sedro posted:You probably meant to do this: oh, yeah thanks
|
# ? Feb 18, 2015 20:28 |
|
I have a Sharepoint Javascript CSOM question: how can I view all of a ListItem's fields if I don't know any of the field names? I created a Discussion list in a site I'm working on and I'm not exactly sure what other fields I have access to beyond "Title". I've output a ListItem to the console but it's just so incredibly deep hierarchy-wise that it's almost impossible make heads or tails of it. I'm stuck using CSOM API calls like get_item("name") to retrieve the info I want. Edit: The answer is ListItemCollection.itemAt(0).get_fieldValues(); IAmKale fucked around with this message at 22:01 on Feb 19, 2015 |
# ? Feb 19, 2015 19:34 |
|
necrotic posted:
|
# ? Feb 19, 2015 19:46 |
|
Misogynist posted:article and meta are undefined in this scope Oh, of course.
|
# ? Feb 20, 2015 02:45 |
|
Karthe posted:get_fieldValues(); Oh wow, try choosing a naming convention.
|
# ? Feb 21, 2015 11:05 |
|
Lots of js libraries have methods / constructors that take (sometimes) large configuration objects as parameters. Eg, a circle drawing method might have a signature DrawingLib.drawCircle(options) where options is an object of the form { center_x : 12, center_y : 10, radius : 4, color : ... }, where all of the parametrization values are optional and have default values when not set. Does this technique have a name or a set of best practices which I could research?
|
# ? Feb 24, 2015 03:14 |
|
Wheany posted:Oh wow, try choosing a naming convention. verb_adjectiveNoun is a convention
|
# ? Feb 24, 2015 03:15 |
|
Newf posted:Lots of js libraries have methods / constructors that take (sometimes) large configuration objects as parameters. Eg, a circle drawing method might have a signature DrawingLib.drawCircle(options) where options is an object of the form { center_x : 12, center_y : 10, radius : 4, color : ... }, where all of the parametrization values are optional and have default values when not set. It's sort of like named parameters in other languages because you can use an object literal when calling the function. Edit: In case that wasn't clear, you just call the function like DrawingLib.drawCircle({center_x : 12, center_y : 10, radius : 4, color : ... }) instead of making a new object. HappyHippo fucked around with this message at 16:56 on Feb 24, 2015 |
# ? Feb 24, 2015 03:23 |
|
Newf posted:Lots of js libraries have methods / constructors that take (sometimes) large configuration objects as parameters. Eg, a circle drawing method might have a signature DrawingLib.drawCircle(options) where options is an object of the form { center_x : 12, center_y : 10, radius : 4, color : ... }, where all of the parametrization values are optional and have default values when not set. Ruby calls this hash args, but I'm not aware of any other names. As far as best practices, don't require too many parameters, provide sane defaults, limit the number of required arguments, and put the required arguments before the options hash (i.e. DrawingLib.drawCircle(center_x, center_y, options) if you required both center_x and center_y.
|
# ? Feb 24, 2015 16:07 |
|
Does it seem like a good idea to throw the default values into an options property in the constructor? Or is there some way to punt it to the prototype (yadda yadda saving memory)?JavaScript code:
|
# ? Feb 25, 2015 02:09 |
|
Newf posted:
You can also do it the other way around, because I have an irrational hatred for comments when it could be written more obviously: JavaScript code:
Ranzear fucked around with this message at 03:09 on Feb 25, 2015 |
# ? Feb 25, 2015 03:00 |
|
Ranzear posted:
Guarantees no errors (as options.hasOwnProperty can be changed). I've started going with Object.keys to remove that dumb loving call. Downside is the scope change, but in most cases it's not that bad. code:
|
# ? Feb 25, 2015 07:38 |
|
necrotic posted:Guarantees no errors (as options.hasOwnProperty can be changed). Object.prototype.hasOwnProperty = function () {alert('butts')} For default values, I prefer the || operator: JavaScript code:
|
# ? Feb 25, 2015 09:34 |
|
Wheany posted:Object.prototype.hasOwnProperty = function () {alert('butts')} Ah, this is great, and not at all what I would have expected to happen with || (eg, I would have expected it return true/false). This more or less replaces the null coalescing operator and slots in nicely with what I'd like to do. Thanks much all.
|
# ? Feb 25, 2015 15:50 |
|
ES6 allows your defaults to appear in the function args: function spud(blah = 'default')
|
# ? Feb 25, 2015 15:56 |
|
necrotic posted:Guarantees no errors (as options.hasOwnProperty can be changed). At the limit, Object.prototype.hasOwnProperty can be changed as well, of course, but it's rarer and usually compatible when things like that happen.
|
# ? Feb 25, 2015 16:17 |
|
Subjunctive posted:At the limit, Object.prototype.hasOwnProperty can be changed as well, of course, but it's rarer and usually compatible when things like that happen. Yeah, that's true, but if you use something like jQuery you would notice very quickly if the root Object.prototype.hasOwnProperty was overridden (unless you changed it after including, I guess). Most of the time its not a problem anyway, but its good to understand why it can be an issue.
|
# ? Feb 25, 2015 17:06 |
|
Does anything change hasOwnProperty anywhere? Or are you defending against var butt = Object.create(null) when you use hasOwnProperty from the object prototype? Does anything use that?
|
# ? Feb 25, 2015 22:01 |
|
Wheany posted:Does anything change hasOwnProperty anywhere? Sounds like a good way to break a lot of poo poo needlessly. Of course nothing guarantees no errors, but his old code would have just errored. Because I'm super lazy, I proto 'hasOwnProperty' into just 'has'. If memory is an issue, you're probably missing hardware acceleration and other poo poo you'll need to run my code anyway. Ranzear fucked around with this message at 22:22 on Feb 25, 2015 |
# ? Feb 25, 2015 22:20 |
|
Wheany posted:Does anything change hasOwnProperty anywhere? Maybe like, evil.js. But nobody would seriously do it. Just use Object.keys, though. It ensures you get only the actual properties of the object, not crap from the prototype chain.
|
# ? Feb 25, 2015 22:40 |
|
necrotic posted:Just use Object.keys, though. It ensures you get only the actual properties of the object, not crap from the prototype chain. hasOwnProperty ignores prototype chain. Thats what the 'own' part means. It's also crazy optimized in just about every setting. If you're using Object.keys you're wasting time and lines to then have to iterate it. It really doesn't matter performance wise, and you'll cut the iteration for a single hasOwnProp lookup which is redundant in that bench, so go with what's most obvious and readable. If you've got proto chain problems, stop using crutch and kludge libraries. ES5+ES6 shim at worst. Ranzear fucked around with this message at 18:29 on Feb 28, 2015 |
# ? Feb 28, 2015 18:23 |
|
Ranzear posted:
I advise against modifying the content of an object passed into a function. This has side-effects which are visible to the caller. The most obvious time when this is a problem is if someone wants to use the same collection of options to create several different Circles objects.
|
# ? Feb 28, 2015 19:50 |
|
qntm posted:if someone wants to use the same collection of options to create several different Circles objects. I'm not seeing the argument, because they'd be getting the same defaults, and those defaults filling in for sparse parameters were the only reason an options object was being passed and created in the first place. You could also just not be lazy and pass everything as regular parameters.
|
# ? Feb 28, 2015 23:15 |
|
The real point is that you don't know what the caller is using the object for, and mutating it is likely to surprise them. (Or throw if they pass something immutable.)
|
# ? Feb 28, 2015 23:21 |
|
First super basic question I'll ask but not the last!code:
|
# ? Feb 28, 2015 23:54 |
|
Because then that function will be created again every time you create an Animal object. Putting it on the Animal prototype means you just have to walk up the prototype chain to get to sayName() instead of using one of n different versions of sayName().
|
# ? Mar 1, 2015 00:14 |
|
Is there a drawback to using setTimeout with a delay of 0 compared to requestAnimationFrame, when I want something to happen once, asynchronously, some time in the very near future? I used the code from this page https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery to asyncronously load two css files. The problem browser in this case is Google's own Chrome, though. I have a small index.html and a spinner graphic that take less than 2 seconds to load even on the slowest network emulation in Chrome (GPRS). The spinner is visible until the main javascript (and CSS) are loaded and initialized (they are several hundreds of kB, so on a slow connection it will take a while). If I use the snippet in the above link, Chrome will take somewhere close to 15 seconds to show the spinner (from the network tab in the developer tools it seems that it waits for the CSS files to be done loading ) If I just replace the raf(cb) from the code with a setTimeout(cb, 0), Chrome will show my spinner just fine. Firefox and IE both work in either case. (Using Sloppy to simulate a slow connection)
|
# ? Mar 2, 2015 15:43 |
|
If I have to guess, I'd say that Chrome runs the requestAnimationFrame, then notices that suddenly there are two new CSS files to be downloaded, so it can't draw on the screen now, it'll have to redraw the screen after the files have downloaded!!! But with the 0-timeout it will probably actually call the code even tens of milliseconds later and has had time to draw the screen already.
|
# ? Mar 2, 2015 15:51 |
|
requestAnimationFrame will get you 16ms later, and only if your web page isn't switched away on another tab, the user hasn't minimized the window, etc.
|
# ? Mar 2, 2015 18:03 |
|
In this case the only benefit, as far as I can tell, is that you don't have to remember the order of the delay and the callback arguments. The linked script uses window.addEventListener('load', cb) as the fallback, which makes me wonder if the head tag doesn't exist in some browsers until the page has been fully loaded. But then I feel like those browsers probably wouldn't support addEventListener anyways. So it could be that google engineers just thought that JavaScript code:
code:
|
# ? Mar 2, 2015 19:33 |
|
<head> doesn't execute scripts until fully loaded, hence the inlining of scripts for faster execution. The use of RAF is for at least one render, i.e. a pseudo-DOMReady() event handler. setTimeout(0) is always useful as a yield function as Javascript is a co-operative environment in a single thread.
|
# ? Mar 2, 2015 19:45 |
|
|
# ? May 16, 2024 10:28 |
|
Does Javascript have any image processing libraries similar to PIL/Pillow for Python? Or anything that will let me break an animated gif down into individual frame bitmaps. I want to do it client-side if I can, I know you can run something like ImageMagick on a server
|
# ? Mar 2, 2015 19:59 |