I have recently started using React JS with an existing python/django project.
My experience from someone who is fluent with JQuery/Dom manipulations:
- Javascript has come a long way. But syntax still is ugly.
- With ES6, I predict coffeescript will fade away in the near future.
- Development on the front end is getting complex
- Use a tool like Webpack or Grunt or Browserify
- IDEs haven't caught up to javascript development...yet.
- Thinking in React JS takes some getting used to but pays off in the future when viewing everything as a component.
> Use a tool like Webpack or Grunt or Browserify - IDEs haven't caught up to javascript development...yet.
WebStorm is certainly close. It doesn't have much of the ES7 strawman stuff, but I wouldn't expect it to. However, it works great with NPM modules, import/export syntax, destructuring, generators, etc etc.
I would love to know about your toolchain. Our stack is python/django/jquery, and I've been looking into React on the frontend, and am particularly excited by Swampdragon and ishout.js integration with Django.
How do you use React and Django? Have you tried building an "isomorphic" (buzzword alert) application using React/Django?
This would really benefit from proper hot reloading ala https://github.com/thereactivestack/kickstart - Meteor takes so long to pick up changes and reload the entire page every time you save a file. Using component hot reloading like in the project I linked to makes things so much faster and more pleasant to develop when using Meteor.
Development on ironrouter stagnated a long time ago. It has almost 300 open issues and the last commit was in June. FlowRouter by Meteorhacks/Kadira (one of the most active community members) was released about 3 months ago as a very slimmed down router. It's been quickly adopted, is well maintained and works excellently with alternate front-end like React.
Lots of smarter people than myself recommend not having reactivity in your router. IronRouter has that in spades. The logic is that it's harder to debug your router if you have reactivity.
FlowRouter is better in that regard because it's 'dumb'.
I find it easier to reason about my code/state by having a dumb router and letting my templates decide what to render.
Can confirm the statement of reactivity in router being a bad thing. Route reloads because of new data can be surprisingly expensive especially when you have a large data set being shown in one place (eg: task list). Unless you are really being careful and watching out for how you put elements into your router (when using iron router) you can suddenly have an edit on one item causing a full reload of the entire view which in turn ends up reloading all the items. It's avoidable for sure, but we all know that it's better to have the default behaviour be the more rational one.
IronRouter tries to be a lot more thing than just a router. It had controllers, which are basically encapsulates your data for a specific route. There are things which a router shouldn't really bother with. Having said that, you can still use IronRouter as just a router and not use the extra bells and whistles that comes with it.
I'm still using it in one of my projects and haven't had any issues, perhaps because I'm not using more advanced features provided by it.
Telescope recently switched away from IronRouter to FlowRouter for a number of reasons, and discussed it in the changelog episode here: https://www.youtube.com/watch?v=itVZ1Md5xMI&feature=youtu.be - @sgdesign does a fantastic job comparing/contrasting and explaining the motivation for the switch away from IronRouter.
The short, unsatisfying answer is that using `class` is deprecated in React, and has been for a while.
For a longer answer, take a look at the discussion of issue #4433 on github [1], especially the following comment by spicyj [2]:
> [...] We're sticking with className and htmlFor for a couple of reasons:
> First, we tend to look at HTML properties (like el.className = ...) when possible, as opposed to attributes (like el.setAttribute('class', ...)). Attributes are always string-typed, while properties can have any JavaScript object value, which gives more flexibility in some circumstances. One example is the .classList property, which arguably is a better fit for the data model than .className is. React doesn't support classList right now, but it certainly could. Given that React's className behaves like the HTML property of the same name, it makes sense to keep that name.
> Another reason is more forward-thinking. In the future, idiomatic React may use object destructuring to pick apart this.props. The react-future repo shows one example of how this could work. Even in modern browsers, this wouldn't work with class and for which are keywords and can't appear as standalone identifiers even though they can appear as property names.
> Third, our thinking is that JSX's primary advantage is the symmetry of matching closing tags which make code easier to read, not the direct resemblance to HTML or XML. It's convenient to copy/paste HTML directly, but other minor differences (in self-closing tags, for example) make this a losing battle and we have a HTML to JSX converter to help you anyway. Finally, to translate HTML to idiomatic React code, a fair amount of work is usually involved in breaking up the markup into components that make sense, so changing class to className is only a small part of that anyway.
Because JSX is shorthand for the DOM, not for the HTML serialization of the DOM. In the DOM API (the official W3C one, not React's), the property name is className.
Technically it's no longer just reserved in ES6, it has an actual use. But starting with ES5 it's generally not a problem to use keywords as property names.
