Learning ReactJS

I’m learning ReactJS.  The JSX approach a bit different from the JavaScript & HTML that is familiar to me, and I have been tripping over the syntax and assumptions. Perhaps you can learn from my mistakes.

There are multiple acceptable ways to create a React component.

  • vanilla JavaScript: var ClassName = React.createClass({ ... })
  • ES6 class: class ClassName extends React.Component { ... }
  • ES6 arrow function: const ClassName = (props) => { /* render */ }

I chose the ES6 arrow function syntax for components that only have a render() method, and the React.createClass() syntax for all other components.

It took me some time to realize that React is managing DOM element objects and attributes, not HTML or fragments or strings. I tried to create an opening tag with its attributes in JSX, and its closing tag as a string. That did not work, because JSX created an element. Instead, I learned to compose elements from subcomponents. A component must render a DOM element/object … it does not want to return multiple siblings, unless they’re wrapped in a single DOM element (e.g. div, span, p).

I used ES6 syntax where advantageous, especially the default parameters, arrow functions, and spread/rest parameters. This only works if you have a ES6 pre-processor in your development environment. The solution I chose was to write the app on plnkr.co. You could use CodePen.io or JSFiddle.net just as well.

One last issue… attribute names. The first component I created was a LABEL. It only has 1 meaningful attribute “for”. Or so I thought. “for” is the deprecated shortcut for “htmlFor”, just like “class” is used for “className”. Both “for” and “class” are JavaScript reserved keywords, which may be why they are not supported in JSX. Anyway, I will never forget that “htmlFor” and “className” are the only exceptions to HTML attribute names.

These articles helped me the most in getting up and running with ReactJS:

Empathy for Enterprise Developers

In a big company (or a small company acting big), many of us application developers can’t do common actions, e.g.

  • install open source or commercial software (not even development tools),
  • push 3rd-party software to production,
  • install the latest version of an already approved software,
  • allow open access to internal web apps,
  • write about work on the public internet or within the private intranet,
  • test web apps on personal devices or external services that aren’t within the company,
  • push to github or codepen or jsfiddle or npm,
  • demonstrate a prototype or proof-of-concept project,
  • ask or answer a question on a public forum,
  • etcetera, etcetera, etcetera.

A majority of application developers are in this situation, and many want to improve the place where they work. But how to do so? How to navigate the perilous waters of opaque approval processes, software certifications, security scanning, collective inertia, auto installation procedures? Who to talk to? What to do? Is it worth it? How do we keep the soldiers on the farm after they’ve seen Paris?

There are answers and strategies for success, and in many cases, the effort is worthwhile, for the company and for the enterprising enterprise developer. The answer does not have to be “leave” or “ignore” or “submit”.

I must write more about this…