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?
Bobby Grace, on the Dropbox Paper team:
On the engineering side, we use inline SVGs. These have many advantages. One advantage is that SVG is a well-structured format that we can manipulate with code. Paper is also using React and has a component for inserting icons.
- Use a single Sketch file, checked into the repo, as the place to design and house all the icons.
- Use gulp-sketch to extract them all individually.
- The build script continues by optimizing them all and building a source of data with all the icons and their properties.
- That data fuels the their
<SvgIcon />React component. (Also see our article).
They call it Papercons.
Now, whenever someone asks for an icon, we can just share a link to all the latest production icons. No more hunting, context switching, and long conversation threads.