Technology

Eleni Chappen

What I’ve learned from a few large-scale React and Redux projects

Dec. 8, 2017

A friend of mine recently started a new job where he’ll be working a lot in React and Redux, and asked me if I had any strategies or best practices, particularly with large-scale projects.

I wish I could tell him that I do. But honestly, every time I make a framework-specific rule, I quickly come across a situation where the best solution is to break it.

What I have come up with are a few benchmarks that guide me to making sure my React code is understandable to other developers, and to Future-Me.

1. All of my logic is tested

When I ensure that all of my logic is tested, whether it’s component/view logic or action-related logic, I naturally fall into healthier coding patterns. I extract unnecessary responsibilities from my components. I write more helper functions and utility modules. I can better determine when state should be kept locally or remotely.

This also helps me determine what packages I want to introduce to my app. For example, people often debate whether Redux is an appropriate tool for their project. The co-author of Redux has even said that for many cases, local state is just fine. In my view, if Redux helps you test your logic, then you are gaining a big advantage by using it. Since reducers are supposed to be pure functions, testing them is incredibly straightforward. Action creators can be tested in isolation outside of your components. If you use any middleware to perform asynchronous requests, these can be tested in isolation as well.

Testing view logic should not be ignored either. If testing your components becomes cumbersome, or if you’re stubbing too many functions in order to test them, that’s a good sign your component is doing too much.

2. My Redux actions tell a story

Redux Dev Tools is indispensable to me when I’m building an app, and when I’m debugging one. These tools allow you to view all of your actions in real time, rewind and replay actions, and dig into the current state for each action.

The list of action names that Redux Dev Tools gives you should tell the story of your user. They should give you a crystal clear understanding what what your user is doing at any given time. An action like SEND_API_REQUESTED is way less understandable to a new developer than an action like USER_LOG_IN_REQUESTED, because it lacks the context of the user experience. Giving your actions this context helps a lot when debugging.

Redux actions should also show you the result of any asynchronous requests you make. So if I see a USER_LOG_IN_REQUESTED in my list of actions, I should know to expect a USER_LOG_IN_SUCCEEDED or USER_LOG_IN_FAILED action shortly afterward.
Using a redux middleware like redux-saga helps me keep track of asynchronous requests and their effects. With dev tools I can clearly see the order of these requests and the effects of their responses.

3. I know how to use a React component without looking up a working example of it in the codebase

If I’m looking at a component definition, I should be able to:

  1. determine whether this component is for global use or context-specific use. Often this is achieved by defining the component within certain directories, like components/elements/forms/textInput.js.

  2. know exactly what props this component receives. This can be done by using React’s prop-types package, which now allows you to more accurately define the shape of your props. So instead of doing this:

user: PropTypes.object.isRequired  

I can do this:

user: PropTypes.shape({  
  id: PropTypes.number.isRequired,
  first_name: PropTypes.string,
  state: PropTypes.oneOf(['pending', 'active', 'archived'])
}).isRequired

I feel like I’ve only scratched the surface here, but it’s a start. Happy coding!

Eleni Chappen

What People Are Reading

News

10/18/17

ChangeMaker Launches!

In a world where marches and protests are making weekly headlines, people are always looking for the next cause to get behind.

But what do you do when a cause or issue you’re passionate about needs more awareness and support? How do you find people to come together? How do you organize people, activities, events, and whatever else you might need to do? And if you do find people, how do you manage all the different moving parts?

And, well, what does that have to do with us at 20spokes?

Meet ChangeMaker -- a project we recently completed and launched.

Similar to sites like Kickstarter or Indiegogo, ChangeMaker allows organizations to add a project and find fellow activists to donate to or join the cause as a volunteer. The interface provides organizations the ability to detail an issue or problem, outline a solution, and how donors or volunteers can help. When people join the project as a volunteer, they can specify their particular skillset in fields such as marketing, design, legal, or data so project managers can delegate tasks to the right people.

With funding from donations, users can work on projects for their cause by using the free website. While most project management tools have some sort of fancy, pay-to-use features, ChangeMaker is completely free to use because it is donor funded and donor maintained.

We branded, designed, and coded the ChangeMaker platform in a Rails environment. We also integrated Stripe Connect, which enables organizations to receive those donations they need to power their projects.

Putting all this together sounds like it would take a good chunk of time, right? But we kicked off this project on August 8 and launched the website this week. A little more than two months. Not too shabby, eh? Just in time for the Newfounders Conference. ChangeMaker will have a big presence at the conference with donors ready to help out organizations that have ready-to-pitch projects for its demo night. Nothing is too small or too large for ChangeMaker to help its users and organizations tackle.

Give ChangeMaker a whirl at changemaker.newfounders.us.

Operations

8/29/16

Watch us eat our own dog food

20spokes is trying a new diet, so to speak. If you’re unfamiliar with the phrase “eating your own dog food,” it’s a common expression in the software world referring to a developer’s practice of using their own products. It’s said to have originated from 1970s television advertisements for Alpo dog food, where the owner of the company would make a point of feeding Alpo to his own dogs. So in its broader interpretation, “practice what you preach” would be an appropriate alternative. Either way, if we can help others build great products, we want to show that we can build our own great products as well.

It’s something we’ve thought about for a while, and now we’re finally taking the steps to make it happen. Client work will still always be our primary focus, but we have the team, the experience, and the aspirations; why wouldn't we work on our own ideas too? Like our clients, though, we don't want to jump into these ventures haphazardly only to end up with a well built app that nobody else wants. So we're putting these ideas through the same process of discovery, validation, and planning that we would with anyone who came into our office. In a way, by becoming clients of our own process, we’re getting our first helping of dog food!

Over the last week or so, we’ve adopted the mindset of a founder with a vision, and taken one of our ideas through the first steps of conception. Working through this process as the “founder” has already given us some great new insight, and we're excited to share this journey with you. So stay tuned for the next several weeks as we document all the steps we take and lessons we learn along the way; we're going to find out just how good our dog food tastes.

Trying to get your own product idea to market? Contact us to learn more about our process and how we can help.

Technology

11/20/17

Cross-Platform mobile development is cost-effective and faster to launch

Two years ago, if a person approached us for mobile app development, the first question would be what platform to launch on first - iOS or Android. It was almost double the cost to deploy on both and double the maintenance.

Fast forward to today, we can deploy on iOS and Android quicker before, at the same time, and with the expected native quality.

So what has changed? Technology has gotten a lot better. We particularly use React Native, an open source framework from Facebook, that allows developers to develop in a common language, Javascript, and deploy on both iOS and Android.

And it is native! Previous technologies for cross platform mobile apps would create a wrapper of a web view. Think of the older experience as using the browser on your phone for a site with a few more bells and whistles. It was close but the difference is noticeable when switching to native applications, from scrolling to the overall experience.

How does this impact everything now?

Cost is no longer double for both platforms. It can even cost less due to wide spread community support developing open source libraries.

Maintenance is a lot easier. A majority of the issues can be fixed in one code base and of the same language.

Recruitment and team knowledge is easier. Your team only need to know one language and most developers know Javascript. iOS is written in Objective C or Swift and Android is written in Java.

Reusable code for desktop web views. With React Native, we are able to share over 50% of the code with the web view, saving all of the above even more.

Stay tuned, as I’ll be going more into the technologies and other benefits.