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.
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".
The "normal" workflow I'm sure we've all lived is that design happens, then coding happens. A healthy workflow has back-and-forth between everyone involved in a project, including designers and developers, but still: The code is the final product. You design your way to code, you don't code your way to designs.
It was only a little over a month ago when it was news that Sketch 43 was moving to a .JSON file format. The final release notes drop the news quite blasé:
Revised file format
But Jasim A Basheer rightly made a big deal of it:
... it will fundamentally change how the design tools game will be played out in the coming years.
"enables more powerful integrations for third-party developers" is stating it lightly. This is what the fine folks at Bohemian Coding has done — they opened up Sketch's file format into a neat JSON making it possible for anyone to create and modify Sketch compatible files.
As the need for these libraries fades, and we see a massive rise in new frameworks, I'd argue it's not as clear when to reach for them. At what point do we need React?