|
bartkusa posted:Ah. Weird. Next step: what is "this.props"? What is "this"? "this.props" is {dataRow: Object, onClickMe: undefined} "this" looks like a bunch of react stuff, only thing I gleaned from it was _rootNodeID ".0.1.$1" which matches what was generated for my <tr> that contains the button, seems to make sense
|
#
?
Mar 3, 2015 07:33
|
|
|
|
| # ? May 22, 2024 16:59 |
|
|
fletcher posted:"this.props" is {dataRow: Object, onClickMe: undefined} OK. So where are you going to put your next breakpoint, to figure out why your assignment to onClickMe is wrong? You're going to put a breakpoint in this.props.dataRows.map(...) And what will you find is causing your problems? "this" will be undefined, because you're passing an anonymous function to map(...), and you aren't binding it to any context.
|
|
#
?
Mar 3, 2015 07:49
|
|
|
bartkusa posted:OK. So where are you going to put your next breakpoint, to figure out why your assignment to onClickMe is wrong? You're going to put a breakpoint in this.props.dataRows.map(...) Ahhh there we go, working now! That makes sense, thank you!
|
|
#
?
Mar 3, 2015 07:59
|
|
|
Next question about that fiddle: lets say TableWidget.handleClick does some ajax and I want to show an indication in the UI while it's loading. I can do some this.setState in the TableWidgetRow.handleClick but how does it know when TableWidget.handleClick has actually completed? Do I have to manipulate TableWidgetRow state from TableWidget? Here's the updated fiddle: http://jsfiddle.net/pj6hz7hq/4/
|
|
#
?
Mar 3, 2015 09:18
|
|
|
^ I was able to do it by just getting rid of TableWidget.handleClick and only having TableWidgetRow.handleClick, but I'm still kinda curious how you would pass state to a child component like that.
|
|
#
?
Mar 3, 2015 19:13
|
|
|
Passing state to a child component should be done with props, like <MyComponent myprops={this.state} /> or similar. If you want to go the other direction, from child up back up the shadow DOM tree to where the state is managed, you can either chain callbacks being passed as props all the way up, or use the Flux pattern - where you have the concept of a store, and you bind an update function that triggers an event on that store, and then just reconcile your state with the store.
|
|
#
?
Mar 3, 2015 20:27
|
|
|
A while back I had a question about JavaScript that basically was solved by having a primary "site" module and then each page would have its own separate page-specific module that controlled the stuff specific to that page. This is working well, but the actual compilation process is an absolute nightmare. I've found Watchify to be incredibly buggy and poorly maintained. Specifically I'm having this problem which was reported in August 2014 and has had a solution developed in a fork and yet still hasn't been fixed in the official repo. I'm wondering if someone can help me out by suggesting an alternative and perhaps point me at a half-decent "getting started" guide for that alternative? Whatever the solution is, it needs to be able to render JSX into JS and support RequireJS modules. It also needs to be capable of watching the files and auto-compiling on changes. I'm fairly new to this modern front-end stuff, is the lack of maintenance on Watchify something that is common among other frequently used tools? How on Earth do you guys survive?
|
|
#
?
Mar 5, 2015 00:26
|
|
|
I've never used Watchify so I can't comment on that but I've been using Gulp to prepare my application for both development and production environments for nearly a year and have never run into any issues. It has a built in watcher so you can either run tasks manually or have them run as you make changes. http://gulpjs.com/ Grunt is another popular alternative but I haven't used it much either.
|
|
#
?
Mar 5, 2015 00:43
|
|
|
The Wizard of Poz posted:I'm fairly new to this modern front-end stuff, is the lack of maintenance on Watchify something that is common among other frequently used tools? How on Earth do you guys survive? Half-baked Javascript projects are common in a way I haven't seen with C#, Python, etc. I personally survive by ignoring the "flavor of the month" stuff, and hand-rolling a lot of what I need. The small handful of libraries that I love and seem to be well maintained are things I don't ever want to reinvent the wheel on: React, numeral, moment, lodash, bluebird. Grunt is OK, Gulp is pretty cool, but they all kind of fall into the same traps. Unless it's a huge project with lots of moving parts, I still tend to do things manually. If it takes me X time to setup and maintain Gulp, and it only saves me X-Y time, why bother?
|
|
#
?
Mar 5, 2015 01:00
|
|
|
Helicity posted:Half-baked Javascript projects are common in a way I haven't seen with C#, Python, etc. I personally survive by ignoring the "flavor of the month" stuff, and hand-rolling a lot of what I need. The small handful of libraries that I love and seem to be well maintained are things I don't ever want to reinvent the wheel on: React, numeral, moment, lodash, bluebird. Unfortunately the major thing I'm struggling with is module management / building. I'm using the RequireJS syntax (using module.exports) so I need something to build these smaller JS files into bundles. Something that supports building to multiple output files is a must - basically my dev-JS looks something like this: code:Those libraries you listed are excellent libraries, but the major issue I'm having is with the development toolchain rather than actual JS libraries themselves.
|
|
#
?
Mar 5, 2015 01:52
|
|
|
The Wizard of Poz posted:Each of the three bundles listed there need to be generated by some kind of a compiler that can take the source files, resolve the includes, render the JSX and output the result as a bundle. Require definitely seems to support bundling: requirejs.org/docs/optimization.html Does this help with the JSX piece? https://stackoverflow.com/questions/23381561/using-reactjs-with-requirejs
|
|
#
?
Mar 5, 2015 02:01
|
|
|
The Wizard of Poz posted:Those libraries you listed are excellent libraries, but the major issue I'm having is with the development toolchain rather than actual JS libraries themselves. Sorry, I didn't mean for those to be an example of a solution for you, it was more of a rant against the Javascript development ecosystem. I'm guessing Gulp might work for you, if you're interested in exploring other tools. It's probably the "fotm" build tool at the moment, so there shouldn't be any issues with show-stopping bugs hanging around. We do all sorts of bundling, require tomfoolery, SASS, etc. and it's worked rather well. I'm not sure about the JSX piece as we haven't mixed JSX into that project yet, but I'd be surprised if it didn't support it.
|
|
#
?
Mar 5, 2015 02:24
|
|
|
Helicity posted:Sorry, I didn't mean for those to be an example of a solution for you, it was more of a rant against the Javascript development ecosystem. I'm guessing Gulp might work for you, if you're interested in exploring other tools. It's probably the "fotm" build tool at the moment, so there shouldn't be any issues with show-stopping bugs hanging around. We do all sorts of bundling, require tomfoolery, SASS, etc. and it's worked rather well. I'm not sure about the JSX piece as we haven't mixed JSX into that project yet, but I'd be surprised if it didn't support it. I'm looking to Gulp now, thanks. I think it's more likely to do what I'm after.
|
|
#
?
Mar 5, 2015 02:26
|
|
|
The Wizard of Poz posted:Unfortunately the major thing I'm struggling with is module management / building. I'm using the RequireJS syntax (using module.exports) so I need something to build these smaller JS files into bundles. Something that supports building to multiple output files is a must - basically my dev-JS looks something like this: For the record, RequireJS is AMD and tends to look something like this: code:If you're doing the second one then I'd have to ask what you're using to compile it. Is it browserify?
|
|
#
?
Mar 5, 2015 03:38
|
|
|
NovemberMike posted:For the record, RequireJS is AMD and tends to look something like this: Ah I see, sorry about the confusion. Yes, I'm using Browserify, previously via watchify (which I believe is some sort of a wrapper that watches files for changes and then auto-Browserifies them). I'm having a lot of trouble with Gulp. I don't understand how the piping works, here's what I have so far, and it's not working: code:Rant incoming: I'm feeling incredibly demotivated and dispirited by all this, I've been a web developer for around 5-6 years and I have never felt so incredibly stupid and utterly outwitted. I don't think I am stupid, at least I didn't, but now I'm not sure. Is this something that is genuinely hard to grok or am I just stupid? I can't seem to find any "getting started" guides for this sort of thing that actually work, they all result in errors or unexpected behaviour. It seems like the APIs for these libraries are changing on a weekly basis so Stack Overflow answers are rarely helpful. Ditto for Google results. I just want to know if I'm the only one who really struggles with this or not? What I'm trying to do seems like it would be an incredibly common task in modern web development, and I feel like there's some kind of memo floating around with the answers on it that other web developers have seen and I haven't. There are incredibly smart and helpful people in here, and they talk about all this poo poo as though its trivial, like they just quickly whip up a gruntfile and go about their work, but for me I just can't get any of it to work the way the guides and the tutorials say they're supposed to. Instead of getting any meaningful coding done I'm sitting here stuffing around with a gruntfile and getting absolutely nowhere. I guess I'm just fed up with it all and I'm not sure where I've gone wrong - it seems like it's really hard for me but really easy for everyone else and I can only assume I've missed out on some important information somewhere. I really need some general guide to this modern front-end world and I just can't find one anywhere.
|
|
#
?
Mar 5, 2015 04:41
|
|
|
IIRC I fixed that issue by importing vinyl-buffer and sticking '.pipe(vinyl_buffer())' in between pipe(source) and pipe(uglify). EDIT: This one https://www.npmjs.com/package/vinyl-buffer their use case also shows it between source() and uglify() NovemberMike fucked around with this message at 05:22 on Mar 5, 2015 |
|
#
?
Mar 5, 2015 05:18
|
|
|
The Wizard of Poz posted:I'm fairly new to this modern front-end stuff, is the lack of maintenance on Watchify something that is common among other frequently used tools? How on Earth do you guys survive? I've been using webpack. It does have a built-in 'watch' mode that has worked well for me so far. I think the webpack config that would be roughly equivalent to the gulpfile you posted would look something like: code:for watch mode webpack -p for minification /w uglifyjs. You could also configure it in webpack.config.js if you wanted to control it /w environment variables, or provide a specific uglifyjs config. edit: I remember not liking the webpack docs much but maybe this howto will also help: https://github.com/petehunt/webpack-howto skul-gun fucked around with this message at 06:08 on Mar 5, 2015 |
|
#
?
Mar 5, 2015 06:04
|
|
|
The Wizard of Poz posted:Rant incoming: Don't worry - this poo poo sucks for all of us. TBH, this is my least favorite part about front end development today. Setting up tooling for a new project has always been a major sticking point, which is why you see so many gulp/grunt/browserify/webpack/whatever boilerplate templates on github. It really just comes down to picking one and going into a kind of manic fugue state as you read through the docs and look up blog posts and other people's repos and poke and prod your build files until everything starts making sense. With the browserify+gulp combo you've bitten off a pretty large chunk to try to understand all at once. Both those projects have pretty large ecosystems - I'd say most people that use them together have built their understanding of each incrementally on their own. I'd also recommend taking a look at webpack - its documentation is just as terrible as the others, but at least its craziness is sort of self-contained. You can easily find boilerplates out there that compile JSX and start working from those - I haven't actually read through it yet but a quick google led me to https://github.com/christianalfoni/react-webpack-cookbook/wiki which looks like a pretty decent intro.
|
|
#
?
Mar 5, 2015 06:30
|
|
|
I'm going through some of the same growing pains as I'm transitioning to working on react and using gulp (my main impetus was so that my jsx would get compiled on the fly automatically). Here are the things that have saved me so far: Concrete stuff related to getting up and running w react/browserify/gulp 1) Pretty sure I linked it already, but this article really helped me with the gulp/browserify setup. 2) I used react router to handle routing. With #1 above that got me to where I wanted to be in terms of framework for my initial react project. 3) Consider Linux. I'm a lifelong Windows guy, but god its so much easier to use a lot of the command line based tools in Ubuntu. Less concrete stuff related to not going crazy because of framework/new-poo poo overload 1) use Twitter (curate your tech list diligently) and CoC to maintain a feel for where things are headed 2) start contributing to existing projects on Github ...a) or at least look at source code using the relevant stack 3) build something small and viable with whatever interests you (honestly you never know for sure with any of this poo poo until you try it on something and not just a hello-world) ...a) but limit the number of new techs per project Kekekela fucked around with this message at 16:30 on Mar 5, 2015 |
|
#
?
Mar 5, 2015 10:47
|
|
|
I definitely recommend webpack for React. It has a development server that can hot reload javascript, which allows instant viewing of your changes. React components get automatically refreshed while you edit them. https://vimeo.com/100010922 You can find a lot of starter packs on Github. It's also not that hard to combine with Gulp.
|
|
#
?
Mar 5, 2015 11:07
|
|
|
Pete Hunt, one of the devs behind React, has what looks like a nice webpack how-to here: https://github.com/petehunt/webpack-howto I haven't actually used webpack (because when I was picking a tool the webpack docs were terrible) , but I remembered coming across that. My solution to the poo poo state of these tools is to get something that works and then never change it until forced to. Watchify+CommonJS has been working great for me.
|
|
#
?
Mar 5, 2015 16:14
|
|
|
The Wizard of Poz posted:It seems like the APIs for these libraries are changing on a weekly basis so Stack Overflow answers are rarely helpful. Ditto for Google results. I just want to know if I'm the only one who really struggles with this or not? Nope. There is a reason YOSPOS likes the term web "developers".
|
|
#
?
Mar 5, 2015 21:29
|
|
|
*a developer tries {thing} feels it's too complicated, decides to make their own {new thing}* *{new thing} gets popular with others* *{new thing} adds features others want* *{new thing} becomes rapidly changing, confusing, mess* *a developer tries {new thing} feels it's too complicated, decides to make their own {newer thing}...*
|
|
#
?
Mar 5, 2015 22:00
|
|
|
"You tried your best and you failed miserably. The lesson is never try."
|
|
#
?
Mar 5, 2015 22:08
|
|
|
Kekekela posted:3) Consider Linux. I'm a lifelong Windows guy, but god its so much easier to use a lot of the command line based tools in Ubuntu. After developing on a Mac for 2 years and being forced to recently switch back to Windows for my dev environment, I can't agree with this enough.
|
|
#
?
Mar 6, 2015 21:31
|
|
|
enthe0s posted:After developing on a Mac for 2 years and being forced to recently switch back to Windows for my dev environment, I can't agree with this enough. It's so true that I do 100% of my development in an Ubuntu VM on my Windows machine. As a bonus, Its nice to be able to move my dev "machine" around very easily.
|
|
#
?
Mar 6, 2015 21:34
|
|
|
Thermopyle posted:It's so true that I do 100% of my development in an Ubuntu VM on my Windows machine. As a bonus, Its nice to be able to move my dev "machine" around very easily. I'm doing .NET stuff now, and as far as I'm aware I'm under the impression that I should be using Visual Studio on Windows. If I'm wrong about this, please tell me because I'm looking for any excuse to use an actual terminal again 
|
|
#
?
Mar 6, 2015 21:42
|
|
|
enthe0s posted:I'm doing .NET stuff now, and as far as I'm aware I'm under the impression that I should be using Visual Studio on Windows. If I'm wrong about this, please tell me because I'm looking for any excuse to use an actual terminal again Oh yes, you should definitely be using VS. I really should have quoted the original post recommending developing on Linux. I wasn't really saying anything about your situation.
|
|
#
?
Mar 6, 2015 21:44
|
|
|
I've only used Linux and Windows to any reasonable extent. If I can get around in Mint on the command line, does that mostly translate over to Mac?
|
|
#
?
Mar 6, 2015 23:21
|
|
|
an skeleton posted:I've only used Linux and Windows to any reasonable extent. If I can get around in Mint on the command line, does that mostly translate over to Mac?
|
|
#
?
Mar 6, 2015 23:31
|
|
|
I'm about to do an presentation about browser layout algorithms (single-threaded era vs. Blink/Servo) and how to make things go close to 60fps (minimise reflow, js tips). Some feedback would be appreciated http://holloway.nz/what-a-browser-is/
|
|
#
?
Mar 8, 2015 05:48
|
|
|
I think I'm able to follow your train of thought, even without your speech, which is a good sign. I don't know if your audience will load this in their browsers during/after your talk, but it might help to hyperlink drat near everything on slide 13. Examples are great. Your CSS examples are compelling. Maybe it'd even more compelling to have a Goofus and Gallant section where you quickly run through things like "this lovely templating example runs at 10fps in Chrome, but this one small tweak names it run 3x faster."
|
|
#
?
Mar 8, 2015 09:22
|
|
|
N.Z.'s Champion posted:I'm about to do an presentation about browser layout algorithms (single-threaded era vs. Blink/Servo) and how to make things go close to 60fps (minimise reflow, js tips). Some feedback would be appreciated http://holloway.nz/what-a-browser-is/ I really liked it, good job.
|
|
#
?
Mar 8, 2015 13:33
|
|
|
M31 posted:I definitely recommend webpack for React.
|
|
#
?
Mar 8, 2015 13:38
|
|
|
So, the past week or so I've been back to Angular after spending a month or more in React. I used to tell people Angular was OK, but now I'm thinking Angular is just not worth using in a world where you can make the choice and React and related tools are available. Is there anything that Angular is better at?
|
|
#
?
Mar 9, 2015 18:13
|
|
|
Rapid development for people who want to stick to a more conventional model/controller/view-template approach for their application, and want that structure enforced by the entire framework. It has its niche, but I imagine its going to get dropped in the dust by Ember et al considering Ember won't be abandoned for 2.0 with no migration path.
|
|
#
?
Mar 9, 2015 19:12
|
|
|
Thanks all for making me feel a lot better, it's nice to know I'm not alone in my struggles. I have a pretty simple and specific question now - I can't figure out what's happening here. This part of the code is very simple (line numbers are only for the purpose of this post): code:code:If I step into this.setState, it's being run with no errors or anything like that, and the partial state gets sent through it okay as far as I can tell, but eventually the code gets kind of complex and difficult to follow. Has anyone encountered this before? Are there any gotchas I should be aware of with this.setState? It's worth mentioning that everything works fine with a different instance of the component on another page, but it's working with different data and there's so much different between the two that it's hard to properly compare. Edit: Doh! As always, talking through it for the sake of this post helped me find the problem - I'm not sure why it manifested the way it did, but I was accidentally using an undefined variable as a key on some elements in my React component. putin is a cunt fucked around with this message at 02:43 on Mar 10, 2015 |
|
#
?
Mar 10, 2015 02:37
|
|
|
Maluco Marinero posted:... considering Ember won't be abandoned for 2.0 with no migration path. If this is a reference to Angular, I thought the reason there currently wasn't a migration path from 1.3 to 2.0 is because 2.0 isn't done yet. Therefore, it's pointless to create a path to a moving target.
|
|
#
?
Mar 10, 2015 04:10
|
|
|
The Merkinman posted:If this is a reference to Angular, I thought the reason there currently wasn't a migration path from 1.3 to 2.0 is because 2.0 isn't done yet. Therefore, it's pointless to create a path to a moving target. Nope, the PLAN is to have no migration path. The changes are too dramatic and fundamental apparently for a migration path to be feasible.
|
|
#
?
Mar 10, 2015 06:56
|
|
|
|
| # ? May 22, 2024 16:59 |
|
|
The Wizard of Poz posted:Nope, the PLAN is to have no migration path. The changes are too dramatic and fundamental apparently for a migration path to be feasible. While this is true, the 1.x line isn't going anywhere anytime soon. 1.4 is going to be released soon, and there are many internal Google apps that rely on the 1.x line, so they aren't going to just drop support for it.
|
|
#
?
Mar 10, 2015 15:25
|
|