DEV Community: Riccardo Coppola

Build feature flags in React using the Context API: how to

Riccardo Coppola — Mon, 30 Mar 2020 09:27:00 +0000

One of the tenets of lean development is "deliver fast, deliver often".

Now, this can become tricky when you have to add new, big features to an application that is already live, or you have to delay a release to a specific day (e.g. changing the landing page for a big sale).

How can we build (and leverage) feature flags (or feature toggles) to improve both the development/release workflow and the user experience?

The case for releasing features "in the dark"

Suppose you have a successful, high traffic blog built in React and you want to add a list of featured posts at the top. The first step would be to break this feature or epic down into smaller stories with your team.

Let's assume that these are the stories you come up with:

create an empty container for the featured posts
display a list of unstyled posts
add style to the list of posts
add UX behaviour to the list of posts, such as a link to the post page and author page

You can expect to have other work ongoing in parallel, like maintaining the blog, making small UI changes etc so how do you handle this big feature release? You definitely cannot go live with an empty container at the top of the page, or with a list of unstyled text that has no behaviour.

One solution may be to create a long-living branch that you rebase on to master as often as you manage to remember (and fix all the conflicts every time), and build the whole feature there, then do a big-bang release of all the code. I don't need to go on to explain why this is a bad decision on so many levels.

Another solution is to use feature flags to wrap your new feature so that you release the code to production as often as you want, following your usual development/release workflow, you just don't display it to the user.

Following is an example:

// This configuration can come from wherever you prefer:
// a config file, a mongo database, etc
const features = {
  featuredPosts: false
};


// In your react component
import FeaturedPosts from "./featured-posts";

const HomePage = ({ features }) => {
  return (
    <article>
      // ... other content
      {features.featuredPosts && <FeaturedPosts />}
      // ... other content
    </article>
  );
};

So the idea behind feature flags is to ship code "in the dark", without the user seeing it.
This way you can keep your big feature within your normal development/delivery flow, just hidden from the final users.

React implementation

I want to create a small component to wrap content with so that I can decide whether or not to render it based on the value of a feature flag.

To keep this as simple as possible, the following is the way I see this component being used:

import FeaturedPosts from "./featured-posts";

<Feature name="featuredPosts">
  <FeaturedPosts />
</Feature>

This is a very declarative, React-like way of consuming features.

Where do I get the features' list from, though? And what a possible implementation may look like?

React Context can help inject a list of features into the application and retrieve it later, as for the component implementation, let's have a look:

import { createContext, useContext } from "react";

const FeaturesContext = createContext();

export const FeaturesProvider = FeaturesContext.Provider;

export const Feature = ({ name, children }) => {
  const flags = useContext(FeaturesContext);

  if (!children) { return null };

  return flags[name] ? children : null;
};

First of all, I am creating a FeaturesContext to be used later to wrap my app.

The Feature component then takes the feature's name and the children and based on the boolean state of the feature, it'll either render the children (if the feature is enabled) or null. It can do it because it's got access to the list of feature flags from the context.

Following is a usage example:

import FeaturedPosts from "./featured-posts";

const HomePage = () => {
  return (
    <>
      /* other content */
      <Feature name="featuredPosts">
        <FeaturedPosts />
      </Feature>
      /* other content */    
    </>
  );
};

const features = {
  featuredPosts: true,
};

const App = () => {
  return (
    <FeaturesProvider value={features}>
      <HomePage />
    </FeaturesProvider>
  );
};

Adding MVT (MultiVariate Testing) support

The use case for MVT is when you want to try out different variations of the same feature (e.g. trying out three different colors for call to action buttons) to see which one is the best performer.

We can easily extend the Feature component to support MVT by adding a variation property:

export const Feature = ({ name, variation, children }) => {
  const flags = useContext(FeaturesContext);

  if (!children) return null;

  if (variation === undefined) {
    return flags[name] ? children : null;
  }

  return flags[name] === variation ? children : null;
};

In the code above, if we don't receive a variation, we treat the flag as a Boolean otherwise we only render the correct variation.

Demo

Thoughts on deployment environments

Many projects are deployed through a series of environments (dev, staging, pre-prod, add your name here) before being released to production.

This can allow for additional levels of testing, usually E2E tests, to be carried out. You can fully test the code behind a feature flag by having different settings for different environments: one of the practices that I'd use is to have all features enabled on a staging environment and run all level of tests against them, then have them turned off in pre-prod and prod.

This way you have the confidence of having well-tested features and the ability to keep them hidden until it's release time.

Feature flags and technical debt

Technical debt is a reality in every application we build. It can be kept under control, but real-life scenarios call for technical debt to be created in order to deliver faster in some periods or accommodate for temporary business requirements.

It is like a loan: you need it, but you also need to have a plan in place to pay it back.

Feature flags add to technical debt because they are part of the code only for a short amount of time and need to be removed afterwards, without actually being a user feature.

This doesn't mean they shouldn't be used, the opposite actually, but there must be a plan in place to clean up the code: every time you use them, make sure your stories include points about removing the feature flag wrapping your code and update the tests to reflect the presence of the feature, plus anything else you may have to do.

Enjoy your improved workflow!

Replace Redux with Hooks and the Context API: how to

Riccardo Coppola — Mon, 16 Mar 2020 10:31:00 +0000

Is it possible to use the new React Context API and hooks to completely replace Redux? Is it worth it? Does it yield the same results and is the solution as easy to use as Redux + React-redux?

With the advent of the new React Context API, passing data deep down in an application became easier and with the new hooks, I started to see a lot of posts advertising that replacing Redux was possible. I wanted to find out for myself, so I started looking closer at the React docs and try to build my own Redux.

The following is what I found out and what I came up with.

Context API

One of the challenges of React is how to pass props to components deep down the tree; props that are "global" to the application, that many components may want to use and usually represent configuration, UI theme, translations.

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

How to use it

To start building a Redux-like library, I want to make available a state object and a dispatch function to the whole application, so let's build an example that takes advantage of the Context API and does just that:

import React from "react";

// Create a context with a default value
const StateContext = React.createContext({
  state: {},
  dispatch: () => {}
});

const ComponentUsingContext = () => {
  return (
    // Wrap the component using the value with the context consumer
    <StateContext.Consumer>
      {({ state }) => <div>App state: {JSON.stringify(state)}</div>}
    </StateContext.Consumer>
  );
};

// Wrap your component with the provider and pass a value 
// if you don't want to use the default
const App = () => {
  return (
    <StateContext.Provider
      value={{
        state: {
          counter: 1
        },
        dispatch: () => console.log("dispatch")
      }}
    >
      <ComponentUsingContext />
    </StateContext.Provider>
  );
};

The above is a quick look at how you can use the Context to send data down the components' tree, and it doesn't look very different from the React Redux Provider that you use to wrap your app with.

Note how you create a Context first, then use the Context.Provider to send data down into the tree and Context.Consumer to use that data at any nesting level.

The part using the Context.Consumer looks a bit more complex than I'd like, but there is a hook that makes it look at lot cleaner (more on this in a sec).

Now that we have a way to "inject" data into an app, let's see how we can leverage hooks to build the additional features required to replace Redux.

Hooks

Hooks were introduced in React 16.8.0 to tackle different classes of problems:

Making it easier to reuse stateful logic between components
Move away from classes, their inherent verbosity and the use of this
Making more use of ahead-of-time compilation to create optimised code (and classes can encourage patterns that make it difficult)
Probably other reasons, which I am not aware of 😇

Among all the hooks that come with React, useContext and useReducer are the ones that can help build a Redux-like library in React.

`useContext`

const value = useContext(MyContext);

It is an alternative to using the Context.Consumer pattern (and makes the code looks more readable in my opinion).

Let's see it applied to the previous Context example:

import React, { useContext } from "react";

const StateContext = React.createContext({
  state: {},
  dispatch: () => {}
});

const ComponentUsingContext = () => {
  const { state } = useContext(StateContext); // <---
  return <div>App state: {JSON.stringify(state)}</div>;
};

const App = () => {
  return (
    <StateContext.Provider
      value={{
        state: {
          counter: 1
        },
        dispatch: () => console.log("dispatch")
      }}
    >
      <ComponentUsingContext />
    </StateContext.Provider>
  );
};

You still have to use the Context.Provider, but retrieving the values from the context looks a lot better now.

`useReducer`

const [state, dispatch] = useReducer(reducer, initialArg, init);

The useReducer hook accepts a reducer (same as you'd write for Redux) and an initial state and return the new state with a dispatch method.

state and dispatch are exactly what I need to pass down the application through the React.Context.

Trying to put things together

The API of my Redux-like library should include:

a Provider to wrap the app and inject the state and dispatch method
a useStore method to create a store (containing the state and dispatch method) to pass to the Provider
a connect method to hook a component to the state

Provider

The provider would simply be a Context.Provider:

const Context = React.createContext(); // No default needed here

export const Provider = Context.Provider;

connect

A very basic connect would accept a Component, then make use of the useContext to get the state and dispatch and then pass them to it.

export const connect = Component = () => {
  const { state, dispatch } = useContext(Context);

  const props = { state, dispatch };

  return React.createElement(Component, props, null);
};

This is of course a very basic version, that passes the whole state to the component: not exactly what I want.

Introducing `mapStateToProps` and `mapDispatchToProps`

The Redux connect method makes use of mapStateToProps to map the whole state to the props that the component needs.

It also uses mapDispatchToProps to pass actions wrapped by the dispatch method as props to the component.

I wanted to support those methods too, so this is an improved version, that also supports the component's own props:

export const connect = (
  mapStateToProps = () => ({}),
  mapDispatchToProps = () => ({})
) => Component => ownProps => {
  const { getState, dispatch } = useContext(Context);
  const stateProps = mapStateToProps(getState(), ownProps);
  const dispatchProps = mapDispatchToProps(dispatch, ownProps);
  const props = { ...ownProps, ...stateProps, ...dispatchProps, dispatch };

  return createElement(Component, props, null);
};

So here I added support for mapStateToProps and mapDispatchToProps, providing a default value that returns an empty object in case those arguments are not provided. I then added the dispatch method so that the component can use it to dispatch actions.

useStore

This is just a utility hook that uses useReducer to create a store and returns it, pretty much like createStore in Redux. It also creates a getState function that returns the state.

export const useStore = (reducer, initialState = {}) => {
  const [state, dispatch] = useReducer(reducer, initialState);

  const getState = () => state;

  return { getState, dispatch };
};

The following snippet puts it all together in the same file to make it easier to read and understand:

A working example

Here's your usual counter example using the code I just discussed (notice my CSS skills):

An important note about re-renders

You may wonder how the application re-renders since I am never using setState, which is a requirement to trigger a re-render in React.

In Redux, the connect method triggers a forceUpdate when the store changes, but here?

The solution lies in how the useContext hook works:

A component calling useContext will always re-render when the context value changes.

Where to now?

Of course, this example is not nearly as powerful as Redux is, but it proves that Redux can be replaced by Context + Hooks.

Is it the right thing to do, though? Is it the right pattern to package these new React features into a Redux-like library?

I believe that these new tools give us an opportunity to find new patterns and leverage the reusability provided by hooks to find better ways to share and access application state at any nesting level.

We'll find the "right way" iteration after iteration, in true agile spirit.

This article was originally published on onefiniteloop.io.

10 tips for working with distributed teams

Riccardo Coppola — Sat, 14 Mar 2020 20:21:14 +0000

Remote teams have become the norm, rather than the exception, for many companies requiring software engineering services (and not only).

They used to be just a small addition to the core, in-house team, but it is not uncommon for them to now represent the bulk of the development force.

It's not always the case of a company hiring a third party to do the job, sometimes it's just having to coordinate multiple teams of the same company, operating from different locations with different time zones.
There are multiple reasons for this choice: cost, multiple company locations to manage, strong talents availability in less competitive markets, strategic choices and so on.

Hewlett-Packard (HP) uses these teams to meet the demands of local economies across the world, and as an HP executive states

We are very dependent on working across the world. It’s our survival, the key to our success. We cannot be a U.S.-centric organization… It’s very common for us to have one project team made up of folks from all of our regions

“No Borders” 2005, p. 37

While having remote teams usually brings down the cost considerably, it comes with its own set of everyday challenges that can outweigh the benefits if not properly handled.

Distributed teams are the subject of active research that questions the extent to which face-to-face and in-person communication is necessary for distributed teams to function effectively and why: empirical tests show that the answer may depend on which team processes and outcomes one is exploring and how distance is measured (Geographical? Cultural? Time zone?).

Essentially, the challenges of distributed teams fall in one of the following categories: degree of virtuality, degree of distribution, history of the team, degree of (im)permanence, degree of task complexity. Following are a few points that I found helpful in my experience with working with multinational multicultural (MNMC) distributed teams and that directly or indirectly address the aforementioned categories.

Listen, listen, listen. Then act

Communication in a co-located team happens as a result of people sharing the same room at the same time: a side effect of sitting together is feeling more comfortable in sharing ideas and raising issues.

Working from the same office means ignoring a whole set of issues around distributed communications that can bring productivity to a halt when working with people in different locations.

The key point in this scenario is to make everyone feel empowered to report problems that would otherwise affect everyone. One way of doing it is to show how serious we are in tackling those issues: listen carefully, then act effectively. Showing care builds trust.

If the microphone is not working during a meeting and it is being reported by the people on the call, stop and fix it, change it, or change room. Do not resume the discussion until the problem is fixed: losing input from a whole part of the team is much worse than stopping the meeting for a few minutes (or even moving it to a different time).

Choose your communication tools wisely

The first step in setting up to work within a distributed environment is to have the right tools in place.

It is vital to make it easy for people to communicate: you don't want to add any additional barrier to those already created by the distance.

Whether people sit in the same office or not, you need a tool to organise and track the work: Jira and Trello are the most widely used solutions nowadays, pick the one you and your team like the most, no big deals here. I love physical boards and sticky notes, but they are just not practical with distributed teams.

Slack, Teams, Skype are all valid chat/conference call tools that given a good internet connection, will do their job: it's just a matter of preference. Choose only one tool though, so the chances of discussions getting lost are minimised.

Make sure you invest in good headsets: I found Sennheiser PC 5 CHAT to be cheap and work perfectly for internet calls.

Buy the right hardware for your meeting rooms: if you work with Macs, I found Apple TV to be very helpful when it comes to sharing your screen/audio during a call. Another option may be to use Chromecast. Also related to setting up your rooms, having a conference speakerphone can really make a difference when many people are sat around a table and far from the laptop: Jabra Speak 410 proved to be effective for this in my experience. And don't forget a good 1080p webcam!

In my experience, I found that meetings with everyone in the same room sitting around a microphone are not as effective as meetings when everyone dials in from his/her desk with their headset on: you always end up having issues with people sitting too far from the table and not being heard. My suggestion is for everyone to dial in from their desk, regardless of how many people are involved in the call.

If your employees are not co-located, then treat every meeting as remote and strive for:

frequent communication: frequent, spontaneous communications mitigate the effect of distribution on both interpersonal and task conflict and are also linked to highest trust
face-to-face communication: perceived as critical early on in a team’s development and seen as a behaviour that will enhance MNMC team effectiveness (although as time goes on and team members become more familiar with each other, non-face-to-face communication don't seem to hinder team's dynamics)

Communicate early, communicate often

With distributed teams, it is important to learn the value of over-communicating: when decisions are made, they need to be communicated immediately to everyone, along with the reason behind the decision. It's important that everyone has a vision of what is going on in the organisation and the role they can play in making that vision become a reality.

The risk of teams around the globe working on outdated/wrong information is too high to delay the communication process: make sure everyone always have the latest updates and can adjust their job based on that.

Hire a developer advocate

A developer advocate is someone who makes other developers' lives easier: too often developers are busy shipping feature and can't spend time improving their development experience, that's when a developer advocate comes in.

They can:

automate tedious tasks
prepare "Getting started" guides for new hires
prepare guidelines for bug reports and troubleshooting how-tos
help with the definition of Done and Ready
structure code reviews
define coding standards and find tools to enforce them
improve the deployment process
the list goes on

All this with the aim of increasing productivity and improving the developers' lives (which leads to better retention, btw).

The above points become much more important with distributed teams: given that fast communication is not always possible, having tools and guides in place can make the difference between getting stuck for a day or being able to progress to the next task.

In general, embrace simplicity and automate whatever possible: the simpler your projects are and the easier it is to work with them, the more productive developers will be. You want to keep the cognitive load as low as possible: co-locate documentation with code, create standards for all teams to follow, enforce and document them and let everyone know, organise workshops and "sell" these concepts to everyone.

Clearly define and document roles

You can expect people from different teams to have never worked together before so it is important that everyone in every team know exactly the complete hierarchy with names, photos and ways of getting in touch. This way everyone will always know who to get in touch with depending on the issue they're having or the information they're seeking.

This diagram would also outline a clear escalation path if an issue arises.

Write everything down, always

This is a rule that everyone should follow, whatever the team nature, but it becomes vital when people are not co-located.

Important discussions don't (can't) always happen during conference calls, decisions are made during a quick lunch, ideas have the tendency to reveal themselves to us at the most peculiar times, but we need all the team to be involved and everyone to know: that is why comments in Jira/Trello are so important as they give everyone visibility over the work that's being done.

Use the comments, update stories/cards often and use your product management tool as a source of truth for everyone.

Enjoy the pleasures and pains of time zone differences

Multinational multicultural distributed teams present opportunities and challenges to organisations: having teams working in different time zones is usually seen as a problem because people have a hard time organising meetings where everyone can attend and issues are resolved slowly because of lack of quick communication.

Although this definitely represents a challenge, it can also represent an opportunity to prolong the work cycle and increase velocity. In such an environment, blockers can be passed to a fresh pair of eyes at the end of the day and possibly get resolved by next morning, something that would be impossible when following the same working hours.

Of course, it all comes at a cost, and teams situated in different time zones require more preparation.

To remove all possible issues and blockers, make sure you:

spend time during your day (and before their day start) to organise work and detail everything to limit the unknowns and make every team a self-sufficient unit
review code or designs as soon as possible
leave actionable feedback in the comments
ensure they can be as independent as possible during their day and always plan more work in advance so if anything comes up they can progress to another task without getting blocked
find the golden time when everyone is online and move stand up to that time. If the time difference is really relevant, you may only have a small window of time: use it to make everyone meet and have at least standup all together
structure your teams as if the whole team was remote: there are not first-class citizens working in a central location, everyone is a remote worker
Alternate time zones: if you need to have meetings at inconvenient times, make sure you make it "inconvenient" for a different team each month
have people from different teams having informal 1:1 once a week: this helps to build relationships and trust, making it easier in the future for everyone to communicate issues and blockers without fear. Make a rule to not cancel them because of a "more" important meeting

Respect and embrace cultural differences

Globally distributed teams will be effective vehicles for knowledge sharing in an organisation as long as individuals learn the cultural logic of others’ divergent beliefs. If not, culture is constructed as something which divides individuals.

Multinational and Multicultural Distributed Teams: A Review and Future Agenda

When working with people living in other parts of the world, there is so much more than a cold colleague-to-colleague relationship to be experienced: I am always impressed by the differences in the way of working and living that I get to experience whenever I work with a new team.

I always make it a priority to get to know and experience their culture as much as possible: be it food, architecture, history. Every country has something peculiar that can spark my interest and that enriches not only me as a person but gives me a common ground to create a better environment at work. Just by looking at specific traits of a country can reveal so much about the people I am working with and, needless to say, helps a lot with the daily work relationships.

Knowing people personalities, habits and needs will help you with the daily organisation of work in a way that can improve productivity and boost team morale: people that see their culture respected will inevitably be happier when working with you. This may mean adjusting your communication patterns to use/avoid words or phrases that may be offensive, moving meetings to avoid specific parts of their day.

If you're interested in finding out more, Managing Cultural Differences in Your Distributed Team is a good read.

Experience their culture in person whenever you can, aka invest in airfare

There is something unique in meeting someone in person and breaking that electronic barrier.

Interactions that happen when working in the same office are impossible to reproduce when teams are distributed, so you should try to get all your teams together as often as possible, not only to talk about work, but (mainly) to have fun and get to know each other: common experiences are the building block of trust and the return you get from it far outweighs the airfare to get everyone in the same place (well, maybe not for big companies).

The simple act of tapping someone on the shoulder releases oxytocin and improve a person's feelings (reduced stress, increased happiness, improved communication).

Make sure to budget for travel and you'll experience increased productivity from day one.

It's not all about work

Thanks to Hugo Raymond for the help on this paragraph.

Think about all the micro-interactions you have on a day-to-day basis that make where you work an enjoyable place to spend the best part of your day: how do you replicate these when working with distributed teams?

The first, obvious answer is to try and spend time together, in person, but this is seldom achievable for companies with multiple teams.

Another way, that can work every day and build lasting rapports is to use your communication tool (Slack, Teams, whatever) and create a safe place that everyone can access: create a "Fun" channel and let people create sub-channels with things that interest them. It could be a book club, where every week people from around the globe share the book they're reading, review previous ones and give suggestions to other people. It could be a photography channel where photos are shared and commented, the latest gears discussed, tips are given. There could be weekly or monthly assignments like "Still life" or "Autumn leaves" where people from around all the offices share their pics: a wonderful way to show the diversity and beauty of different countries.

To some this may seem like "organised fun" but you only need a few passionate champions for those who are interested in the social part, to engage, for it to then become a success.

If you read until here, may as well watch this!

Jilanna Wilson keeps the love light burning for a team that is spread across 5 continents and 8 time zones and shares some of her knowledge in this video from the DesignOps Summit 2019:

Good luck, and ❤️ your remote teams, they're good for you!

References

This article was originally published on onefiniteloop.io