This year picked up on several of the themes introduced at last year’s inaugural conference: GraphQL was a big player, popping up in a handful of talks throughout the weekend, as was performance (including discussions on ways to increase both raw speed and overall perceived performance). ReasonML, the subject of an enthusiastic presentation by Marcel Cutts last year, starred in Ken Wheeler’s Saturday morning keynote. In addition to the usual suspects, React Boston also offered a stunning array of talks showcasing how people are using React in creative, boundary-pushing, useful, and whimsical ways. Keep reading for some of the highlights.

Component libraries make life easier for everyone

In a gorgeously illustrated talk on Saturday morning, Samantha Bretous emphasized how a component kit—a shared library of reusable, well tested, cleanly encapsulated components—can improve efficiency, help isolate bugs, reduce the overall size of your codebase, and ensure that users have a consistent experience across your application.

Bretous laid out a clear guide to building a component kit, involving strong communication pathways between designers and engineers, and a suite of tools—including Zeplin and StorybookJS—that her team has found helpful for organizing and documentation. To avoid the complications—inconsistent UIs, developer decision-making overhead, code proliferation—that result from custom CSS, Wayfair’s Artem Sapegin recommended building a series of primitive components that can serve as building blocks for a larger design system. Proud of the kit component library you’ve built, or looking to augment it? Jason Clark’s lightning talk introduced Bit, a cloud-based tool for hosting, sharing, and collaborating on components.

GraphQL is going strong

Chris Toomey highlighted how using GraphQL—in particular, GraphQL fragments—helps with code organization, letting each component specify its own data needs alongside its JS, CSS, and markup. Individual fragments—like individual components—can be composed to make up larger, more complex queries. Combining React, GraphQL, TypeScript, and the Apollo CLI means each component can structure its type definition around these fragments, making the development process “simple and correct.” In her talk on learning the React Native ecosystem as a junior engineer, Erin Fox agreed, pointing to GraphQL as a “booster seat” that helped her jump start her career. Shawn Swyx Wang followed up with a demo of babel-blade, which solves the “double declaration” problem—where the structure of a data object is specified both in a GraphQL query string and in the component that uses the data—by intelligently building queries for you based on how data is used.

React is all around us

Audience anticipation for the Saturday afternoon demo by Vladimir Novick—who blew minds last year by flying a drone inside of Wayfair’s offices—was high. Novick’s talk on building augmented reality applications with React did not disappoint. After a quick timeline of AR (first introduced by L. Frank Baum—as in, The Wizard of Oz—in 1901), Novick dropped a six-foot-tall monster next to the podium and then took us through a portal into Wakanda.

Novick’s detailed slides included a deep dive into the code and tooling behind the demo. Following on Sunday, Matt Hamil blended cutting-edge React360 virtual reality technology with old-school nostalgia, demoing an entirely React-powered, 3D version of Frogger. Hamil also noted the new UX challenges and accessibility considerations that come with 3D applications and developing for different input devices, urging engineers to take responsibility for accessibility as they begin building in a third dimension. This point arose several times throughout the weekend, including in Josh Comeau’s Saturday morning talk, a call for whimsy that blended a discussion of how web animations and delightful UX surprises can improve user experience (and companies’ bottom line), a practical walkthrough of several examples, and an emphasis on the importance of accessibility over “wow” factor when implementing these kinds of features.

People are thinking about performance

While Comeau’s talk focused on how we can improve perceived performance, a number of other presentations covered how to assess and speed up load times. Christina Keelan Cottrell’s lightning talk on Lighthouse, a Google open source tool that offers performance and accessibility audits, used Wayfair as a sample use case to show how addressing a few common pain points can dramatically speed up performance. Houssein Djirdeh shared several additional tools—including the Profiler in React 16.5—to measure performance metrics and make addressing performance bottlenecks easier.

Tejas Kumar gave a Pokemon-themed demo of suspense, a new React API (still a work in progress) that can help prioritize rendering of different components based on when data becomes available. First announced at JSConf Iceland in March, suspense lets you “pause any state update until the data is ready, and… add async loading to any component deep in the tree without plumbing all the props and state through your app and hoisting the logic.” Cole Turner turned the focus from upping speed to slimming down content, sharing tricks for how to render less in a puppy-filled presentation on performant layout.

Everyone loves a challenge

One hundred and eleven of React Boston’s attendees had their interest piqued and their knowledge tested in Wayfair’s React quiz. However, zero of them were able to achieve a perfect score.

The effort involved in setting up a React-flavored challenge was a fascinating and fun learning experience. Watching people furrow their brow trying to remember how comparison operators resolve was entertaining, even after experiencing the heartbreak of looking into someone’s face as you reveal their 1 out of 11 score. It was great to listen to the chatter around some of the questions as groups began to crowdsource their problem solving.

While Wayfair enjoyed generating a little buzz around an impossible quiz, many of the team expected participants to google their way to 100%, or quit halfway through taking it.

What we didn’t expect was the sheer number of submissions. Overall, a big shout out is in order for everyone’s good spirit and participation. React Boston is about bringing our community closer together and raising our collective bar. Watching participants throw yourselves at a challenge like this made the Wayfair quiz custodians smile.

[x] The ref function will be run each time the component renders.
[x] It will create a new instance of the function for ref each time it renders.
[x] this.title will be the DOM element of h2 after the component is mounted.

Hardest questions (deep dive)

In the interest of furthering all of our understanding, we want to break down two of the hardest questions in terms of incorrect submissions.

Hard Question One:

What of the following statements are true, regarding the `ref` usage in the snippet below?

From the author of the question, Wayfair software engineer Yinlin Zhou:

The ref function will be run each time the component renders.

“If we use an inline function for ref, the ref function will be run each time the component renders. A new instance of the function will be created each time the component renders, so ref needs to clear the old one and set the new one, so it’ll be run each time the component renders. More precisely, it’ll be called twice during updates (for reference: https://reactjs.org/docs/refs-and-the-dom.html#caveats-with-callback-refs).”

It will create a new instance of the function for ref each time it renders.

“Because of the anonymous, in-line nature of the function, it will create a new instance of the ref function each time it renders.”

this.title will be the DOM element of h2 after the component is mounted.

The reference will be the DOM element after the component is mounted, and will go back to null when it unmounts.

“Believe it or not, way back in the days of Netscape 1.x some browsers didn’t understand the <script> tag! This meant that we needed to use HTML comments in script tags so that the browser wouldn’t render our JavaScript directly on the page. While this is no longer relevant, HTML-like comments are still in the spec: https://www.ecma-international.org/ecma-262/#sec-html-like-comments. In this example we’re using a single line HTML-like comment to ignore all code after the `<!–`. This means we have an IIFE with no input, so the return value will be undefined.

Wrapping up an amazing weekend

Covering all of the amazing conversations had and resources shared this during such an event is a challenge—React Boston also featured demos of new tools to help mock GraphQL schemas, manage React state more simply, and make large scale code migrations more straightforward; talks on unit testing best practices, improving the code review process from both ends, and easter eggs across multiple projects; and a tricky quiz that tested the boundaries of participants’ JavaScript knowledge.

For those who weren’t able to be there, videos of all talks are available now; head over to the Wayfair Tech YouTube channel to start watching.

Looking for a few other great recaps? Some fellow presenters shared their own thoughts and experiences, too.

Wayfair is incredibly humbled to be actively contributing to and learning from the global React community. React Boston’s schedule featured many who’ll still be on the conference circuit through to the end of the year; React Day Berlin is one such event. Until next year, we’ll keep sharing and participating on all fronts around ReactJS. Bring on React Boston 2019!