I hate switching back to C# after working with SQL and SQLlike languages for like 5 months.
I mean, that's not true. I'd much rather work with C#.
I just hate having to remember that I can't do stuff like if(thing = poopy) and to use semicolons and stuff.
I've still yet to figure out just exactly what the point of each of these JS frameworks is supposed to fulfill.
You've got handlebars, react, express, node.
When should I use which? What are some examples!
I see a lot of hello world with a print or something, but real world practical examples are kind of missing.
Handlebars is a templating language that lets you generate HTML more easily. React is an end-to-end framework for making web apps. Express is a framework that sits on top of Node and lets you make webservers more easily. Node is a low-level way to run javascript natively and do network-y things.
Of those, React is the only "framework" in the way it's most commonly used; the other big-name frameworks right now are Angular and Ember. There's things like backbone which is much smaller and just gives you a way to get events/data moving around, without any rendering.
If I can't use state and I can't use refs I'm very, very unclear on what I need to do for validations. I see that Formsy has you pass in properties to those components but that means I need to have separate components for things like Inputs that can accept the validations, right? That means I have to write something similar to Input to do validations. I guess my problem is that this PasswordReset page is literally a self-contained component that uses the Bootstrap components to display stuff... I have to write sub-components that use these (something like <HonkyInput>) that take in these props and those props get validated against whatever I want. How would I get these values from a separate component, though? Like if I had:
How would I know if HonkyInput was valid to change the image? Would I attach a function in PasswordReset to HonkyInput that would change the state in PasswordReset?
I'm assuming the image is:
<i className="fa fa-times password-reset" />
if that is the case then, you know because PasswordRest component is a parent to both HonkyInput and i.
One thing you could do is send down a method as a prop to HonkyInput and i.
Say you have a method inside PasswordReset called handleValidation. i could look something like
and in HonkyInput you can call this.props.validationMethod() and it'll execute whatever is PasswordReset's handeValidation method.
which then sets it's state, which then you can pass down to it's children and they can re-render how they need to.
That's if you don't use something like backbone or Flux to handle state, it is prudent to have state in the closest most common ancestor to whatever components need to talk to each other.
Admittedly it can get to be a huge pain depending on how big your app is and what compoents are interacting with what other components. But Flux/backbone/Mobservable aim to make that easier.
After React is just views, not data/state handling.
Once you get Flux/etc implemented, it's actually suggested to make as many components as 'stateless' as possible.
But with all that said, you keep saying you are on a deadline. If shit is working right now, i'd move on to the next issue/ticket/defect. You can worry about getting it perfect after the deadline.
I've still yet to figure out just exactly what the point of each of these JS frameworks is supposed to fulfill.
You've got handlebars, react, express, node.
When should I use which? What are some examples!
I see a lot of hello world with a print or something, but real world practical examples are kind of missing.
Handlebars is a templating language that lets you generate HTML more easily. React is an end-to-end framework for making web apps. Express is a framework that sits on top of Node and lets you make webservers more easily. Node is a low-level way to run javascript natively and do network-y things.
Of those, React is the only "framework" in the way it's most commonly used; the other big-name frameworks right now are Angular and Ember. There's things like backbone which is much smaller and just gives you a way to get events/data moving around, without any rendering.
Why do people talk about using react and handlebars together? It's confusing as fuck.
they shouldnt, that is stupid.
most of that crap happens because people see JSX and have a knee jerk reaction and are all like "GET THAT TEMPLATE AWAY FROM LOGIC" without understanding how beneficial it is. because they have a skewed notion of what "seperation of concerns" means.
I've still yet to figure out just exactly what the point of each of these JS frameworks is supposed to fulfill.
You've got handlebars, react, express, node.
When should I use which? What are some examples!
I see a lot of hello world with a print or something, but real world practical examples are kind of missing.
Handlebars is a templating language that lets you generate HTML more easily. React is an end-to-end framework for making web apps. Express is a framework that sits on top of Node and lets you make webservers more easily. Node is a low-level way to run javascript natively and do network-y things.
Of those, React is the only "framework" in the way it's most commonly used; the other big-name frameworks right now are Angular and Ember. There's things like backbone which is much smaller and just gives you a way to get events/data moving around, without any rendering.
Why do people talk about using react and handlebars together? It's confusing as fuck.
Because React is a logic framework, it's not a view layer. You can just use POHT (plain ol' HTML templates) for templates, or you can use a more full blown templating engine like Handlebars. Angular works much the same way. A lot of people just use HTML, but Jade is also very big in the Angular space.
For most people, just using good ol' HTML is perfectly fine (it's what I do in most of my Angular and React work).
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited August 2015
JSX is not a view layer. JSX is basically string interpolation on steroids. You can just as easily have Handlebars inside your JSX. It's been done, people do it, it's not hard.
e: And the reason to do it is that for some people HTML is offensively terrible. It's over verbose and gross. I agree with those people, but not enough to actually use a template engine.
Angular works much the same way. A lot of people just use HTML, but Jade is also very big in the Angular space.
Jade's a preprocessor, right? How would you mix Jade in with <ng-repeat> and stuff and keep track of what's getting put in from where? (alternatively, when would you use ngIf -vs- Jade's "if"? the answers to this question seem to suggest that you'd just use Jade as an alternative to HTML, which then falls out as HTML and that HTML goes to Angular? (like writing your angular code in Coffeescript sort of thing).
React most definitely is a view/layout thing and you should use it for all of that, JSX and such.
We are using Jade with ours for content only. So, like, our "About Us" page is rendering Jade content into the component, and you can do up your markup that way for all the "static" content. It's replacing the CMS for us right now. When I build a more dynamic database style CMS, it may continue to use Jade.
So if you like Handlebars, you could have done the same as above, just swap it in instead of Jade.
Not sure what other combinations would make sense though, you should be doing React for all your application goodness.
Is anybody else having an issue with the MSDN layout being garbage?
As of about 2 weeks ago, all the content is using the center half of the screen on my widescreen monitor, with giant blank areas on the side.
Look at that eensy weensy scrollbar.
It's the same in IE and Chrome.
Only just noticed, because I normally operate at around 175% zoom (because I've found that this reduces my eye strain problems). Had to go back to 100% to see the blanks.
i think we are gonna have to agree to disagree because i fundamentally dont think thats a good way to implement react.
At a fundamental level it's no different than just using HTML. The syntax differs. You're not using Jade or Handlebars for the templating so much in this case as using it for syntax, which many people prefer over HTML. No different than writing your React's JavaScript code in Coffee or TypeScript (which is a touch harder because of the way JSX works, but people are doing it).
Angular works much the same way. A lot of people just use HTML, but Jade is also very big in the Angular space.
Jade's a preprocessor, right? How would you mix Jade in with <ng-repeat> and stuff and keep track of what's getting put in from where? (alternatively, when would you use ngIf -vs- Jade's "if"? the answers to this question seem to suggest that you'd just use Jade as an alternative to HTML, which then falls out as HTML and that HTML goes to Angular? (like writing your angular code in Coffeescript sort of thing).
Yes, basically. The Jade becomes HTML which is then what actually builds the DOM for Angular. You're using it as a syntax replacement, not for all the logic-light templating. It's likely you'd never use Jade 'if', but always use ng-if, unless you had a very specific reason to have logic in the pre-process, which I would almost certainly want most developers to think very hard about. One reason might be that you need something in the view processed server side instead of client side, since Angular does not do progressive enhancement like React.
That's because too long of lines in content is poor for readability, they're doing that intentionally.
Zoom in with Ctrl +!
Maybe to a point, but I'm pretty sure they overshot because at normal zoom level I get about 6 words per line and it makes it really fucking hard for me to read because I'm constantly jumping to a new line and having to scroll for ages to find anything.
edit: actually zoom doesn't help. I don't want bigger text. I want more text.
So, I got to spend my evening last night on the 4 hour conference call from hell trying to get the app I work on running in our Disaster Recovery simulation environment.
Then this morning was managed chaos as I had to do some last minute build corrections.
gavindelThe reason all your softwareis brokenRegistered Userregular
I'm reading accounting textbooks on the side to try and catch up in domain knowledge. Given that I work building accounting software now...this is a good thing. Most of it is pretty dry stuff, but hey - I've learned more than a dozen ways people commit fraud in large corporations!
Plus, I'm certain that accounting + programming is a skillset that will never lack for job opportunities.
I think they're talking about using Handlebars to render mostly-static, non-interactive HTML, maybe with some formatting helpers and loops but without any conditional blocks.
At least, that's the only explanation that makes any sense at all to me. Rendering with Handlebars and then trying to bind event handlers after the fact... I don't know, it sounds messy. All you get back from Handlebars is an HTML string. Would you... create a DocumentFragment, plop the HTML in there, and then bind the event handlers? Yuck.
Posts
I mean, that's not true. I'd much rather work with C#.
I just hate having to remember that I can't do stuff like if(thing = poopy) and to use semicolons and stuff.
Why do people talk about using react and handlebars together? It's confusing as fuck.
I'm assuming the image is:
if that is the case then, you know because PasswordRest component is a parent to both HonkyInput and i.
One thing you could do is send down a method as a prop to HonkyInput and i.
Say you have a method inside PasswordReset called handleValidation. i could look something like
var PasswordReset = React.createClass = { handleValidation: function (args) { if (foo === bar) { setState({valid: qux}) } }, render: function(){ <Panel> <HonkyInput validationMethod={this.handleValidation} label="Password" type="password" validateLength /> </Panel> <Panel> <i className="fa fa-times password-reset" valid={this.state.valid}/> </Panel> } }and in HonkyInput you can call this.props.validationMethod() and it'll execute whatever is PasswordReset's handeValidation method.
which then sets it's state, which then you can pass down to it's children and they can re-render how they need to.
That's if you don't use something like backbone or Flux to handle state, it is prudent to have state in the closest most common ancestor to whatever components need to talk to each other.
Admittedly it can get to be a huge pain depending on how big your app is and what compoents are interacting with what other components. But Flux/backbone/Mobservable aim to make that easier.
After React is just views, not data/state handling.
Once you get Flux/etc implemented, it's actually suggested to make as many components as 'stateless' as possible.
But with all that said, you keep saying you are on a deadline. If shit is working right now, i'd move on to the next issue/ticket/defect. You can worry about getting it perfect after the deadline.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
But yeah I figured that passing in the validate method from the parent to the child was the best route to go... But I was being sure. Thanks.
they shouldnt, that is stupid.
most of that crap happens because people see JSX and have a knee jerk reaction and are all like "GET THAT TEMPLATE AWAY FROM LOGIC" without understanding how beneficial it is. because they have a skewed notion of what "seperation of concerns" means.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
Because React is a logic framework, it's not a view layer. You can just use POHT (plain ol' HTML templates) for templates, or you can use a more full blown templating engine like Handlebars. Angular works much the same way. A lot of people just use HTML, but Jade is also very big in the Angular space.
For most people, just using good ol' HTML is perfectly fine (it's what I do in most of my Angular and React work).
why would anyone use react and rip out JSX?
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
instead of putting weak psuedo logic into html (like handlebars, dust, mustache), you put html inside a powerful logic language i.e. javascript.
using handlebars or some other templating thing inside react to attempt to "separate concerns" completely misses the point.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
e: And the reason to do it is that for some people HTML is offensively terrible. It's over verbose and gross. I agree with those people, but not enough to actually use a template engine.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
PVS-studio publishes some pretty godlike articles critiquing C++ codebases, and they are bite-sizing it!
Jade's a preprocessor, right? How would you mix Jade in with <ng-repeat> and stuff and keep track of what's getting put in from where? (alternatively, when would you use ngIf -vs- Jade's "if"? the answers to this question seem to suggest that you'd just use Jade as an alternative to HTML, which then falls out as HTML and that HTML goes to Angular? (like writing your angular code in Coffeescript sort of thing).
We are using Jade with ours for content only. So, like, our "About Us" page is rendering Jade content into the component, and you can do up your markup that way for all the "static" content. It's replacing the CMS for us right now. When I build a more dynamic database style CMS, it may continue to use Jade.
So if you like Handlebars, you could have done the same as above, just swap it in instead of Jade.
Not sure what other combinations would make sense though, you should be doing React for all your application goodness.
As of about 2 weeks ago, all the content is using the center half of the screen on my widescreen monitor, with giant blank areas on the side.
Look at that eensy weensy scrollbar.
It's the same in IE and Chrome.
Zoom in with Ctrl +!
Same here as well.
Only just noticed, because I normally operate at around 175% zoom (because I've found that this reduces my eye strain problems). Had to go back to 100% to see the blanks.
At a fundamental level it's no different than just using HTML. The syntax differs. You're not using Jade or Handlebars for the templating so much in this case as using it for syntax, which many people prefer over HTML. No different than writing your React's JavaScript code in Coffee or TypeScript (which is a touch harder because of the way JSX works, but people are doing it).
Yes, basically. The Jade becomes HTML which is then what actually builds the DOM for Angular. You're using it as a syntax replacement, not for all the logic-light templating. It's likely you'd never use Jade 'if', but always use ng-if, unless you had a very specific reason to have logic in the pre-process, which I would almost certainly want most developers to think very hard about. One reason might be that you need something in the view processed server side instead of client side, since Angular does not do progressive enhancement like React.
you are all crazy.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
i am glad i mostly develop desktop stuff
edit: actually zoom doesn't help. I don't want bigger text. I want more text.
I'M BROWSING THE PA FORUMS AT 175% ZOOM RIGHT NOW HAHAHAHAHAHAHAAH
It's like everyone's got loud thoughts!
Then this morning was managed chaos as I had to do some last minute build corrections.
At least management is appreciative.
Plus, I'm certain that accounting + programming is a skillset that will never lack for job opportunities.
WHY ARE THERE TWO CHOICES FOR A FUNDAMENTAL DATA TYPE LIKE THIS??
yeah I hate that
single quotes almost always.
unless it's json.
then double quotes always.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
which is why single quote can be easier:
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
Yeah, that one makes sense. It's like {at}"" in C#, but no, in JS you can just freely interchange '' and ""
E: I mean, in the same code. A single string has to be either 'something' or "something else", not 'a third thing"
I think they're talking about using Handlebars to render mostly-static, non-interactive HTML, maybe with some formatting helpers and loops but without any conditional blocks.
At least, that's the only explanation that makes any sense at all to me. Rendering with Handlebars and then trying to bind event handlers after the fact... I don't know, it sounds messy. All you get back from Handlebars is an HTML string. Would you... create a DocumentFragment, plop the HTML in there, and then bind the event handlers? Yuck.