Bring your animations to life with physics
If you’re familiar with AngularJS you already understand many of the principles necessary to get started with React. In this post, I’ll demonstrate how to write the equivalent of an ngRepeat inside a React component.
I’ve been using Angular in my web apps for the last four years, but I recently became interested in React so I started the learning process. As usual, I dove in blindly, fumbled around with various tutorials until I felt comfortable enough to build something useful. With a few React apps under my belt now, I want to share what I’ve learned with other Angular developers who may be trying out React for the first time. In this post, I’ll start from scratch assuming you know nothing about React. I will try to help correlate Angular concepts with their React counterparts so you can start to build a mental model based on something you already know.
This post is not a tutorial. There are enough of them on the Internet. It is always more interesting to look at a real production app. A lot of tutorials and boilerplates show how to write isomorphic ReactJS applications, but they do not cover a lot of real-life problems we’ve faced in production (styling, data-fetching, vendor-prefixes, configutation etc). So we decided to share our experience at github and develop the app in a public repo. The post describes all the issues and howto to deal with them.
For giving us React and Flux, I’ve seen relatively little about integrating Facebook’s own Graph API with their development tools. The tools are so new that there’s precious little instruction out there about how to answer questions that are easier to answer with other architectures, like:
With the Mongoose adapter for Graffiti, you can use your existing Mongoose schema for developing a GraphQL application.
We are going to cover the following topics:
Building a frontend application is hard. Compared to building backend applications, you have way too much mutable state to manage and in the end your whole code base is so complex that nobody wants to touch anything.
We already know how to build backend applications - generating html, sending it to the browser, repeat - without it ending in a nightmare of complexity, but building frontend stuff is very complicated. Backend is easy, frontend is hard. So, why don’t we just build the frontend like the backend?
Programming is a bit like gardening. While trying to keep the bugs out, we prefer to keep everything neat and organized lest we want to end up in the jungle. A poor structure just slows us down and makes it easier for bugs to crawl into the system.
There are multiple ways to structure your project. I believe it is far better to evolve the structure as you go rather than to stick with some dogma. I will go through some basic approaches next to provide some food for thought.