|
Neat. I learned something new about .splice() and now I get to learn .serializeArray() Thank you much
|
# ? Jul 26, 2014 22:31 |
|
|
# ? Jun 5, 2024 07:51 |
|
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:
HTML code:
|
# ? Jul 26, 2014 23:21 |
|
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 |
|
So I have code that works, and it's driving me crazy that I'm not understanding how it works.code:
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:
code:
**edit2 The Rabbit Hole Gets Deeper code:
Raskolnikov2089 fucked around with this message at 19:59 on Jul 29, 2014 |
# ? Jul 29, 2014 19:37 |
|
Raskolnikov2089 posted:So I have code that works, and it's driving me crazy that I'm not understanding how it works. If by "worked" you mean "did not cause an error and returned NaN", then here is why: JavaScript code:
|
# ? Jul 29, 2014 19:58 |
|
Lumpy posted:If by "worked" you mean "did not cause an error and returned NaN", then here is why: **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 |
|
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:
|
# ? Jul 29, 2014 20:19 |
|
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 |
|
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 |
|
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:
jsfiddle here: http://jsfiddle.net/L9QVh/1/
|
# ? Aug 5, 2014 00:08 |
|
return overamt+recursion(etc) is returning a string that says "9898[object]".
|
# ? Aug 5, 2014 00:40 |
|
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. 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 |
|
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:
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:
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 |
|
I think the point is you need to change code:
code:
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 |
|
Raskolnikov2089 posted:I'm back, to give the thread new life! 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:
code:
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:
code:
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 |
|
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 |
|
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 |
|
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 |
|
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 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 |
|
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:
code:
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 |
|
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 |
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: 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 |
|
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 |
|
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. 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:
Hope this help give more details/context.
|
# ? Aug 6, 2014 12:57 |
|
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 |
|
Wheany posted:Yeah, I would still go with the javascript object in this case. Great! Thanks for the answer.
|
# ? Aug 6, 2014 19:33 |
|
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 |
|
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. 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 |
|
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 |
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 |
|
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 |
|
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. Secrets of the Javascript ninja or Javascript Allongé might be good reads.
|
# ? Aug 14, 2014 13:48 |
|
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 |
|
Which has a samurai on the cover...
|
# ? Aug 14, 2014 15:11 |
|
qntm posted:Which has a samurai on the cover... Lmbo.
|
# ? Aug 14, 2014 15:38 |
|
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. 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 |
|
qntm posted:Which has a samurai on the cover... That's the secret.
|
# ? Aug 14, 2014 16:50 |
|
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 |
|
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 |
|
|
# ? Jun 5, 2024 07:51 |
|
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 |