|
necrotic posted:Avoiding bundlers is going to make things very painful for you. Just use parcel, you'll be much happier in the long run. Dominoes fucked around with this message at 00:44 on Jul 6, 2018 |
# ? Jul 6, 2018 00:02 |
|
|
# ? May 16, 2024 17:19 |
|
Parcel is nice for smaller projects but webpack isn't going anywhere soon, it's too flexible.
|
# ? Jul 6, 2018 14:42 |
|
(s h a m e l e s s p l u g) I come mostly from a Ruby and Java universe where stuff like "background jobs processing" is easy - use Sidekiq or Quartz or whatever, you're done. NodeJS has a few tools, chiefly Kue and Bull...but I've never been satisfied with them. So I wrote and open-sourced (with some additional features behind a paywall so as to give me a financial reason to maintain the project over the long term) TaskBotJS, which for my money is the best option out there for TypeScript and JavaScript. I use the open-source version myself in one project to keep tabs on it and the commercial version in another because I need the features there, so it's dogfooded, and I have other folks using it already so it's not a Works On My Machine situation. (Except for the packaging and release stuff. Which is awkward because that's also the best one-stop demo of the project. But hey--it's an 0.9.0 release, not a 1.0 release.) Feel free to check it out and let me know what you think. https://github.com/eropple/taskbotjs
|
# ? Jul 6, 2018 18:24 |
|
Chenghiz posted:Parcel is nice for smaller projects but webpack isn't going anywhere soon, it's too flexible.
|
# ? Jul 7, 2018 04:45 |
|
Dominoes posted:Thanks dudes. This appears to be an issue of TSC not knowing how to deal with importing node modules as files, and es6 imports having the opposite problem; diagnosing by editing the compiled files directly to point to .js files. Fighting a mime issue now. (And will have to re-attack how to workaround this). tsc isn't meant to be used on large project without a bundler. Its remit is to handle TS->JS transpilation, and anything else is incidental. Chenghiz posted:Parcel is nice for smaller projects but webpack isn't going anywhere soon, it's too flexible. I suspect Parcel won't last forever, but for now it's good for giving Webpack a kick in the rear end about how Goddamn overcomplicated it is just to do "the right thing" of handling HTML, JS, SCSS/LESS, and images properly, and it not taking a bunch of screwing around to handle the simple use case of two HTML files with different bundles. Edit: I wish somebody would make something to reduce the endless proliferation of config files because I can't actually trust the full ecosystem for any of my tools to just read a Goddamn entry in package.json. .babelrc, .browserslistrc, .eslintrc, .prettierrc, .stylelintrc... Roadie fucked around with this message at 05:20 on Jul 7, 2018 |
# ? Jul 7, 2018 05:16 |
|
Roadie posted:Edit: I wish somebody would make something to reduce the endless proliferation of config files because I can't actually trust the full ecosystem for any of my tools to just read a Goddamn entry in package.json. .babelrc, .browserslistrc, .eslintrc, .prettierrc, .stylelintrc...
|
# ? Jul 7, 2018 14:34 |
|
I just learned async/await. It makes regular Promises look stupid (except for those edge things where you have to put a Promise around some old callback-type function to make it async-able.) But for like 95% of asynchronous things it's great. And especially for unit tests, where promises are loving terrible.
|
# ? Jul 13, 2018 04:05 |
|
util.promisify exists for promisifying callbacks on Node. Something similar no doubt exists in a browser (but I rarely run into them anymore there).
|
# ? Jul 13, 2018 05:50 |
|
AFashionableHat posted:util.promisify exists for promisifying callbacks on Node. Something similar no doubt exists in a browser (but I rarely run into them anymore there). Node is slowly rolling out promisified versions of their API. I think the most recent module that was mainlined is fs. Can't wait to see the end of callbacks.
|
# ? Jul 13, 2018 07:06 |
|
roomforthetuna posted:I just learned async/await. It makes regular Promises look stupid (except for those edge things where you have to put a Promise around some old callback-type function to make it async-able.) But for like 95% of asynchronous things it's great. And especially for unit tests, where promises are loving terrible. Async uses Promises under the hood. Makes you think.
|
# ? Jul 13, 2018 15:51 |
|
Mixing async await with Promise chains is the way to go, I don't understand when people want to go all in on just one or the other.
|
# ? Jul 13, 2018 19:49 |
|
Lumpy posted:Async uses Promises under the hood. Makes you think. code:
|
# ? Jul 14, 2018 00:41 |
|
I'm trying to create a function that traverses all the child nodes but the for loop seems to return early. I'm just getting into js and not sure if I've just made a simple mistake here or if js works differently than I think it should.code:
|
# ? Jul 14, 2018 13:03 |
|
JS has nothing special with recursion. What you're seeing is variable hoisting at work: both your children and child variables lack a declaration and are hoisted to the parent (global) scope. You can fix this by adding var declarations at the top of your function:code:
You could also use forEach instead of a loop and remove any explicit declarations: code:
necrotic fucked around with this message at 13:22 on Jul 14, 2018 |
# ? Jul 14, 2018 13:18 |
|
roomforthetuna posted:I knew that, and it did make me think, mostly I wonder how that works with something like this: That's why I let all the people who are smarter than me (which is a whole lot of people!) make stuff like Babel.
|
# ? Jul 14, 2018 14:46 |
|
FSMC posted:I'm trying to create a function that traverses all the child nodes but the for loop seems to return early. I'm just getting into js and not sure if I've just made a simple mistake here or if js works differently than I think it should. Separately from what necrotic said, you should be using some kind of linter. Any linter would instantly have caught this issue. JavaScript has gotchas, and it's highly inadvisable not to use the industry standard tools for avoiding those gotchas.
|
# ? Jul 14, 2018 16:21 |
roomforthetuna posted:I knew that, and it did make me think, mostly I wonder how that works with something like this: I've seen how TS transpiles async await to ES5, and it uses a massive switch case based on state at any given time that keeps adding itself to the event loop until it's done
|
|
# ? Jul 14, 2018 17:35 |
|
Doom Mathematic posted:Separately from what necrotic said, you should be using some kind of linter. Any linter would instantly have caught this issue. JavaScript has gotchas, and it's highly inadvisable not to use the industry standard tools for avoiding those gotchas. I've read up on variable hoisting so I think I have some kind of handle of why it didn't work. "children" is assigned outside of the for loop, but because I forgot to write var, it became a global value, so when it was updated in the inner loop with length 0, the for loops returns after the first loop. I'm pretty new to js but that seems like crazy bad. I'm pretty sure I had some sort of LINT maybe jslint installed but when I checked I had some warnings about eslint not being installed. So I managed to get that installed which then told me to install tslint, which made me also install typscript, and then finally seemed all installed but not much help. I tried a to create an unused variable, created a typo, missed out semi colons and vscode highlights all the other mistakes, but there is nothing in the problems log or on the screen about potential scope issues. So I have got the same warnings as I would have had before. I'm using vscode and pretty new to js and using lint. Is there some sort of setting I can use to catch stuff like this. I would have expected that using a variable without declaring it would be bad and show a warning, also shouldn't any globals throw up a warning? Also I'm confused by some of the notation in the fix and lots of javascript examples I've seen. I've tried to find more information about it but I don't know the terminology or topic names I need to be looking for. *Where function variable brackets aren't closed out. "(variable, function .... {.....});" *What does the "=>" mean code:
|
# ? Jul 15, 2018 04:10 |
|
That is shorthand function syntax. You could replace it with code:
|
# ? Jul 15, 2018 04:13 |
|
FSMC posted:*What does the "=>" mean is mostly equivalent to function (aaa, bbb) {some stuff} Except the arrow version doesn't have its own "this" and "arguments" bindings, it inherits those from its scope, where the "function" version has its own. 90% of the time it doesn't matter, and 90% of the *rest* of the time, the arrow version is more likely to be what you expected than the "function" version. (There are some other differences you almost certainly don't care about at this level.) Edit: also the thing to search for if you want to learn more about it is "arrow functions". roomforthetuna fucked around with this message at 04:19 on Jul 15, 2018 |
# ? Jul 15, 2018 04:16 |
|
necrotic posted:That is shorthand function syntax. You could replace it with I think the main issue I have is I don't understand what the full hand means. I've seen this sort of fullhand notation everywhere in js but don't understand it at any level. Here is the original function which works as I expect. code:
code:
code:
|
# ? Jul 15, 2018 13:47 |
|
FSMC posted:Here is pseudo code of what I expect a more streamlined syntax to look like. In this case, forEach is no special piece of syntax. It is just a method on children (and on any array, in fact). We call this method passing a single argument, and that single argument is itself a function. In other words forEach is a "higher-order function". The way forEach behaves is that it calls the "inner function" once per element in the array. Supporting this, JavaScript does, as you say, allow functions to be declared pretty much anywhere you would expect a simple JavaScript value or expression like 5 + 6. You can then bind that value to a variable e.g. var simple = function (child) { ... } and pass the variable to other functions children.forEach(simple), or just cut out the middleman: children.forEach(function (child) { ... }). You can declare all your functions separately if you like, there are some pros and cons to doing this, but you should get used to people declaring them in-line as well.
|
# ? Jul 15, 2018 14:29 |
|
FSMC posted:
There is no reason why you couldn't just declare it separately. Some reasons to use anonymous functions: 1. It's not used anywhere else. 2. It has access to its parent scope. 3. It is standard JS practice. As mentioned, you better get used to using them because of #3. You're going to see them everywhere. I agree that its pretty visually noisy. Arrow functions help with that though.
|
# ? Jul 15, 2018 15:53 |
|
FSMC posted:The main issue is I don't understand why or where functions are declared. Why are functions are decalred where I would expect a variable to be. So if I was going to declare a function, why not just declare it separately? To help with the context you're missing here, functions in JS are just objects like everything else. These two things... JavaScript code:
JavaScript code:
|
# ? Jul 16, 2018 01:04 |
|
Thermopyle posted:There is no reason why you couldn't just declare it separately. #2 is the most important IMO. Closures are really powerful once you understand how to use them with callbacks passed to higher-order functions like forEach.
|
# ? Jul 16, 2018 14:50 |
|
I've got an array and a bunch of conditions to potentially filter it on. I'd like to compose them together in something like:code:
|
# ? Jul 16, 2018 19:58 |
|
Depends on how big you expect the array to be and how often the code runs! Luckily, browsers have great tooling nowadays to profile your code and figure out whether it's a performance bottleneck or not.
|
# ? Jul 16, 2018 20:14 |
In case of lodash you can also use the lazy evaluation chain which could help a lot. But yeah, when in doubt profile.
|
|
# ? Jul 17, 2018 07:06 |
|
Is there a good tutorial on how to organize a react application? I'm coming from a hyper-structured Rails back and this all feels kinda like the wild west.
|
# ? Jul 18, 2018 02:19 |
|
MasterSlowPoke posted:Is there a good tutorial on how to organize a react application? I'm coming from a hyper-structured Rails back and this all feels kinda like the wild west. use create-react-app imo
|
# ? Jul 18, 2018 02:31 |
|
FSMC posted:function recursiveNode(node) { Careful with forEach on a NodeList it's not exactly the same as an array. Babel probably takes care of this, but just in case, you probably are safer with: code:
|
# ? Jul 18, 2018 02:37 |
|
uncurable mlady posted:use create-react-app imo Sounds perfect, thanks!
|
# ? Jul 18, 2018 02:55 |
|
geeves posted:Careful with forEach on a NodeList it's not exactly the same as an array. Babel probably takes care of this, but just in case, you probably are safer with: forEach is horrible to debug and horrible to reason about.
|
# ? Jul 18, 2018 06:44 |
|
The performance of for...of is terrible, since it requires an allocation on each loop, and next() has not been optimized in most engines. forEach and for loops don't have that issue. I've gotten multi-FPS speedups by changing for...of to forEach in some of my work.
|
# ? Jul 18, 2018 21:34 |
|
Suspicious Dish posted:The performance of for...of is terrible, since it requires an allocation on each loop, and next() has not been optimized in most engines. forEach and for loops don't have that issue. I've gotten multi-FPS speedups by changing for...of to forEach in some of my work. for (let a of list) { ... } should be equivalent to for (let i = 0; i < list.length; i++) {let a = list[i]; ... } except for not taking up any namespace for i. (Edit: if the 'a' is the allocation then I would think forEach would require the same allocation for the 'a' in list.forEach((a) => { ... }).) (Edit2: are you think of it as it applies to key-values rather than arrays, where you have to do Object.keys(map) and *that's* the allocation? I do see the value in forEach for key-value situations.) roomforthetuna fucked around with this message at 22:30 on Jul 18, 2018 |
# ? Jul 18, 2018 22:26 |
|
for (const a of list) is equivalent to:JavaScript code:
Suspicious Dish fucked around with this message at 22:36 on Jul 18, 2018 |
# ? Jul 18, 2018 22:33 |
|
Aha, thanks for the explanation. And that makes me sad.
|
# ? Jul 18, 2018 22:43 |
|
roomforthetuna posted:I don't know why you'd even use forEach these days, now that there's the "for (x of y)" syntax, other than ingrained habit from The Time Before. When I say forEach, I guess I should have clarified all of the array methods including map, reduce and filter. Usually if I'm using forEach I just use a regular loop given performance https://jsperf.com/fast-array-foreach
|
# ? Jul 19, 2018 01:13 |
|
Wow, are those jsperf measurements for real? That difference is severe. I thought for sure JS engine would just optimize most cases to do the same thing as a for loop since in a lot of cases the programmer is just going to blindly use whichever syntax is their preference at the moment. So it seems like most people's uses of for( x of y ) and forEach() out there would just be done upon plain old arrays in the most mundane way possible, yet the engine always assumes you might have some special type of list with an overridden custom iterator and runs it the really slow way just to be careful? Is that what's going on? Does this mean if I go back in all my inner loops and turn all for( x of y ) and forEach() calls (where I was just trying to save an unnecessary counter variable) into for loops instead, I could have as big of speed gains as those graphs show?
|
# ? Jul 19, 2018 01:33 |
|
|
# ? May 16, 2024 17:19 |
|
Dumb Lowtax posted:Wow, are those jsperf measurements for real? That difference is severe. I thought for sure JS engine would just optimize most cases to do the same thing as a for loop since in a lot of cases the programmer is just going to blindly use whichever syntax is their preference at the moment. Pretty certain it's accurate. The slowdown is mostly because of the instantiation and tear down of a method for each iteration that comes with scope built in to forEach. If you had to build in a closure into a for loop for any reason you might see some slowdown as well (how much compared to forEach, I don't know, TBH). Unless your data set is extremely large, it's probably nothing to worry about, but if you're getting into 10,000s of calculations then start maybe start to think about performance (and really shouldn't be done on the front end if at all possible) We wrote a custom calendar-like thing in react that in some rare cases had several thousand datapoints displayed. We took raw solr data and with map / foreach transformed it into something useful (this actually was harder to do in Java but very easy with JS). The TTI was still pretty decent in these edge cases at 2-3 seconds. geeves fucked around with this message at 02:08 on Jul 19, 2018 |
# ? Jul 19, 2018 02:05 |