|
I received some JS code and it won't compile. On closer look it's got some non-standard "commands" peppered through it that remind me of placeholders from web templating, or maybe from compiled JS like TypeScript. I don't know how to tell. What do you all make of this?code:
|
# ? May 5, 2019 23:01 |
|
|
# ? Jun 3, 2024 23:29 |
|
huhu posted:I just converted my project to Typescript. Almost done playing whack-a-mole but I'm stumped by the following errors: quote:And a second issue. I've got the following: Declare a type for this.queue somewhere. I like to put it above my constructor. Something like queue:Queue
|
# ? May 6, 2019 01:31 |
|
Dumb Lowtax posted:I received some JS code and it won't compile. On closer look it's got some non-standard "commands" peppered through it that remind me of placeholders from web templating, or maybe from compiled JS like TypeScript. I don't know how to tell. What do you all make of this? private class fields https://github.com/tc39/proposal-class-fields#private-fields
|
# ? May 6, 2019 01:50 |
|
More fundamentally misled questions about async and await coming up. DoesJavaScript code:
JavaScript code:
|
# ? May 6, 2019 06:50 |
|
Newf posted:More fundamentally misled questions about async and await coming up. Does That await isn't doing anything, it's just building an array of promises. What you probably want is: JavaScript code:
Nolgthorn fucked around with this message at 11:05 on May 6, 2019 |
# ? May 6, 2019 11:02 |
|
Async/await is nice syntax for promises. It does nothing else to the language. You can await any promise (as in that all example), but not an array itself as that is not a promise. The fetch feature is the only core JS feature I'm aware of that itself returns a promise and can work with await without any wrapping.
|
# ? May 6, 2019 14:19 |
|
code:
Also since I'm doing this in React, for some reason putting that anonymous function in the onClick of the span tag makes the whole thing re-render as soon as it loads. I noticed that if I just have a function in there, it will load as soon as the page first renders. Seems odd.
|
# ? May 6, 2019 15:54 |
|
LifeLynx posted:
I'm 100% sure I'm doing the type annotations right here but I would explicitly pass in the event to the handler (because I hate having to think about what this is): code:
|
# ? May 6, 2019 16:18 |
|
LifeLynx posted:
Arrow notation functions in JS keep the this context. As such, this will be defined as whatever it was in the render function, which probably isn't what you want. Directly pass the ClickHandler function (without parentheses) and you'll be fine code:
|
# ? May 6, 2019 16:29 |
|
LifeLynx posted:
When you put an anon function inside an event handler, it creates a new function each time, and that causes the re-render. So don't do that if you don't want that to happen.
|
# ? May 6, 2019 16:38 |
|
Lumpy posted:When you put an anon function inside an event handler, it creates a new function each time, and that causes the re-render. So don't do that if you don't want that to happen. Is there a reason for that behavior? Seems strange. I also don't know why this doesn't work: code:
code:
|
# ? May 6, 2019 22:46 |
|
It shouldn't by itself cause a re-render, but it does create a new function which can be a performance issue. Same reason you shouldn't create an anonymous function inside of a for loop. edit: that second one is referring to the click function but not actually invoking it. Even if it was the this inside the function your calling would be window and not the event target. MDN has a good article on this and how it works https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this Not sure why the first wouldn't work but I've never tried using inline-functions like that with react. necrotic fucked around with this message at 23:04 on May 6, 2019 |
# ? May 6, 2019 22:59 |
|
LifeLynx posted:Is there a reason for that behavior? Seems strange. The reason for the behavior: JavaScript code:
JavaScript code:
And the reason the two onClicks above don't work, assuming they are written that way exactly, is in the first instance you have 'this' binding problems, and in the second, you are simply stating 'ClickHandler', not actually calling it. Plus it will probably have 'this' binding problems as well. Javascript is a fun language.
|
# ? May 7, 2019 11:35 |
|
Lumpy posted:The reason for the behavior: Careful with terms, this causes the vDOM to see it as a change (and write it to the real DOM) but does not by itself cause a re-render of the react tree (a trigger of the render function). That requires a prop, state or hook value to change (for a functional component). If a function definition like that caused a re-render it'd be an infinite loop and literally unusable. edit: your examples are functionally equivalent if the const definition is in the render function. necrotic fucked around with this message at 13:31 on May 7, 2019 |
# ? May 7, 2019 13:29 |
|
Lumpy posted:The reason for the behavior: Oh okay, I see why React would need to re-render there. New code, same problems. The funny thing is I've seen what I believe to be this exact solution posted on Stack Overflow... it just doesn't work for me. "TypeError: Cannot read property 'handleClick' of undefined". code:
|
# ? May 7, 2019 13:32 |
|
The handler function is not defined as a property of an object, remove the this when calling it. And you still are not referring to the clicked card in anyway when calling the handler. Also load the json outside of the react component, dont do it inside a render function ever.
|
# ? May 7, 2019 13:38 |
|
necrotic posted:Careful with terms, this causes the vDOM to see it as a change (and write it to the real DOM) but does not by itself cause a re-render of the react tree (a trigger of the render function). That requires a prop, state or hook value to change (for a functional component). Good point, and a reminder why I shouldn't post before coffee.
|
# ? May 7, 2019 13:44 |
|
LifeLynx posted:Thanks for answering my dumb questions, this thread has been more helpful than even Stack Overflow. I'm used to "this" automatically knowing what element it's referring to. Remember how I said I don't like to have to constantly think about what this refers to? You're learning why.
|
# ? May 7, 2019 15:51 |
|
necrotic posted:Not sure why the first wouldn't work but I've never tried using inline-functions like that with react. Oh, right. A normal function definition doesn't bind this to the parent context's this. So same as the previous examples the this in the handler is referring to the global object (window). Munkeymon posted:Remember how I said I don't like to have to constantly think about what this refers to? You're learning why. Yeah, this. Arrow functions have made it a lot easier to work with at least.
|
# ? May 7, 2019 16:00 |
|
I ended up doing what I wanted to do by putting handleClick inside the functional component, like this:code:
|
# ? May 7, 2019 16:39 |
|
What is the current hotness in IDE for javascript? I've been bumbling through on my toy projects with emacs and the chrome console, but I think at some point I may want to upgrade a bit.
|
# ? May 7, 2019 17:37 |
ulmont posted:What is the current hotness in IDE for javascript? I've been bumbling through on my toy projects with emacs and the chrome console, but I think at some point I may want to upgrade a bit. Vscode.
|
|
# ? May 7, 2019 17:39 |
|
Webstorm (or any Jetbrains IDE)
|
# ? May 7, 2019 18:12 |
|
ulmont posted:What is the current hotness in IDE for javascript? I've been bumbling through on my toy projects with emacs and the chrome console, but I think at some point I may want to upgrade a bit. If you're working on typescript I've found emacs to be pretty needs suiting, but for plain javascript VSCode is really fantastic.
|
# ? May 7, 2019 21:51 |
|
Tanners posted:If you're working on typescript I've found emacs to be pretty needs suiting, but for plain javascript VSCode is really fantastic. VSCode is fantastic for TS as well...as you'd expect. (i prefer jetbrains IDEs tho)
|
# ? May 7, 2019 21:56 |
|
This seems like a good place for this rant, even though it's not directly JS/TS - today I learned that Dart is a stupid language for chumps. Because it's touted as type-safe, but unlike Typescript literally anything can be null whenever it feels like it. List of strings? More like null or list of null-or-strings! Hope you like handling all possible null cases in all your functions every loving time! I'd been using it for several weeks at work under the impression that it was like Typescript where a type means what you say, and today a reviewer suggested I might want to include tests for what my function does if my list of objects contains nulls and I like was "wait, what the gently caress, my list can contain nulls?" I thought the reviewer was mistaken, but no, the language really is that poo poo. And I mean it's not "can contain nulls" like you can coerce Typescript into doing, it's just flat out happy to accept ["foo", null, "bar"] as a parameter of type List<String>. I realize Javascript is happy to mix nulls and things too, but that's 100% dynamic typing, Javascript doesn't claim to be type safe so it's expected. Dart is mostly even more type safe oriented than Typescript, but then it goes and pulls this loving nonsense, what the gently caress. Don't use Dart. (Even Javascript can do compile-time null-rejection if you use the Closure compiler and ask for non-nullable types!) roomforthetuna fucked around with this message at 02:19 on May 8, 2019 |
# ? May 8, 2019 02:17 |
|
Dart was originally a dynamically typed language that was supposed to replace JavaScript in browsers, before they cast Raise Undead on it.
|
# ? May 8, 2019 03:08 |
|
I used dart in a flutter project recently and it wasnt that bad. I was just learning flutter and dart so the code i wrote was very much not pretty, but for the most part things worked as expected.
|
# ? May 8, 2019 04:14 |
|
Volguus posted:I used dart in a flutter project recently and it wasnt that bad. I was just learning flutter and dart so the code i wrote was very much not pretty, but for the most part things worked as expected. It's barely better than Javascript at that point, in that as you say "for the most part things work as expected". Allowing surprise nulls is just a loving travesty though for a typed language. I'm using it for Flutter too, which is quite a hefty paradigm shift from any other UI stuff I've done, gives it a bit of a steep learning curve for doing anything advanced, but I don't mind that. I wouldn't even really mind the null thing if it wasn't just so obnoxious. Unexpected nulls are barely even a thing in C++ for the last 8 years, who would make a new language and let them be a thing? It'd also be okay for small solo projects where I can be confident I won't pass myself null values, but for team things you've gotta handle any edge cases your functions make possible that some jackwagon might do, which means basically every function has to begin with "assert(arg!= null); assert(!listArg.contains(null));" which is stupid as gently caress. (Or you have to make a crapload of use of the "?." and "??" operators, which would be wonderful operators for using on parameters that you've described as null-or-a-type.) In other newish languages that completely gently caress up handling of nulls: Go (click Run, then compare main() against the output, the rest of the stuff is just there as a sort of vaguely-realistic setup for that lovely behavior.)
|
# ? May 8, 2019 05:09 |
|
I'm pretty sure all of these "compile to javascript" languages are on their way out as using just javascript seems to be the better option every single time. And as a result, instead, we are seeing the emergence of WebAssembly which will just let you program in whatever language you want. Please god no more "compile to javascript" ty.
|
# ? May 8, 2019 12:55 |
|
Dart was kind of a mashup of Java and JS, so I'm not sure why you'd expect it to be any better about non-null types than those languages. Rust and Kotlin are the two up-and-coming languages I can think of that even have them, with C# getting them soonish. Hell, maybe Java got them in 9, but I'm not up on new Java features. Not that I'm defending Dart here - just kinda baffled that anyone is expecting it to be better about null handling than its ancestors.
|
# ? May 8, 2019 14:32 |
|
TypeScript is not going anywhere.
|
# ? May 8, 2019 14:34 |
|
Munkeymon posted:Dart was kind of a mashup of Java and JS, so I'm not sure why you'd expect it to be any better about non-null types than those languages. Rust and Kotlin are the two up-and-coming languages I can think of that even have them, with C# getting them soonish. Hell, maybe Java got them in 9, but I'm not up on new Java features. Java has an @Nullable annotation (a variety of them even!) so linters can tell you to gently caress off with your possibly-nulls. The fact that so many versions of that exist really should have informed a language-maker that there was a desire for this feature. I wouldn't have particularly expected Dart to be decent in isolation, I expected it to be decent because a team had chosen to use it, and why would you choose to use a language that's worse than Typescript or C++, in a company where lots of people already know Typescript and C++?
|
# ? May 8, 2019 15:39 |
|
roomforthetuna posted:Typescript is basically Javascript, and is better about null handling than its ancestor. Dart predates Typescript, dude. Or do you mean for Flutter? In that case, it's either because someone at Google wanted to justify keeping Dart alive or post-hoc justify the original effort behind it to juice their career. Sort of like how IIRC Excel only used VB for scripting because Spolsky led the Excel team and VB was his baby before that.
|
# ? May 8, 2019 16:10 |
|
Munkeymon posted:Dart predates Typescript, dude. Or do you mean for Flutter? In that case, it's either because someone at Google wanted to justify keeping Dart alive or post-hoc justify the original effort behind it to juice their career. Sort of like how IIRC Excel only used VB for scripting because Spolsky led the Excel team and VB was his baby before that. And yeah, Dart-Flutter is probably based on some career nonsense as you say. It's frustrating because I really appreciate the goals of Flutter, why would you bind it only to a stupid language nobody wants? (Other than as some sort of career nonsense.)
|
# ? May 8, 2019 16:35 |
|
roomforthetuna posted:Yeah, but you were saying you don't get why would I expect a language to behave better than its ancestors - the answer is because I've seen other languages behave better than their same ancestors, Typescript being an example of that. I wasn't saying I think Dart should have learned from Typescript. (Though with its regeneration as a Flutter thing, actually, yes, Dart should have learned from Typescript.) Just to be clear, you are talking about TS's ~advanced feature~ --strictNullChecks that was added in 2.0 when you talk about 'better behavior', right?
|
# ? May 8, 2019 16:59 |
|
Munkeymon posted:Just to be clear, you are talking about TS's ~advanced feature~ --strictNullChecks that was added in 2.0 when you talk about 'better behavior', right? Functions that care whether a thing can be null seem pretty core to the language what with the "!" for asserting that a thing that could be null is not null. Edit: vvvv yeah apparently strictNullChecks is off by default. Maybe I included some recommended strict config file from somewhere, I certainly didn't set the option individually. So yes I am talking about that 'advanced feature'. roomforthetuna fucked around with this message at 20:00 on May 8, 2019 |
# ? May 8, 2019 18:26 |
|
roomforthetuna posted:I don't know, I didn't set any special options while setting up my Typescript, is that feature a default thing now? It sure doesn't appear to be? I've never used it outside that playground thing, though, so maybe it's commonly configured with the strict null check 🤷♂️ Munkeymon fucked around with this message at 19:06 on May 8, 2019 |
# ? May 8, 2019 19:04 |
|
Yeah the null checking by default is one of the reasons I ended up using flowtype instead of typescript for most of my work.
|
# ? May 9, 2019 14:05 |
|
|
# ? Jun 3, 2024 23:29 |
|
TypeScript always looked attractive to me, but since I was relatively new to Javascript I avoided it just because I was already overwhelmed by the massive ecosystem. However, I’ve been using VS Code’s JS type checking feature and it seems pretty awesome. I just use JSDoc comments to define function parameters and occasionally make a declaration file. Most of the time, it infers all the types correctly anyway. It’s helped me catch a lot of errors. Seems like most of the benefits of TS without actually writing TS.
|
# ? May 9, 2019 18:16 |