This post is going to dig into to React Router 4, how it's so different from previous React Router versions, and why that is. My intentions for this article aren't to rehash the already well-written documentation for React Router 4. I will cover the most common API concepts, but the real focus is on patterns and strategies that I've found to be successful.
Let's take a look at Hoodie, the "Back-End as a Service" (BaaS) built specifically for front-end developers. I want to explain why I feel like it is a well-designed tool and deserves more exposure among the spectrum of competitors than it gets today. I've put together a demo that demonstrates some of the key features of the service, but I feel the need to first set the scene for its use case. Feel free to jump over to the demo repo if you want to get the code. Otherwise, join me for a brief overview.
Today we'll be adding authentication (via Google Authentication and Firebase) to our Fun Food Friends app, so that only users that are signed in can view who is bringing what to the potluck, as well as be able to contribute their own items. When users are not signed in, they will be unable to see what people are bringing to the potluck, nor will they be able to add their own items.
Suppose you've built a zippy new event listing React app for a client. The app is hooked up to an API built with your favorite server-side tool. A couple weeks later the client tells you that their pages aren't showing up on Google and don't look good when posted to Facebook. Seems solvable, right?
Monica Dinculescu on web components and why we might care:
... before web components came around, you had to wait on all browsers to agree on a new element (like, a date picker). And even after they agreed on a new element, it took them yeaaaaars to implement it... With web components, web developers get to write such elements, so that you don't have to wait for 10 years before all browsers agree that they should implement a date picker.
I'm probably wrong in conflating the two, though. Even the React Docs say:
React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary.
Let's take a look at building something using Firebase and React. We'll be building something called Fun Food Friends, a web application for planning your next potluck, which hopefully feels like something rather "real world", in that you can imagine using these technologies in your own production projects. The big idea in this app is that you and your friends will be able to log in and be able to see and post information about what you're planning to bring to the potlock.
React provides two standard ways to grab values from
<form></form> elements. The first method is to implement what are called controlled components (see my blog post on the topic) and the second is to use React's
Controlled components are heavy duty. The defining characteristic of a controlled component is the displayed value is bound to component state. To update the value, you execute a function attached to the
onChange event handler on the form element. The
onChange function updates the state property, which in turn updates the form element's value.
(Before we get too far, if you just want to see the code samples for this article: here you go!)
When does a project need React? That's the question Chris Coyier addressed in a recent blog post. I'm a big fan of Chris' writing, so I was curious to see what he had to say.
So today, I'm here to argue that the answer to "When does a project need React?" is not "it depends". It's "every time".