Honest question here from someone new to React. Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? It feels a bit like old school ASP! I'm not trying to be flippant, I just was always taught about separation and mixing HTML markup with JS logic seems like we are going the other way.
I do undestand where you come from there, but I'd view this as a bit different. React's building block is the 'component' – the idea being that this is an isolated part of the application. By its very nature, isolating a component means separating the HTML from all the other HTML, and the script from all the other script. Since components are generally quite small, it makes sense to bundle these together. You don't s…
A Primer for Building Single Page Applications with React
41–50 of 145 posts
Re: A Primer for Building Single Page Applications with React
#42Earlier quoted context omitted.
> Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications . While well-designed applica…
The reason I usually prefer to separate script and markup is that it makes the logic easier to test and those tests less brittle when the markup changes. Not having had any experience with react, I was wondering what the accepted approach to testing is?
One common way is to have React render into a simulated DOM (e.g. https://github.com/tmpvar/jsdom) and then trigger event handlers with code. You make assertions over the structure of the rendered DOM to know whether things went fine, all without a browser attached.
A dumber way that works remarkably OK too for simpler scenarios is to just have React render stuff to HTML strings and do regexes over those strings. Hacky, and if you're doing serious app development you probably don't want this, but it's a very easy way to get started.
Re: A Primer for Building Single Page Applications with React
#43Earlier quoted context omitted.
[deleted]
No, this is not correct. Please stop spreading this misinformation. Your license to use React is not contingent on 'not to sue them' – however, the additional patent grant that they give you is contingent on this. This patent grant is in addition to your license to use the software. If you accuse Facebook of violating one of your patents, then you automatically lose the right to use any of theirs. You do not lose you…
Re: A Primer for Building Single Page Applications with React
#44Earlier quoted context omitted.
No, this is not correct. Please stop spreading this misinformation. Your license to use React is not contingent on 'not to sue them' – however, the additional patent grant that they give you is contingent on this. This patent grant is in addition to your license to use the software. If you accuse Facebook of violating one of your patents, then you automatically lose the right to use any of theirs. You do not lose you…
It may not be correct, but do you deny that it's already been repeated enough that it'll take another 6-12 months of wasted hallway conversations discrediting it? When that BillG email for money urban legend first came out relatives literally called just to ask about it.
EDIT: Changed ANAL to IANAL...
Re: A Primer for Building Single Page Applications with React
#45Can you build an SPA using just React? At the very least it seems like you'll need a URL router, and something like underscore.js to fill in the gaps.
Sure. You may not want to depending how big and complex the application is, but it's definitely possible.
A router and an immutable collections library (immutablejs or mori for instance) are very convenient additions, but by no means necessary. Hell you don't need a precompilation phase either by skipping JSX (and unsupported ES6 constructs).
Re: A Primer for Building Single Page Applications with React
#46Hey by the way, the slack channel, Reactiflux, is actually pretty strong, check it out. Many people there are actually using React on large scale apps, myself included, and there is plenty of discussion.
Re: A Primer for Building Single Page Applications with React
#47Honest question here from someone new to React. Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? It feels a bit like old school ASP! I'm not trying to be flippant, I just was always taught about separation and mixing HTML markup with JS logic seems like we are going the other way.
Re: A Primer for Building Single Page Applications with React
#48Question from a JS layman: React is great in comparison to what? vanilla JS? Angular/Backbone/Ember? JQuery? any other *.JS? Also is this a good direction for "mobile first" approach? What about platform independence? (iOS/Android/Desktop agnostic, etc, etc). (bootstrap? phonegap?)
In comparison to Angular, React is more idiomatic . It is very easy to reason about the scope, lifecycle, and performance of React components if you are familiar with JavaScript as a language. In comparison with Backbone/JQuery, React is more declarative . It encourages the developer to describe the structure of the UI in a given state and let the engine handle the transitions between states. It's possible to use Bac…
I just wish we had a non-proliferation treaty on Flux frameworks.
Re: A Primer for Building Single Page Applications with React
#49Earlier quoted context omitted.
> Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications . While well-designed applica…
What about desktop/mobile applications - is it ok to mix your logic and presentation there?
I think about how painful it would be adding a custom button(new behavior) to a notification on a website: you either add an event listener to the dom and listen for it to bubble or add it to the button directly(the easier option). These new web frameworks seem to be adding it directly to the dom node -- we're back to which is faster, but traditionally harder to manage. But since everything is a structured component (all of these things implement an interface) we can build them faster and worry about it on the component level and not the markup level. I've been playing with React and Riot and it is a very interesting approach. You can build things out a lot faster than you used to and that is what matters in the end. The user will not care if you separate concerns (as long as the page renders and is accessible, but that is another story).
Re: A Primer for Building Single Page Applications with React
#50Honest question here from someone new to React. Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? It feels a bit like old school ASP! I'm not trying to be flippant, I just was always taught about separation and mixing HTML markup with JS logic seems like we are going the other way.
First, they came for the HTML markup and said "come on guys, JSX is just some XML on steroids. You should not worry at all" and we didn't speak up.
Then they came for CSS and said "come on guys, they're just small components and the same as placing the CSS declarations via the style attribute anyway blah blah blah" and we didn't speak up.
So you don't really know what's gonna be their next victim. There's a lot of revisionism and reinterpretation of best practices going on in the industry and hipsters and fanbois seem to go chasing the latest shiny and trendy object out there.
Nothing we can do to help save these people!
But seriously guys, have you seen any React dev code with all those CSS declarations and HTML markup over each other?
I pity the ones who will be assigned maintain this spaghetti code.