Frontend

Using Flow to Write More Confident React Apps

Writing your first React app is simple with tools such as Create React App, but as your application and your team grow, it becomes more difficult to write scalable, confident code efficiently. Think about the number of times you pass props around a React application and expect them to look a certain way or be of a certain type, or the times when you’ve passed the wrong type of argument into a function and rendered a page useless. Fortunately, there are many solutions for these preventable problems, and one of the tools we’ve found helpful here at Rent The Runway is Flow.

What Is Flow?

According to Flow’s official website, Flow is a static type checker for JavaScript. After you install Flow, start the Flow background process, and annotate your code, Flow checks for errors while you code and gently alerts you to them. There are even Flow packages available for many popular text editors, which can highlight potential problems and provide explanatory text right beside the code itself.

Many times, Flow can infer how you want your code to work, so you don’t always need to do extra work, but it helps to be certain by actually using the static type annotations. In short, Flow checks how data moves through your app, ensuring that you’re using the types of data that you expect and forcing you to think twice before you reassign a variable to a different type, or try to access a non-existent property of an object.

Basic Example

Here’s a basic example of how to add Flow type checking to a file.

This is a simple component to display and edit data for a customer’s account.

Telling Flow that it should check this file is as simple as including the `// @flow` flag at the top of the file. Almost immediately, Flow will begin checking the file, and you’ll notice red dots in the text editor (Sublime) warning about potential problems. When we hover over those lines, we see additional information about the error at the bottom of the text editor.

After tackling the highlighted lines one by one, we’re left with a nicely annotated file:

Here, we’re doing the bare minimum to silence the red dots, telling Flow that the `constructor` method accepts a `props` argument that should be an object. (Flow allows you to be more specific, which we’ll show in a bit, but this suffices for now). In addition, we’ve explicitly declared the properties and types of each property for the class, which is part of Flow’s Class type checking capabilities. Now, the shape of state and the types of its properties are guaranteed, and we only had to do a bit of annotation for Flow to get started.

To be more explicit, we can also declare the types of properties that an object when supplied as an argument to a function must have. Below, on line 15 of the CustomerAccountProfile component (right), we specify that the props must have a customer property.

In that component’s parent, CustomerTabAccount (left), on line 75, you can see that when we try to pass in ‘null’ as a prop, Flow gives us a warning that ‘This type is incompatible with (object type)’.

To go one step farther, you could even declare the types of all the properties within props for the component. Now, if you try to reference a property that isn’t declared with the props, Flow will let you know that the property is not found.

Although this is just a sample of the many type checks Flow is capable of, the Flow documentation goes pretty deep into all the possibilities.

Advantages

What’s great about Flow is that it can catch errors early and help development teams communicate better about how components work together within an application. And although React’s PropTypes serve a similar purpose and are arguably simpler to use, they only throw errors at runtime rather than while you’re coding. Plus, since they’re declared below the component, they seem more like an afterthought.

Beyond the basics, adding Flow to your codebase is fairly painless, since it’s opt-in. You tell Flow to analyze a file by including a `// @flow` flag at the top of a file. This will mark it as a Flow file, and the Flow background process will monitor all Flow files. Files without the flag will be ignored, so you get to control which files you check and you can integrate it into a new or existing codebase over time.

It also plays nicely with ES6 and Babel, which strips out all the annotations for production.

Disadvantages

On the other hand, that same opt-in policy leaves room for neglect. Less diligent programmers can opt to forgo Flow altogether. In addition, there is a learning curve for type annotations, especially for new developers who aren’t used to type checking their code. What I find to be a bigger challenge is not getting started, but using Flow well. Basic type checking is useful, but Flow offers the ability to write very use-case specific type checks such as “Maybe” types, which check optional values and “Class” types, which allow you to use a class as a type. It’s easy to begin using Flow, but difficult to master all of its capabilities.

We began adopting Flow slowly in one of our retail applications, and as we continue building new features, we continue to convert older components to use Flow. Overall, it has helped us identify bugs sooner rather than later and has enabled easier refactoring because we can be more confident about the arguments functions accept and how different function invocations change a component’s state.

For more information on Flow and getting started, consult the official Flow documentation.

Resources

Official Flow Documentation

React PropTypes Versus Flow


iOS Data Binding is Better with Signals

Here at Rent the Runway, we want to make sure that all of our users have a responsive and rewarding iOS mobile app experience. With our backend architected to use many highly performant microservices, there is a whole lot of data and user interactions to keep in sync. We have services for user memberships, promotions, products, search categories, user hearts, and so much more. Without a one-to-one mapping of API service calls to application views, it was critical that we come up with a robust and coordinated approach for data binding and content updates.

One of the main iOS communication patterns is delegation. Delegation creates a one-to-one messaging structure between two objects, where one object can act on behalf of another. Using this pattern, it is typical that a completed API call would inform its delegate object that new data exists and is ready for processing and/or display somewhere else in the app.

On this diagram we can see that we have several UIViewControllers (ProductCollectionsVC, ProductsGridVC, ProductVC) that hold a ModelController (HeartsMC), which is responsible to fetch all the hearts from a user. 
While this approach is useful in many situations, it makes it difficult for communicating data updates from one object to many objects at the same time as we can see on the diagram.
 
As an alternative to delegates, we can use ReactiveCocoa’s framework to use signals for communication. In short ReactiveCocoa is a functional reactive programming framework which represents dataflows by the notion of events. An event is just a concept that represents that something happened, which could represent a button being tapped or the status of a network call being made. ReactiveCocoa uses Signals and SignalProducers to send messages representing these events.  A Signal will only notify an observing object of events that have occurred after the observer has started observing, not any past actions. On the other hand, a SignalProducer allows you to start observing for an event but also have the visibility for past and future events.

ReactiveCocoa explains these concepts by comparing them to a person (the observer) watching television (the signal or signal producer). 

[A signal] is like a live TV feed — you can observe and react to the content, but you cannot have a side effect on the live feed or the TV station. [A signal producer] is like a on-demand streaming service — even though the episode is streamed like a live TV feed, you can choose what you watch, when to start watching and when to interrupt it.
— https://github.com/ReactiveCocoa/ReactiveSwift

Signals work very well for UI events like tapping a button, where an observer would only be interested in reacting to touch events after it has started observing. A Signal Producer would be more useful for a network request, where its on-demand nature would help provide more contextual information about a network request, such as allowing an observer to know if it is in progress, has it previously failed, should we cancel it, etc.

Objects throughout our app can then observe these event-driven signals and take any action they need to bind data to views, process data, or trigger any other actions. This allows multiple views and viewControllers in our app to be notified of data changes at the same time without the need for complex delegation chains. 

In the code snippet above, we are setting up signals for a modelController. When it receives a signal, it can call a method that is defined by our protocol. If we were to configure these methods and interactions with a delegate, other ViewControllers would not receive any message and would not know to update their data.

In the app, we have a TabBarController that allows users to quickly switch between viewControllers that provide different functionality. However, we do have some shared data sources between these controllers, so our signals allow us to update data on every accessible viewController so the user can interact with them immediately after switching tabs.

This approach has been very helpful for broadcasting changes of the datasource on a ModelController throughout the app. While implementing, we paid special attention to weak/strong references with our observers to prevent retain cycles, routinely testing that objects were being deallocated when needed. Additionally, deadlocks can occasionally occur if signals trigger other signals that are dependent on the completion of another signal. However, with well thought out protocols and implementation patterns, we have been able to provide a responsive and stable app experience for our users.


Refactoring Sass with Lists and Maps

At Rent the Runway, we have an internal tool to easily create emails for our customers. It’s a Rails/React system that turns .erb template files into SailThru-compatible layouts (SailThru is our software for sending customer emails).

In this repo we use Sass utility classes. If you’re unfamiliar with utility classes, they’re usually classes that contain a single CSS rule, like so:

.left { text-align: left; }

They’re useful for highly descriptive markup – in our case, creating inline styles for emails. For example, to align your text left in an email, you would use the above class like so:

<td class=”left”> Here is some left-aligned text. </td>

See this post on CSS tricks for a great summary of why inline design is commonly used for emails. Using utility classes allows us to more easily match inline styles to particular email elements.

However, creating stylesheets for utility classes can get messy. We quickly ended up having a number of stylesheet partial files that contained quite repetitive CSS blocks:

The padding partial had almost 200 lines of definitions like that! We had similar problems for heading definitions and background colors:

I could go on, but you get the idea – not very DRY and awkward to add to. What do you do if you quickly need another padding utility class? Just add it onto the end, and worry about duplication later. These stylesheets were getting unruly, unreadable, and impossible to maintain. It seemed like a great opportunity to refactor using two cool Sass features: lists and maps.

First up, we refactored the padding partial to use lists – similar to arrays in other languages. The padding classes were mixed up and mostly named after the padding pixel value specified (e.g. .padding-left-25px). However, a couple used comparative suffixes – e.g. padding-left-max. Our first job was to standardize all the classes to use pixel values in their class names. It’s easier to understand `.padding-left-25px` than `.padding-left-max`.

Next, we grouped all the classes by rules: whether they specified one particular padding (e.g. padding-left), two sides (e.g. top and bottom) or all padding.

Already it was easy to see that there were a couple of duplicate rules. Those could be deleted. The next step was to turn the necessary values into a list. Lists in Sass are incredibly easy to create: just take all values and separate them with commas:

$padding-left-values: 5px, 10px, 20px, 30px, 50px, 70px;

Then, we could use the @each function of Sass to loop through all the pixel values. Using interpolation with #{} , we could name the class appropriately and give the padding value:

@each $px in $padding-left-values {
  .padding-left-#{$px} {
    padding-left: $px;
  }
}

This produces all the classes I need without having to type them all out manually. Also, it makes the process of adding a new padding class far easier: just add the px value to the list.

The next challenge was to refactor the heading sizes. Again, there were a number of repeated classes detailing the various header sizes. However, this time they were named based on relative sizes (e.g. small, medium, large) rather than the absolute pixel value that was found in the style rule.

This called for a map – similar to objects in JavaScript or hashes in Ruby. The heading sizes map had keys that corresponded with the name, and values that corresponded with the pixel size of the text:

$heading-sizes: (
  smallest: 25px,
  small: 36px,
  medium: 40px,
  large: 80px,
  largest: 110px
);

As with lists, you can loop over a map using the @each function. As we’re using both the key and the value, you define both of those first.

@each $size, $px in $heading-sizes {
  .heading-#{$size} {
    @include times($px);
  }
}

Notice here that we’re already using a mixin – times() – that sets an appropriate font family, size, and calculates a line-height based on the font-size passed in.

We did a similar thing with colors, using a color map to loop through and create utility classes for background colors:

$colors: (
  // Primary copy
  midnight: #272c32,
  cotton: #fff,
  // Accent
  tan: #cd9365,
  fawn: #c79176,
  tangerine: #e85940,
  error: #eb5840,
);

// Background colors file

@each $color, $hex in $colors {
  .#{$color}-bg {
    background-color: $hex;
  }
}

Both of these compile to CSS similar to our bloated Sass stylesheets from before. However, it’s much easier to add, remove, or check for duplicate colors or header sizes in this system. Let’s say a new seasonal color needed to be added – rather than having to write out the whole class definition, just add the name and hex value to the colors map.

What’s more, it always feels so satisfying making a commit with more deletions than additions, don’t you think?


Evolving Our Style Guide to Better Unite Designers and Developers

Exactly two years ago Jess Brown wrote Bridging the Design-Development Divide. Her post summed up Rent the Runway’s efforts to create consistent styling, and then translate that styling into Sass variables and classes for easy reuse. This ultimately was embodied in a style guide that lived in GitHub Pages and was publicly accessible.

  Jess Brown’s GitHub Pages style guide

Jess Brown’s GitHub Pages style guide

The style guide that Jess created greatly aided in developer-designer relations by ensuring designer mockups were consistent with the colors and Sass stylings powering the site. However, because it was separate from our site and we were rapidly evolving our brand identity, the GitHub Pages style guide quickly fell behind our storefront stylings. There was nothing forcing the guide to be kept up-to-date.

Since Jess’ creation of the first robust style guide for RtR, the company underwent a rebrand as well as a shift towards using React. This created a new opportunity for a more dynamic system of presenting, maintaining, and using our styles. React allows for the creation of reusable components of varying scales such as a button, product card, or even carousel of products. Components can be nested and reused for various purposes, allowing for flexible building blocks to be created for pages. By taking the elements of the styleguide and translating them into React components, we are able to ensure consistent stylings across the site’s elements.

In tandem with the translation of site elements into components, we moved the style guide into the same code base as the storefront. This means that the style guide is powered by the same Sass files that power the site’s front end. Change the font on a button in the style guide and it is instantly reflected site-wide!

  The new React component based    style guide   .

The new React component based style guide.

We then categorize these components for easy discoverability according to Brad Frost’s Atomic Design principles. This means that small components such as buttons, links, etc. are labeled as “atoms.” Collections of atoms are categorized as molecules and so on. If you are interested in creating an atomic design style guide for your own use, checkout patternlab.io. It provides templates for creating style guides that are organized by atomic design principles and served as an inspiration for Rent the Runway’s guide.

So this all sounds great, but one of the biggest challenges is getting cross team collaboration and buy-in to ensure that the living style guide becomes an effective manner of generating consistent styles and fast paced development. For the engineering team, I presented to the Architecture Review Board (ARB) for the introduction of a new grid system in tandem with the style guide. At RtR, we use "ARBs" to screen changes to the way we work, such as using new libraries, or accepting new naming conventions. The ARB for the guide was accepted and the new grid and stylings are being used on Rent the Runway’s pages today. For the product and creative teams, I created Sketch and Photoshop templates of the elements and grid system for use by PMs and Designers, ensuring that the designs the engineering team receives can be built by the frameworks and components in the style guide. In theory, this combined toolkit means every design being passed from a UX designer to a front end engineer can be built by laying out React components from the style guide using the new grid system which in turn greatly reduces repetition of code and speeds up development times.

We will continue to advocate the use of this guide for cataloging, onboarding, and accessibility purposes. By centralizing our styles onto the same Sass codebase, we hope to ensure seamless translation of UX/UI designs into pages.

And one last thing: The new React Styleguide is publicly accessible right on renttherunway.com!


A Post-Internship Look at RTR

This post was written by our awesome colleague, Maude "It's pronounced 'Mode'" Lemaire, whom we can't wait to welcome back after she finishes school.


I left New York City a few hours ago with every intent to return. Yesterday marked my final day as a tech intern for Rent the Runway but I still feel as though I'll be back on Tuesday, grabbing myself an ice coffee from the kitchen and tackling some new bugs. Needless to say it'll be strange heading to class bright and early and hitting the books once more.

I spent thirteen weeks working alongside some of the most insightful engineers at Rent the Runway's SoHo offices. Within just three months, I learned more than in a single semester of university. Pat (Newell) & John (Holdun) have taught me about writing efficient JavaScript, best CSS practices, and using Backbone to solve just about every problem. After a few weeks, I developed a decent understanding of Ruby where I had none whatsoever previously.

From my experience this summer, I learned most from the code review process. At Rent the Runway, when you're working on a new feature or fixing a bug, you start on a local branch. When you think it's all good, you make a pull request to merge your changes onto the master branch. At that point, your peers will review your code. They'll make comments about syntax, a block of code you can reduce to a single line (sometimes), and the bigger picture of your solution; sometimes it turns into a big discussion about how your code will scale and evolve with future features on the horizon. Although it might seem harsh at first, you have to go into the code review process with an open mind and hope to come out of every pull request a better programmer than you were before.

Everyone's constantly talking about building a scalable, maintainable system. There are discussions about the best practices everywhere you turn in the office. Don't know how a system works? Open up your chat and ask someone you think might know. Don't know the specifics of Ruby syntax? Just turn around and ask someone! You'll find experts in a bunch of niches and it's an environment that makes it incredibly easy to learn a ton of new things. As an intern, it's a perfect opportunity to turn to your neighbor and ask them a million questions about what they know! I was able to learn about product, business strategy, marketing and buying in addition to tech just by having coffee chats with coworkers. In terms of work experience diversity, you truly can't beat the Rent the Runway team.

The amount of women in tech at Rent the Runway is surprising. I wasn’t prepared to see so many, coming from a university program where barely 9% of us are women and having worked an internship the previous summer where I was the only woman on my team. It was great to see that no matter what background any programmer was coming from, everyone was open to their ideas. No need to prove yourself (which I've had to do in certain cases) – you're instantly an important part of this dynamic group of hardworking engineers. Even though I was "just an intern," I found that I was the only one ever saying anything of the sort. To my team, I wasn't "just an intern;" by the end of the summer, I was given just as much work as my coworkers and writing as much production code. There were certainly times when I seriously screwed up a pull request with a million rebasing related commits and caused a fair share of JavaScript errors but I'm happy to say I fixed more problems than I caused.

About a month before my original end date of August 22nd, I was sitting down with Jade, the team lead on our current project, when he asked when I'd be heading back to Montreal. At the time, I'd heard about Hack Week during the last week of August – a full five days of working on anything you wanted (so long as it made Rent the Runway better) and I desperately wanted to stay the extra week. With his support, my internship was extended by a week and I was able to stay and participate in the festivities. To top it all off, a few weeks later I was given a full-time offer! Beyond the perks of free rentals, unlimited vacation, and living in NYC, it's an opportunity I simply cannot pass up. Between the people in tech at RTR and the opportunity for fast-paced growth, Rent the Runway is a really (really) great place to work and you can count on me coming back after graduation.