Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

Raskolnikov2089: Nov 3, 2006; Schizzy to the matic

Neat. I learned something new about .splice() and now I get to learn .serializeArray()

Thank you much

# ? Jul 26, 2014 22:31

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 21:00

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Newf posted:

I've done more javascript over the past week than in the rest of my life combined, and this sort of thing is driving me insane. I was two hours with this piece of jQuery, which would be plain skipped over by the debugger rather than even causing an error. As in, the debugging cursor would jump directly from the first line here to the further code below.

If you want the code to break inside the function, put your breakpoint on the exact row "alert($(this).text);", not on any earlier row.

Be careful that in standards mode, your selectors are case sensitive.

Also .ItemList > a means "any 'a' element that is the immediate child of an element with class='ItemList'"

so these will not work:

HTML code:

<div class="ItemList">
	<span>
		<a href="example.com">Hello</a>
	</span>
</div>

HTML code:

<div class="Itemlist"><!-- note the lower case L -->
	<a href="example.com">Hello</a>
</div>

# ? Jul 26, 2014 23:21

Dr. Poz: Sep 8, 2003; Dr. Poz just diagnosed you with a serious case of being a pussy. Now get back out there and hit them till you can't remember your kid's name.; Pillbug

I just ran into the fact that when instantiating a Date in JavaScript, the constructor parameter for Month is zero-based, meaning that a 1 means February. Is there a clean way to globally override this without making developers remember to use a derived type? I'm using TypeScript for this particular project if that makes a difference.

# ? Jul 29, 2014 19:32

Raskolnikov2089: Nov 3, 2006; Schizzy to the matic

So I have code that works, and it's driving me crazy that I'm not understanding how it works.

code:

	$('.aidInput').children('.amount').each(function(index){
		var checkInput = parseInt($(this.val));
		if(typeof checkInput ==="number"){
			amtofAid.push(parseInt($(this).val()));
		}
		else{
			amtofAid.push(NaN);
		}
	});

The above cycles through some text inputs, checks to see if they're a number after parseInt runs, and if so, pushes them to an array. Otherwise, it pushes NaN to the respective index.

It works like a charm, but I don't 100% remember why I wrote it this way. Specifically two things are confusing me:

1. When I console.log checkInput, it returns NaN for every input. Shouldn't it return the parseInt text value?

2. Why am I using .val instead of .val() in the var checkInput line?

**edit - ok, I'm realizing now that it was a syntax error it should have been:

code:

var checkInput = parseInt($(this).val());

Now it console.logs correctly, however I'd still like to know why my first instance of

code:

var checkInput = parseInt($(this.val));

worked.

**edit2 The Rabbit Hole Gets Deeper

code:

console.log(typeof checkInput);
console.log(checkInput);

If I use text instead of a number on one of the inputs, the first console.log still returns "number". However the second console.log returns NaN.

Raskolnikov2089 fucked around with this message at 19:59 on Jul 29, 2014

# ? Jul 29, 2014 19:37

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Raskolnikov2089 posted:

So I have code that works, and it's driving me crazy that I'm not understanding how it works.
code:
	$('.aidInput').children('.amount').each(function(index){
		var checkInput = parseInt($(this.val));
		if(typeof checkInput ==="number"){
			amtofAid.push(parseInt($(this).val()));
		}
		else{
			amtofAid.push(NaN);
		}
	});
The above cycles through some text inputs, checks to see if they're a number after parseInt runs, and if so, pushes them to an array. Otherwise, it pushes NaN to the respective index.

It works like a charm, but I don't 100% remember why I wrote it this way. Specifically two things are confusing me:

1. When I console.log checkInput, it returns NaN for every input. Shouldn't it return the parseInt text value?

2. Why am I using .val instead of .val() in the var checkInput line?

**edit - ok, I'm realizing now that it was a syntax error it should have been:
code:
var checkInput = parseInt($(this).val());
Now it console.logs correctly, however I'd still like to know why my first instance of
code:
var checkInput = parseInt($(this.val));
worked.

If by "worked" you mean "did not cause an error and returned NaN", then here is why:

JavaScript code:

$('.aidInput').children('.amount').each(function(index){
    // let us look at the three pieces going on in: parseInt($(this.val));
    console.log(this.val); // undefined
    console.log( $(undefined) ); //[] (an empty array, since you made a jQuery out of nothing)
    console.log( parseInt([]) ); // NaN, since an empty array is not an number
});

# ? Jul 29, 2014 19:58

Raskolnikov2089: Nov 3, 2006; Schizzy to the matic

Lumpy posted:

If by "worked" you mean "did not cause an error and returned NaN", then here is why:

JavaScript code:

$('.aidInput').children('.amount').each(function(index){
    // let us look at the three pieces going on in: parseInt($(this.val));
    console.log(this.val); // undefined
    console.log( $(undefined) ); //[] (an empty array, since you made a jQuery out of nothing)
    console.log( parseInt([]) ); // NaN, since an empty array is not an number
});

**edit - nevermind - should have googled first

http://stackoverflow.com/questions/2801601/why-does-typeof-nan-return-number

Well hell, time to rewrite a lot of code.

Good thing about painful lessons, you learn them really well.

Raskolnikov2089 fucked around with this message at 20:08 on Jul 29, 2014

# ? Jul 29, 2014 20:06

geeves: Sep 16, 2004

Dr. Poz posted:

I just ran into the fact that when instantiating a Date in JavaScript, the constructor parameter for Month is zero-based, meaning that a 1 means February. Is there a clean way to globally override this without making developers remember to use a derived type? I'm using TypeScript for this particular project if that makes a difference.

I've done this in the past as necessary. Drop this into a global JS file.

http://jsfiddle.net/VrU2a/

code:

Date.prototype.getRealMonth = function () {
    return this.getMonth() + 1;
};

# ? Jul 29, 2014 20:19

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I'd really recommend if you need to work with dates in JavaScript you get a library for it like 'moment'. Life is too short to gently caress around with the various blind spots in Date implementation, drop in 'moment' and be done with it. Its a really nice date time API anyway.

# ? Jul 30, 2014 02:18

Raskolnikov2089: Nov 3, 2006; Schizzy to the matic

Neverrrrrrrrrrrmind.

Well, that's two hours spent learning how important the typeof operator is.

Raskolnikov2089 fucked around with this message at 19:03 on Jul 30, 2014

# ? Jul 30, 2014 18:47

Raskolnikov2089: Nov 3, 2006; Schizzy to the matic

I'm back, to give the thread new life!

I have a recursive function, called by doEverything(). The recursive function should return a variable, remainOver, which should be accessible by doEverything(). The parameters are arbitrary ones I grabbed that make this undefined error result.

code:

var Loanarray = [{type:5, amt:1000}];

function recursion(overamt,end,total$,needArray){
	if(overamt <= 0 || end >= needArray.length){ 
		if(overamt < 0){  
			var remainder =(Math.abs(overamt));
			console.log('Can keep $' + remainder); 
		}
		else{
			var remainOver = overamt;
           		alert(remainOver);
			console.log('To be taken away $' + overamt);
		};
	}	
	else{
		overamt -= needArray[end].amt;
		total$ -= needArray[end].amt;
		needArray[end].amt = 0; 
		return overamt + recursion(overamt,end+1,total$,needArray);
	};
	return{
	remainOver: remainOver,
	};

}

function doEverything(){
    var result = recursion(10849,0,5000,Loanarray);
    var remainOver = result.remainOver;
    alert(remainOver);
}

doEverything();

Every drat thing I try returns undefined on that alert. I cannot for the life of me figure out why doEverything cannot access result.remainOver.

jsfiddle here: http://jsfiddle.net/L9QVh/1/

# ? Aug 5, 2014 00:08

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

return overamt+recursion(etc) is returning a string that says "9898[object]".

# ? Aug 5, 2014 00:40

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Raskolnikov2089 posted:

Every drat thing I try returns undefined on that alert. I cannot for the life of me figure out why doEverything cannot access result.remainOver.

jsfiddle here: http://jsfiddle.net/L9QVh/1/

I'm on my phone, so I haven't looked at your fiddle, but two things come immediately to mind:

One, each invocation of a function gets its own copy of variables. The outer invocation can't see into the inner's variables, which makes sense because when control returns to the outer the inner's variables are gone. (Closures can extend the liveness, but they aren't relevant here.) This means that if your outer wants to see the inner's result, the inner has to communicate that result explicitly, such as by returning that result.

Two, different paths through doEverything seem to return very different things semantically. One path returns a number (computed by adding overall to something else; sorry, phone), and the other returns an object with a single property.

I'll try to take a look at the fiddle later if I get a chance.

# ? Aug 5, 2014 00:47

Raskolnikov2089: Nov 3, 2006; Schizzy to the matic

Bruegels Fuckbooks posted:

return overamt+recursion(etc) is returning a string that says "9898[object]".

Which I guess makes sense because when I console.log(result) in doEverything(), it returns 9849[object Object].

However

code:

		else{
			var remainOver = overamt;
            		alert(typeof remainOver);
		};

returns number.

Also, how are you checking the typeof of the return value?

Subjunctive posted:

I'll try to take a look at the fiddle later if I get a chance.

Thanks! I need access to several variables from the recursive function

Doing it like:

code:

function doEverything(){
    var result = parseInt(recursion(10849,0,5000,Loanarray));
    var remainOver = result.remainOver;
    alert(typeof remainOver);
    console.log('this is the ' + result);
}

Is the best way I've found to pull variables from other functions, for use in functions down the line.

I'm not married to it, but it's the best way I understand for now.

Raskolnikov2089 fucked around with this message at 02:04 on Aug 5, 2014

# ? Aug 5, 2014 01:57

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

I think the point is you need to change

code:

return overamt + recursion(overamt,end+1,total$,needArray);

to something like

code:

var remainOver = overamt + recursion(overamt,end+1,total$,needArray).remainOver;

(and let the function return down below)

The problem with your first one is that the recursive call returns an object with one property, remainOver. In that first line there when you add them together javascript sees that you're trying to add a number to an object, which makes no sense. It forges on however, and converts both to a string, hence "9898[object]". In other words you're treating the return value as a number when its an object.

Also I didn't read it too closely but can't you just do this with a for loop?

Also I didn't know you could use $ in variable names in javascript. That's... odd

HappyHippo fucked around with this message at 02:49 on Aug 5, 2014

# ? Aug 5, 2014 02:43

This Post Sucks: Dec 27, 2004; It Gave Me Splinters!

Raskolnikov2089 posted:

I'm back, to give the thread new life!

I have a recursive function, called by doEverything(). The recursive function should return a variable, remainOver, which should be accessible by doEverything(). The parameters are arbitrary ones I grabbed that make this undefined error result.
code:
....
Every drat thing I try returns undefined on that alert. I cannot for the life of me figure out why doEverything cannot access result.remainOver.

jsfiddle here: http://jsfiddle.net/L9QVh/1/

You had a couple of problems in here. The main one you were trying to do was to access the local variable outside the scope of the recursion function as well as the following line:

code:

return overamt + recursion(overamt,end+1,total$,needArray)

Once you got in to your first conditional statements, you weren't returning any values:

code:

if(overamt <= 0 || end >= needArray.length){ 
		if(overamt < 0){  
			var remainder =(Math.abs(overamt));
			console.log('Can keep $' + remainder); 
		}
		else{
			var remainOver = overamt;
            alert(remainOver);
			console.log('To be taken away $' + overamt);
		};

so your " + recursion(overamt,end+1,total$,needArray)" was returning the alert object functions as [Object Object]s.

I whipped up a quick MVC version that will allow you to do pretty much what you were trying to do.
JS Fiddle here.

code:


var Loanarray = [{type:5, amt:1000}];

 var recursion = {
     remainOver: 0,
     init: function()
     {
          this.remainOver = 0;   
     },
     start: function (overamt, end, total$, needArray)
        {
       
            this.overamt = overamt,
            this.end = end,
            this.total$ = total$,
            this.needArray = needArray;
            this.run();
        },
         
        run: function ()
        {
            if (this.overamt <= 0 || this.end >= this.needArray.length)
            {
                if (this.overamt < 0)
                {
                    var remainder = (Math.abs(this.overamt));
                    console.log('Can keep $' + remainder);
                    return remainder;
                }
                else
                {
                    var remainOver = this.overamt;                    
                    console.log('To be taken away $' + remainOver);
                    return remainOver;
                };
            }
            else
            {
                
                this.overamt -= this.needArray[this.end].amt;
                this.total$ -= this.needArray[this.end].amt;
                this.needArray[this.end].amt = 0;
                this.end++;          
                this.remainOver =  this.overamt + this.run();
                
            };
        }
    }


function doEverything(){
    recursion.init();
    recursion.start(10849,0,5000,Loanarray);     
    var remainOver = recursion.remainOver;
    alert(remainOver);
}

doEverything();

So, what you're doing is making your recursion function an object, therefore you can access parts of that object afterwards. So, once you run the recursion.start method with your input variables, the recursion.remainOver variable will get set with whatever ran the last time you did it. Careful, though, if you want to use this more than once in a row, if you don't call the recursion.init() method, you'll just compound your previous number. If you are always wanting to start with a remainOver of 0, you could change the .start() function to:

code:

start: function (overamt, end, total$, needArray)
        {
       
            this.overamt = overamt,
            this.end = end,
            this.total$ = total$,
            this.needArray = needArray,
	    this.remainOver = 0;
            this.run();
        },

and remove the need to do a recursion.init() all together.

Hopefully that was kind of what you were looking for!
Cheers.

This Post Sucks fucked around with this message at 02:52 on Aug 5, 2014

# ? Aug 5, 2014 02:48

Raskolnikov2089: Nov 3, 2006; Schizzy to the matic

HappyHippo posted:

useful stuff

This Post Sucks posted:

also useful stuff

I'm going to need to digest this some. I might be back with more questions, but I think this is enough to get it going. I want to make sure I understand why.

HappyHippo posted:

Also I didn't read it too closely but can't you just do this with a for loop?

Depending on the needArray[x].type, I need to be able to track needArray[x].amt reductions from overamt & total$, as well as by amount. It's also important to re-add back any .amt(s) that are reduced by too much.

I'm working with different types of money with different strings attached, so when I started graphing out the nested for loops and if then statements that would be required, I thought recursion might be easier to unravel.

I might have thought wrong.

Raskolnikov2089 fucked around with this message at 04:08 on Aug 5, 2014

# ? Aug 5, 2014 03:57

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

HappyHippo posted:

Also I didn't know you could use $ in variable names in javascript. That's... odd

It was added when they added regexes to javascript. The most common place you will see it is probably jQuery: $('.whatever')

# ? Aug 5, 2014 06:11

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Wheany posted:

It was added when they added regexes to javascript. The most common place you will see it is probably jQuery: $('.whatever')

I think it was always legal, for symmetry with Java. It definitely predates regexps.

# ? Aug 5, 2014 06:21

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Raskolnikov2089 posted:

I'm working with different types of money with different strings attached, so when I started graphing out the nested for loops and if then statements that would be required, I thought recursion might be easier to unravel.

I might have thought wrong.

I tend to avoid recursion when I write javascript. In javascript, every time you make a recursive call, you make a new stack, and it's very easy to run into "max call stack size exceeded." Other languages avoid this using compiler optimizations, but in javascript you have to manually optimize to make fewer recursive calls.

# ? Aug 5, 2014 14:28

Zerok: Feb 23, 2014

Hello JavaScript question thread, this is my very first question here.

I will give you a bit of background about myself before I ask said question. I am mostly a Java programmer(~8 years worth of experience) with some knowledge of C++, C# and other more usual back end langage. A month ago, I had to pick up Javascript due to being in a startup and needing to do GUI. Our current framework of choice is Grails at the moment. My Javascript experience is very very limited. Last time I actually did some JS was back in college, so its been more than 10 years.

Now that the very brief background is done, ask more question about it as needed, here is the actual question per say.

A co-worker of mine is telling me and my other co-worker that we are basically coding JS like retards because we do not believe that stuff like the following code snippet is actually a nice and good solution.

code:

<input type="hidden" id="endDate" value="" />
<input type="hidden" id="startDate" value="" />
...

So he basically declare his variables this way in the hidden fields. My co-worker and I are doing it my basically declaring a Map of variables than we then use where needs be by passing it to JS functions, a bit like this:

code:

<script>
var mapOfVar = {startDate: d1, endDate: d2};
someFunction(mapOfVar);
</script>

To us this way looks cleaner, and our co-worker is not able to explain to us why his method is the supposed bomb and the standard of JS.

The only thing I can think of is because he can then call his variable anywhere in JS files with a call such as $.("#startDate").val()?

So my question for you guys, is the hidden input really a convention in JavaScript?

# ? Aug 6, 2014 02:11

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Bruegels Fuckbooks posted:

I tend to avoid recursion when I write javascript. In javascript, every time you make a recursive call, you make a new stack, and it's very easy to run into "max call stack size exceeded." Other languages avoid this using compiler optimizations, but in javascript you have to manually optimize to make fewer recursive calls.

In ES6 you get PTC, but this wasn't a case where there were calls in tail position. Out of tail position, there isn't really anything a compiler can do to optimize away stack frame creation in the general case.

Some kinds of JITs (tracing, at the limit) can minimize the amount of state preserved to be equivalent to the caller manually saving the overwritten state, but it's still over-general versus accumulating in a loop if that suits the algorithm.

Stack depth limits are pretty generous now on modern engines, and frames are made as lightweight as possible because initializing them is part of a very, very hot path. Unless your data set is likely to be very large or out of your control, I wouldn't avoid recursion on those grounds, personally.

# ? Aug 6, 2014 02:32

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Zerok posted:

So he basically declare his variables this way in the hidden fields. My co-worker and I are doing it my basically declaring a Map of variables than we then use where needs be by passing it to JS functions, a bit like this:
code:
<script>
var mapOfVar = {startDate: d1, endDate: d2};
someFunction(mapOfVar);
</script>
To us this way looks cleaner, and our co-worker is not able to explain to us why his method is the supposed bomb and the standard of JS.

The only thing I can think of is because he can then call his variable anywhere in JS files with a call such as $.("#startDate").val()?

So my question for you guys, is the hidden input really a convention in JavaScript?

Well, the hidden input really has nothing to do with javascript. Can you explain to me what "someFunction" does? One of those snippets is html and the other is js, they aren't really doing the same thing.

# ? Aug 6, 2014 04:06

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Zerok posted:

So my question for you guys, is the hidden input really a convention in JavaScript?

In both cases you're using them as sort of globals, it seems. If I had to choose from those two without any context, I would choose the native javascript object over the input elements, partly because setting and getting values from DOM nodes is slow and partly because they can only hold strings and not any kind of data.

If you're passing data back and forth between the browser and the server with the user clicking on submit buttons (a "traditional" forms based web app), and just using javascript to enhance the experience, then hidden input fields could be a decent solution.

# ? Aug 6, 2014 07:08

Zerok: Feb 23, 2014

down with slavery posted:

Well, the hidden input really has nothing to do with javascript. Can you explain to me what "someFunction" does? One of those snippets is html and the other is js, they aren't really doing the same thing.

Wheany posted:

In both cases you're using them as sort of globals, it seems. If I had to choose from those two without any context, I would choose the native javascript object over the input elements, partly because setting and getting values from DOM nodes is slow and partly because they can only hold strings and not any kind of data.

If you're passing data back and forth between the browser and the server with the user clicking on submit buttons (a "traditional" forms based web app), and just using javascript to enhance the experience, then hidden input fields could be a decent solution.

First of all thanks for the answers, I will try to details a bit more what we are doing.

In the case where I took the example, someFunction will basically do a REST get call to a web service on the server that will serve data for a chart. In both case, the variable, either by hidden input or by the map, are used to send filters (startDate, endDate, name, device etc...) to the query.

In essence we have an other JS file that will do the call to the web service with the JQuery getJSON call. In the complete of the call, we add the data to a HighCharts chart that we will then display.

More context:
Version with input

code:

// version with the map
someFunction = function(params) {
	var url = params.baseUrl + '?startDate=' + params.startDate + '&endDate=' + params.endDate
	$.getJSON().done( 
		//Code that will add the series/categories to HighCharts
	)

// version with the hidden input
someFunction = function(params) {
	var url = $.('#baseUrl').val() + '?startDate=' + $.('#startDate').val() + '&endDate=' + $.('#endDate').val()
	$.getJSON().done( 
		//Code that will add the series/categories to HighCharts
	)

In both case someFunction is called in a gsp file (grails server page) in the <script> tag of a $( document ).ready call. We basically want to load our chart when we end up on our page. We have a "Chart/Report" portal that provides a dozen charts that goes each individual pages.

Hope this help give more details/context.

# ? Aug 6, 2014 12:57

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Zerok posted:

In both case someFunction is called in a gsp file (grails server page) in the <script> tag of a $( document ).ready call. We basically want to load our chart when we end up on our page. We have a "Chart/Report" portal that provides a dozen charts that goes each individual pages.

Yeah, I would still go with the javascript object in this case.

# ? Aug 6, 2014 14:10

Zerok: Feb 23, 2014

Wheany posted:

Yeah, I would still go with the javascript object in this case.

Great! Thanks for the answer.

# ? Aug 6, 2014 19:33

Dr. Poz: Sep 8, 2003; Dr. Poz just diagnosed you with a serious case of being a pussy. Now get back out there and hit them till you can't remember your kid's name.; Pillbug

Maluco Marinero posted:

I'd really recommend if you need to work with dates in JavaScript you get a library for it like 'moment'. Life is too short to gently caress around with the various blind spots in Date implementation, drop in 'moment' and be done with it. Its a really nice date time API anyway.

Just wanted to say that this was a gem of advice. Using moment simplified a couple things I ran up against. Thanks for your help with this stuff Maluco.

# ? Aug 6, 2014 20:59

Malfeasible: Sep 10, 2005; The sworn enemy of Florin

Wheany posted:

In both cases you're using them as sort of globals, it seems. If I had to choose from those two without any context, I would choose the native javascript object over the input elements, partly because setting and getting values from DOM nodes is slow and partly because they can only hold strings and not any kind of data.

If you're passing data back and forth between the browser and the server with the user clicking on submit buttons (a "traditional" forms based web app), and just using javascript to enhance the experience, then hidden input fields could be a decent solution.

Hidden fields make sense if you want to send data to the server, but I try to avoid using inputs, visible or otherwise, if they aren't needed.

Don't forget that localStorage, sessionStorage, and hidden fields could store an object using JSON.stringify to serialize it first. You can use JSON.parse to deserialize it and persist an object across page loads with sessionStorage, for example.

# ? Aug 7, 2014 04:02

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

I don't remember what I was doing, but the other day I ran into the arguments keyword and I feel like I've just fallen down the rabbit hole. I've always known that Javascript is a "prototype based language," and that "functions are first class objects," but I don't think I really "get" what any of that means. With arguments, it seems that function overloading doesn't work the same way that it does in object-oriented languages -- I can call a function with whatever arguments I want and welp, YOLO.

So my question is, where should I go from here? Is this elementary stuff that I should know, implying that I need to pick up an actual Javascript book and start from the beginning? Or is it more esoteric than that? Either way, it makes sense now, but I'd like to know what else I don't know, so I'm looking for some suggestions to study up on.

# ? Aug 14, 2014 03:43

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Kobayashi posted:

So my question is, where should I go from here? Is this elementary stuff that I should know, implying that I need to pick up an actual Javascript book and start from the beginning?

Here is a good start: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects

# ? Aug 14, 2014 04:01

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

down with slavery posted:

Here is a good start: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects

So basic stuff then, heh.

# ? Aug 14, 2014 04:21

Skiant: Mar 10, 2013

Kobayashi posted:

I don't remember what I was doing, but the other day I ran into the arguments keyword and I feel like I've just fallen down the rabbit hole. I've always known that Javascript is a "prototype based language," and that "functions are first class objects," but I don't think I really "get" what any of that means. With arguments, it seems that function overloading doesn't work the same way that it does in object-oriented languages -- I can call a function with whatever arguments I want and welp, YOLO.

So my question is, where should I go from here? Is this elementary stuff that I should know, implying that I need to pick up an actual Javascript book and start from the beginning? Or is it more esoteric than that? Either way, it makes sense now, but I'd like to know what else I don't know, so I'm looking for some suggestions to study up on.

Secrets of the Javascript ninja or Javascript Allong� might be good reads.

# ? Aug 14, 2014 13:48

spiritual bypass: Feb 19, 2008; Grimey Drawer

The Principles of Object Oriented Javascript is a nice short read that'll teach you a ton. I also second the recommendation of the two books in the last post.

# ? Aug 14, 2014 15:07

qntm: Jun 17, 2009

Skiant posted:

Secrets of the Javascript ninja

Which has a samurai on the cover...

# ? Aug 14, 2014 15:11

Peanut and the Gang: Aug 24, 2009; by exmarx

qntm posted:

Which has a samurai on the cover...

Lmbo.

# ? Aug 14, 2014 15:38

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Kobayashi posted:

I don't remember what I was doing, but the other day I ran into the arguments keyword and I feel like I've just fallen down the rabbit hole. I've always known that Javascript is a "prototype based language," and that "functions are first class objects," but I don't think I really "get" what any of that means. With arguments, it seems that function overloading doesn't work the same way that it does in object-oriented languages -- I can call a function with whatever arguments I want and welp, YOLO.

So my question is, where should I go from here? Is this elementary stuff that I should know, implying that I need to pick up an actual Javascript book and start from the beginning? Or is it more esoteric than that? Either way, it makes sense now, but I'd like to know what else I don't know, so I'm looking for some suggestions to study up on.

If you're not scared of reading something that's a little technical, I found this page pretty enlightening. It's pretty short but dense. It's ostensibly about closures, but along the way it explains prototypes, scopes, execution contexts, garbage collection, etc. If you can follow the whole thing you'll understand a lot about javascript.

# ? Aug 14, 2014 15:48

The March Hare: Oct 15, 2006; _{Je r�ve d'un}
Wayne's World 3; Buglord

qntm posted:

Which has a samurai on the cover...

That's the secret.

# ? Aug 14, 2014 16:50

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

down with slavery posted:

Here is a good start: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects

What I got out of that is that essentially everything in Javascript is an associative array. I suppose I'll read some of those book recommendations now!

# ? Aug 14, 2014 23:47

Skiant: Mar 10, 2013

qntm posted:

Which has a samurai on the cover...

They have almost a whole page inside explaining that they know the difference for assholes like you.

# ? Aug 15, 2014 06:53

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 21:00

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Kobayashi posted:

What I got out of that is that essentially everything in Javascript is an associative array. I suppose I'll read some of those book recommendations now!

Well, one syntax for accessing object properties looks like PHP's associative arrays, but they're not the same thing. The preferred notation for directly accessing object properties is using the dot notation, not the bracket notation.

# ? Aug 15, 2014 08:20

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »