React 18 sets the foundation for concurrent rendering APIs that future React features will be built on top of.

In this tutorial, I will give a quick guide of the features released in React 18, and explain a few major concepts such as concurrent rendering, automatic batching and transitions.

React 18 Feature Quick Guide

Now let's look at each of these updates in more detail. But first, if you haven't already, let's learn how to update React.

How to upgrade to React 18

Install React 18 and React DOM from npm or yarn, like this:

npm install react react-dom

Then, you'll want to use createRoot instead of render.

In your index.js, update ReactDOM.render to ReactDOM.createRoot to create a root, and render your app using root.

Here's what it would look like in React 17:

import ReactDOM from 'react-dom';
import App from 'App';

const container = document.getElementById('app');

ReactDOM.render(<App />, container);

And here's what it looks like in React 18:

import ReactDOM from 'react-dom';
import App from 'App';

const container = document.getElementById('app');

// create a root
const root = ReactDOM.createRoot(container);

//render app to root
root.render(<App />);

Concurrency in React 18

To understand concurrency, let’s consider this example by Dan Abramov from React 18 Working group discussions.

Let’s say that we need to call two people – Alice and Bob. In a non-concurrent setting, we can only have one call at a time. We would first call Alice, end the call, and then call Bob.

This is fine when calls are short, but if call with Alice has a long waiting period (such as on-hold), this can be a time sink.

Image showing that in a typical non-concurrent phone conversation, you have to wait for a call to be over before starting a new call.

In a concurrent setting, we could call Alice and, once we were put on hold, we could then call Bob.

This doesn’t mean that we are talking to two people at the same time. It just means that we can have two or more concurrent calls at the same time and decide which call is more important.

Image showing phone conversation between Alice and Bob can be concurrent, by placing a call on hold and answering a more urgent call with Bob first.

Similarly, in React 18 with concurrent rendering, React can interrupt, pause, resume, or abandon a render. This allows React to respond to the user interaction quickly even if it is in the middle of a heavy rendering task.

Before React 18, rendering was a single, uninterrupted, synchronous transaction and once rendering started, it couldn’t be interrupted.

Concurrency is a foundational update to React’s rendering mechanism. Concurrency allows React to interrupt rendering.

React 18 introduces the foundation of concurrent rendering and new features such as suspense, streaming server rendering, and transitions are powered by concurrent rendering.

New React 18 Features

Automatic Batching

React 18 features automatic batching. To understand batching, let’s consider the example of grocery shopping from the same React Working Group discussion.

Let’s say that you are making pasta for dinner. If you were to optimize your grocery trip, you would create a list of all the ingredients that you need to buy, make a trip to the grocery store, and get all your ingredients in one trip.

This is batching. Without batching, you would start cooking, find out you need an ingredient, go to the grocery store and buy the ingredient, come back and continue cooking, only to find out you need another ingredient, go to the grocery store...and drive yourself crazy.

In React, batching helps to reduce the number of re-renders that happen when a state changes, when you call setState. Previously, React batched state updates in event handlers, for example:

const handleClick = () => {
setCounter();
setActive();
setValue();
}

//re-rendered once at the end.

However, state updates that happened outside of event handlers were not batched. For example, if you had a promise or were making a network call, the state updates would not be batched. Like this:

fetch('/network').then( () => {
setCounter(); //re-rendered 1 times
setActive();  //re-rendered 2 times
setValue();   //re-rendered 3 times
});

//Total 3 re-renders

As you can tell, this is not performant. React 18 introduces automatic batching which allows all state updates – even within promises, setTimeouts, and event callbacks – to be batched. This significantly reduces the work that React has to do in the background. React will wait for a micro-task to finish before re-rendering.

Automatic batching is available out of the box in React, but if you want to opt-out you can use flushSync.

Transitions

Transitions can be used to mark UI updates that do not need urgent resources for updating.

For example, when typing in a typeahead field, there are two things happening: a blinking cursor that shows visual feedback of your content being typed, and a search functionality in the background that searches for the data that is typed.

Showing a visual feedback to the user is important and therefore urgent. Searching is not so urgent, and so can be marked as non-urgent.

These non-urgent updates are called transitions. By marking non-urgent UI updates as "transitions", React will know which updates to prioritize. This makes it easier to optimize rendering and get rid of stale rendering.

You can mark updates as non-urgent by using startTransition. Here is an example of what a typeahead component would like when marked with transitions:

import { startTransition } from 'react';

// Urgent: Show what was typed
setInputValue(input);

// Mark any non-urgent state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setSearchQuery(input);
});

How are transitions different from debouncing or setTimeout?

1. startTransition executes immediately, unlike setTimeout.
2. setTimeout has a guaranteed delay, whereas startTransition's delay depends on the speed of the device, and other urgent renders.
3. startTransition updates can be interrupted unlike setTimeout and won't freeze the page.
4. React can track the pending state for you when marked with startTransition.

Suspense on the server

React 18 introduces:

1. Code splitting on the server with suspense
2. Streaming rendering on the server

Client rendering vs server rendering

In a client-rendered app, you load the HTML of your page from the server along with all the JavaScript that is needed to run the page, and make it interactive.

If, however, your JavaScript bundle is huge, or you have a slow connection, this process can take a long time and the user will be waiting for the page to become interactive, or to see meaningful content.

In a client rendering flow, a user has to wait a long time before the page becomes interactive. Source: React Conf 2021 Streaming Server Rendering with Suspense by Shaundai Person

For optimizing the user experience and avoiding the user having to sit on a blank screen, we can use server rendering.

Server rendering is a technique where you render the HTML output of your React components on the server and send HTML from the server. This lets the user view some UI while JS bundles are loading and before the app becomes interactive.

For a detailed overview of client vs server rendering, check out Shaundai Person’s React Conf 2021 talk.

In a server rendering flow, we can display meaningful data to the user much faster by sending HTML from the server. Source: React Conf 2021 Streaming Server Rendering with Suspense by Shaundai Person

Server rendering further enhances the user experience of loading the page and reducing time to interactive.

Now what if most of your app is fast except for one part? Maybe this part loads data slowly, or maybe it needs to download a lot of JS before it gets interactive.

Before React 18, this part was often the bottleneck of the app, and would increase the time it took to render the component.

One slow component can slow down the entire page. This is because server rendering was all or nothing – you couldn’t tell React to defer loading of a slow component and couldn’t tell React to send HTML for other components.

React 18 adds support for Suspense on server. With the help of suspense, you can wrap a slow part of your app within the Suspense component, telling React to delay the loading of the slow component. This can also be used to specify a loading state that can be shown while it's loading.

In React 18, one slow component doesn’t have to slow the render of your entire app. With Suspense, you can tell React to send HTML for other components first along with the HTML for the placeholder, like a loading spinner. Then when the slow component is ready and has fetched its data, the server renderer will pop in its HTML in the same stream.

Image showing that suspense on the server can allow a slow component to show a loading state while others are fully rendered.

This way the user can see the skeleton of the page as early as possible and see it gradually reveal more content as more pieces of HTML Arrive.

All of this happens before any JS or React loads on the page, which significantly improves the user experience and user-perceived latency.

Strict mode

Strict mode in React 18 will simulate mounting, unmounting, and re-mounting the component with a previous state. This sets the ground for reusable state in the future where React can immediately mount a previous screen by remounting trees using the same component state before unmounting.

Strict mode will ensure components are resilient to effects being mounted and unmounted multiple times.

Conclusion

In a summary, React 18 sets the foundation for future releases and focusses on improving the user experience.

Upgrading to React 18 should be straightforward and your existing code should not break after the update. The upgrade process should not take more than an afternoon.

Give it a go and let me know what you think!

Sources:

1. React RFC
2. My previous React 18 post
3. React V18 blog
4. React Conf 2021 - React for App developers
5. React Conf 2021 - Streaming Server Rendering with Suspense

If you enjoyed this article, give it a ❤️ so others can find it too.

• For more frequent tips, stay in touch on Twitter
• Want articles like this directly in your inbox?

This article is an introduction to a new JS library called feature-u, that facilitates feature-based development in your React project.

Note_: On 8/14/2018 feature-u V1 was released, that re-designed Cross Feature Communication to include UI Composition as a core offering. This article covers the V1 release. The first article, based on feature-u V0, can be found here. We are very excited about this update because it promotes one solution for all feature collaboration!_

Most developers would agree that organizing your project by feature is much preferred over type-based patterns. Because application domains grow in the real world, project organization by type simply doesn’t scale, it just becomes unmanageable!

There are a number of good articles that discuss this topic with insight on feature-based design and structure (see: References below). However when it comes to the implementation, you are pretty much left to fend for yourself.

feature-u is a utility library that manages and streamlines this process. It automates the mundane details of managing features and helps to promote features that are truly plug-and-play.

This article provides a foundation of feature-u concepts and terminology, building insight into how you can promote individual plug-and-play features within your project. It makes the case for why feature-u was developed and gives you a better understanding of it’s benefits.

Check out the full docs, source, and npm package.

feature-u opens new doors into the exciting world of feature-based development. It frees you up to focus your attention on the “business end” of your features!

At a Glance

For your convenience, this Table of Contents (TOC) links directly to each section. Also note that each section title links back to the TOC.

Feature Based Development  Segregating Features  Feature Goals    Feature Runtime Consolidation    Feature CollaborationThe feature-u Solution  launchApp()  Feature Object  aspects  Running the App    App Initialization    Framework Configuration    Launching Your Application  Cross Feature Communication  Feature Based UI Composition    Resource Contracts  Feature EnablementIn SummaryBenefitsReferences

Please help me get the word out on feature-u. Your claps determine the distribution/promotion of this article. If you think feature-u has potential, please give this article multiple claps :-)

Feature Based Development

At a 30,000 ft view, feature-based development (as in most software) is all about dissecting hard problems into smaller pieces. Even when I started my career (back in the 70's), this was a prominent quote:

“All problems in computer science can be solved by another level of indirection.” David Wheeler

By breaking up your application into features, each feature can focus on a more specific and isolated set of tasks. In some ways you can think of a feature as a “mini application”!

There are many design considerations in defining your feature boundaries. You can find several articles on this topic that provide insight on feature-based design.

For the most part, these considerations are part of the design of each individual project. While feature-u does not dictate overall design considerations, it does facilitate good feature-based principles (such as encapsulation). This will be the focus of this article.

Segregating Features

If you are like me, when you think about feature-based development, the first thing that comes to mind is to isolate your code into feature directories.

In doing this your code is organized by what it accomplishes (i.e. features), rather than what it is (i.e. components, routes, logic, actions, reducers, selectors, etc.).

By segregating your features into individual directories, there is a semblance of isolation.

Feature Goals

Our goal is to encapsulate each feature in such a way as to make them truly plug-and-play. But how is this accomplished?

The directory structure is just a start. There are several hurdles that must be overcome to realize our goal …

• How do we encapsulate and isolate our features, while still allowing them to collaborate with one another?
• How can selected features introduce start-up initialization (even injecting utility at the root DOM), without relying on some external startup process?
• How can feature-based UI Composition be accomplished in an isolated and autonomous way?
• How do we configure our chosen frameworks now that our code is so spread out?
• How do we enable/disable selected features which are either optional, or require a license upgrade?

In short, how do we achieve a running application from these isolated features?

When you boil it all down, there are two overriding characteristics that must be accomplished to achieve our goals:

1. [**Feature Runtime Consolidation**](#c8d1): pulling our features back together into one running application
2. [**Feature Collaboration**](#abbc): provide a mechanism by which our features can interact with one another

As it turns out, everything else is a byproduct of these two artifacts. Let’s take a closer look at each of these items.

Feature Runtime Consolidation

Now that we have isolated our features into separate entities, how do we bring them back together so they run as one application? We must be able to pull and configure various aspects of our individual features, and “launch” them as a single homogeneous running application.

This concern can be further divided into two sub-concerns:

• [App Initialization](#d44a)
  Some features may require certain startup initialization. As an example, a feature that encapsulates some DB abstraction will rely on a run-time setup of a DB service.
  Certainly we don’t want to rely on some global app logic to accomplish this (once again, we want our features to be encapsulated and self-sufficient).
• [Framework Configuration](#c339)
  If your application relies on other frameworks, chances are there are resources contained within each feature that must be accumulated and fed into the framework configuration process.
  How is this accomplished?

Feature Collaboration

The second characteristic (mentioned above) is Feature Collaboration — providing a mechanism by which our features can interact with one another.

A best practice of feature-based development (to the extent possible) is to treat each feature as an isolated implementation. Most aspects of a feature are internal to that feature’s implementation (for example, actions are typically created and consumed exclusively by logic/reducers/components that are internal to that feature).

From this perspective, you can think of each feature as its own isolated mini application.

With that said, however, we know that “no man is an island”! Any given feature ultimately exists as part of a larger application. There are cases where a feature needs to promote a limited subset of its aspects to other features. For example, a feature may need to:

• be knowledgeable of some external state (via a selector)
• emit or monitor actions of other features
• consolidate component resources from other features — as in UI Composition
• invoke the API of other features
• etc. etc. etc.

These items form the basis of why [**Cross Feature Communication**](#5369) and [**Feature Based UI Composition**](#a480) are needed.

To complicate matters, as a general rule, JS imports should NOT cross feature boundaries. The reason being that this cross-communication should be limited to public access points — helping to facilitate true plug-and-play.

Given all this then, how is Cross Feature Communication achieved in a way that doesn’t break encapsulation?

Features need a way to promote their Public Interface to other features, and consume other feature’s Public Assets.

The feature-u Solution

Let’s take a look at the solution feature-u provides for all of these goals. The following sections will build feature-u concepts incrementally.

launchApp()

[launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp) is an essential utility in feature-u. It is an agent, working on your behalf, which provides the foundation that accomplishes all the goals of feature-u! It facilitates both [**Feature Runtime Consolidation**](#c8d1) and [**Feature Collaboration**](#abbc).

With this utility, your mainline startup process is extremely simple … it merely invokes [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp), and you are done!

The [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp) function actually starts your application running, employing various hooks that drive BOTH App Initialization and Framework Configuration!

You can find [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp) examples in the [Usage](https://feature-u.js.org/1.0.1/usage.html#launchapp) section, and [Launching Your Application](https://feature-u.js.org/1.0.1/detail.html#launching-your-application).

How does this work? What are the bindings to [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp)? ... let's delve a bit deeper…

Feature Object

To accomplish this, each feature promotes a [Feature](https://feature-u.js.org/1.0.1/api.html#Feature) object (using [createFeature()](https://feature-u.js.org/1.0.1/api.html#createFeature)), that catalogs aspects of interest to feature-u.

This is the primary input to [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp).

aspects

In feature-u, “aspect” (little “a”) is a generalized term used to refer to the various ingredients that (when combined) constitute your application. Aspects can take on many different forms: UI Components • Routes • State Management(actions, reducers, selectors) • Business Logic • Startup Initialization Code • etc. etc. etc.

Not all aspects are of interest to feature-u … only those that are needed to setup and launch the application … all others are considered an internal implementation detail of the feature. As an example, consider the Redux state manager: while it uses actions, reducers, and selectors … only reducers are needed to setup and configure Redux.

The [Feature](https://feature-u.js.org/1.0.1/api.html#Feature) object is merely a lightweight container that holds aspects of interest to feature-u. These aspects can either be [Built-In aspects](https://feature-u.js.org/1.0.1/detail.html#built-in-aspects) (from core feature-u), or [Extendable aspects](https://feature-u.js.org/1.0.1/detail.html#extendable-aspects) (from plugin extensions).

Running the App

Let’s see how [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp) accommodates the two sub-goals of running the app:

• [App Initialization](#d44a)
• [Framework Configuration](#c339)

App Initialization

Because [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp) is in control of starting the app, it can introduce [Application Life Cycle Hooks](https://feature-u.js.org/1.0.1/appLifeCycle.html).

This allows each feature to perform app-specific initialization, and even inject components into the root of the app.

There are two hooks:

1. [Feature.appWillStart()](https://feature-u.js.org/1.0.1/appLifeCycle.html#appwillstart) - invoked one time at app startup time
2. [Feature.appDidStart()](https://feature-u.js.org/1.0.1/appLifeCycle.html#appdidstart) - invoked one time immediately after app has started

[Application Life Cycle Hooks](https://feature-u.js.org/1.0.1/appLifeCycle.html) greatly simplify your app's mainline startup process, because initialization specific to a given feature can be encapsulated in that feature.

Framework Configuration

A fundamental goal of feature-u is to automatically configure the framework(s) used in your run-time-stack (by accumulating the necessary resources across all your features). This greatly reduces the boilerplate code within your app.

How can this be accomplished when there are so many frameworks out there … and every project uses a different mix?

feature-u is extendable! It operates in an open plugable architecture where Extendable Aspects integrate feature-u to other frameworks, matching your specific run-time stack. This is good, because not everyone uses the same frameworks!

Extendable Aspects can be found in external NPM packages (the normal case), or you can create your own using [createAspect()](https://feature-u.js.org/1.0.1/api.html#createAspect) (a more advanced topic).

The [Aspect](https://feature-u.js.org/1.0.1/api.html#Aspect) object contains a series of [Aspect Life Cycle Hooks](https://feature-u.js.org/1.0.1/extending.html#aspect-life-cycle-methods) that are invoked under the control of feature-u([launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp)). In general, an Aspect's responsibility is to:

• accumulate [AspectContent](https://feature-u.js.org/1.0.1/api.html#AspectContent) across all features
• perform some desired setup and configuration
• expose it’s functionality in some way (typically a framework integration)

An [Aspect](https://feature-u.js.org/1.0.1/api.html#Aspect) automatically extends the [Feature](https://feature-u.js.org/1.0.1/api.html#Feature) object by allowing it's [AspectContent](https://feature-u.js.org/1.0.1/api.html#AspectContent) to be "cataloged" in the Feature using Aspect.name as it's key. In the diagram above, you can see that

• the reducerAspect (Aspect.name: 'reducer') permits a Feature.reducer: reducerContent construct
• and the logicAspect (Aspect.name: 'logic') permits a Feature.logic: logicContent construct

It is important to understand that the interface to your chosen frameworks is not altered in any way. You use them the same way you always have (just within your feature boundary). feature-u merely provides a well-defined organizational layer, where the frameworks are automatically setup and configured by accumulating the necessary resources across all your features.

Launching Your Application

In feature-u, the application mainline is very simple and generic. There is no real app-specific code in it … not even any global initialization! That is because each feature can inject their own app-specific constructs!! The mainline merely accumulates the [Aspects](https://feature-u.js.org/1.0.1/api.html#Aspect) and [Features](https://feature-u.js.org/1.0.1/api.html#Feature), and starts the app by invoking [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp):

Here are some important points of interest (match the numbers to *n* in the code above):

1. the supplied [Aspects](https://feature-u.js.org/1.0.1/api.html#Aspect) (pulled from separate npm packages) reflect the frameworks of our run-time stack (in our example [redux](http://redux.js.org/), [redux-logic](https://github.com/jeffbski/redux-logic), and [feature-router](https://github.com/KevinAst/feature-router)) and extend the acceptable Feature properties (Feature.reducer, Feature.logic, and Feature.route respectively) ... see: [Extendable aspects](https://feature-u.js.org/1.0.1/detail.html#extendable-aspects)
2. all of our app features are supplied (accumulated from the features/ directory)
3. a [registerRootAppElm()](https://feature-u.js.org/1.0.1/api.html#registerRootAppElmCB) callback is used to catalog the supplied rootAppElm to the specific React platform in use. Because this registration is accomplished by your app-specific code, feature-u can operate in any of the React platforms, such as: [react-web](https://reactjs.org/), [react-native](https://facebook.github.io/react-native/), and [expo](https://expo.io/) ... see: [React Registration](https://feature-u.js.org/1.0.1/detail.html#react-registration)
4. as a bit of a preview, the return value of [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp) is a [Fassets object](https://feature-u.js.org/1.0.1/api.html#Fassets), which promotes the accumulated Public Face of all features, and is exported to provide [Cross Feature Communication](https://feature-u.js.org/1.0.1/crossCommunication.html).

Cross Feature Communication

In support of Feature Collaboration that doesn’t break encapsulation, feature-u promotes feature-based resources through something called fassets (feature assets). This is how all Cross Feature Communication is accomplished. You can think of this as the Public Face of a feature.

SideBar: The term fassets is a play on words. While it is pronounced "facet" and is loosely related to this term, it is spelled fassets (i.e. feature assets).

A feature can expose whatever it deems necessary through the built-in [Feature.fassets aspect](https://feature-u.js.org/1.0.1/api.html#fassets)). There is no real constraint on this resource. It is truly open.

The [fassets aspect](https://feature-u.js.org/1.0.1/api.html#fassets) has a define directive where resources are cataloged.

Here is a simple example of how fassets are defined:

feature-u accumulates fassets from all active features, and promotes them through the [Fassets object](https://feature-u.js.org/1.0.1/api.html#Fassets) (emitted from [launchApp()](https://feature-u.js.org/1.0.1/api.html#launchApp)).

SideBar: There are several ways to obtain access the Fassets object (see [Obtaining fassets object](https://feature-u.js.org/1.0.1/crossCommunication.html#obtaining-fassets-object)).

To reference a fassets resource, simply dereference it as any other object reference. There is also a [Fassets.get()](https://feature-u.js.org/1.0.1/api.html#Fassets_get)method that can be supplied [Wildcards](https://feature-u.js.org/1.0.1/crossCommunication.html#wildcards-adding-dynamics), returning an array of resources.

This is an example of a push philosophy. Here the supplier is is simply publicly promoting a resource for other features to use (take it or leave it). The supplier is merely saying: “this is my Public Face”.

You can find more information about this topic in [Cross Feature Communication](https://feature-u.js.org/1.0.1/crossCommunication.html).

Feature Based UI Composition

It is common for a UI component to be an accumulation of sub-components that span several features. As a result, UI Composition is a very important part of Cross Feature Communication.

In support of this, feature-u introduces the [withFassets()](https://feature-u.js.org/1.0.1/api.html#withFassets) Higher-order Component (HoC) that auto-wires fasset properties into a component. This is a common pattern popularized by Redux connect() (simplifying component access to application state).

Here is how a component would access a company.logo (defined by another feature):

The [withFassets()](https://feature-u.js.org/1.0.1/api.html#withFassets) HoC auto-wires named feature assets as component properties through the [mapFassetsToPropsStruct](https://feature-u.js.org/1.0.1/api.html#mapFassetsToPropsStruct) hook. In this example, because the Logo property is a component, MyComponent can simply reference it using JSX.

You can find more information about this topic in [UI Composition](https://feature-u.js.org/1.0.1/crossCommunication.html#ui-composition).

Resource Contracts

It is common for UI Composition to be represented as a contract, where a component in one feature has a series of injection needs that are to be supplied by other features.

The [fassets aspect](https://feature-u.js.org/1.0.1/api.html#fassets) has additional constructs to facilitate this contractual arrangement, allowing feature-u to provide more validation in the process.

Rather than just defining resources in one feature and using them in another:

• A given feature can specify a series of injection needs using the fassets.use directive. This identifies a set of injection keys that uniquely identify these resources.
• Other features will supply this content using the fassets.defineUse directive, by referencing these same injection keys.

This represents more of a pull philosophy. It gives feature-u more knowledge of the process, allowing it to verify that supplied resources are correct.

Wildcards (*) can be used to add additional dynamics to the process, allowing features to inject their content autonomously.

Here is a main feature that is pulling in a series of sub-components (links and bodies) from other features:

main feature:

Because our specification includes wildcards, a series of definitions will match!

Here is the MainPage component that fulfills the usage contract:

When [withFassets()](https://feature-u.js.org/1.0.1/api.html#withFassets) encounters wildcards (*), it merely accumulates all matching definitions, and promotes them as arrays.

Through this implementation, any feature may dynamically inject itself in the process autonomously! In addition, this dynamic implicitly handles the case where a feature is dynamically disabled (very kool indeed)!!

The following snippets are taken from other features that supply the definitions for the content to inject:

cart feature

search feature

Two external features (cart and search) define the content that is requested by the main feature.

The fassets.defineUse directive requires that the resource keys match a fassets.use feature request. This is the contract that provides feature-u insight when enforcing it's validation.

SideBar: Because we are also dealing with navigation, we introduce [react-router](https://reacttraining.com/react-router/) into the mix (with the Link and Route components). Because of RR's V4 design, our routes are also handled through component composition (see [Feature Based Routes](https://feature-u.js.org/1.0.1/featureRouter.html) for more information).

You can find more information about this topic in [UI Composition](https://feature-u.js.org/1.0.1/crossCommunication.html#ui-composition).

Feature Enablement

Features can be dynamically disabled by setting the Feature.enabled boolean property (part of the [Built-In aspects](https://feature-u.js.org/1.0.1/detail.html#built-in-aspects)):

In this example, it is just as though the sandbox feature doesn't exist. In other words it has been logically removed.

Typically, this indicator is based on some run-time expression, allowing packaged code to be dynamically enabled/disabled during the application’s start-up process:

This dynamic is useful in a number of different situations. For example:

• some features may require a license upgrade
• other features may only be used for diagnostic purposes, and are disabled by default

You can find more information about this topic in [Feature Enablement](https://feature-u.js.org/1.0.1/enablement.html).

In Summary

The following diagram summarizes feature-u’s Basic Concepts (as discussed above):

Benefits

There are many benefits in using feature-u!

The two fundamental artifacts from which most benefits are derived are:

• A formal means by which features can collaborate with one another ([Cross Feature Communication](http://localhost:4000/crossCommunication.html)), making them truly plug-and-play
  This includes the ability for [UI Composition](http://localhost:4000/crossCommunication.html#ui-composition) to cross feature boundaries. It even allows UI Content to be injected autonomously. This is something that has to be seen ... it shows off feature-u very well.
• A significant reduction in boilerplate code through:
  Auto configuration of the frameworks in-use (via plugin extensions — [Extendable aspects](http://localhost:4000/detail.html#extendable-aspects))
  Startup initialization that is encapsulated within features (via [Application Life Cycle Hooks](http://localhost:4000/appLifeCycle.html))

The following list of benefits can be directly correlated to the considerations that formed the basis of why feature-u was developed (see: [Why feature-u?](http://localhost:4000/why.html)).

1. Feature Encapsulation: isolating feature boundaries improves code manageability
2. Feature Collaboration: promote Cross Feature Communication through a well-defined feature-based Public Interface
3. Feature Based UI Composition: facilitate seamless cross-feature component composition
4. Application Life Cycle Hooks: features can initialize themselves without relying on an external process
5. Feature Enablement: enable/disable features through a run-time switch
6. Minimize Feature Order Dependency Issues during in-line code expansion
7. Framework Integration: automatically configure used framework(s) (matching the app’s run-time-stack) by accumulating all feature aspects (employing an extendable API)
8. UI Component Promotion: features can autonomously promote their UI components through Feature Based Route Management
9. Single Source of Truth: is facilitated in a number of ways within a feature’s implementation
10. Simplified App Startup: launching an app can be accomplished through a single line of executable code!
11. Operates in any React Platform React Web, React Native, Expo, etc.
12. Plug-and-Play: features can be more easily added or removed

feature-u allows you to focus your attention on the “business end” of your features!

Go forth and compute!!

References

• A feature based approach to React development … Ryan Lanciaux
• How to better organize your React applications? … Alexis Mangin
• How to use Redux on highly scalable javascript applications? … Alexis Mangin
• The 100% correct way to structure a React app (or why there’s no such thing) … David Gilbertson
• Redux for state management in large web apps … David Clark

This article is an introduction to feature-u — a library that facilitates feature-based project organization in your react project. This utility assists in organizing your project by individual features.

Most developers would agree that organizing your project by features is much preferred over type-based patterns. Because application domains grow in the real world, project organization by type simply doesn’t scale, it just becomes unmanageable!

There are many good articles on this topic with insights on feature-based design and structure (see: References below).

This article outlines my excursion into feature-based composition. In working through the details, I realized there was an opportunity for a library to help manage and streamline some of the hurdles incurred in this process. The result: feature-u (check out the full docs, GitHub source, and NPM package).

Update: On 8/14/2018 feature-u V1 was released, that re-designed Cross Feature Communication new to include UI Composition new as a core offering. A new article can be found here that takes a comprehensive approach in introducing you to all of feature-u (including V1). We are very excited about this update, because it promotes one solution for all feature collaboration! While upgrading to V1 requires some client code mods (see V1 Migration Notes), it is well worth it. This article is based on feature-u V0, and is using some antiquated APIs (mostly Feature.publicFace, and the app object). Still, this is a good resource to get your feet wet with feature-u.

At a Glance

Backdrop — why feature-u was created

feature-u Basics — introduce high-level feature-u concepts

eatery-nod App — the sample app used to demonstrate feature-u

Before & After — eatery-nod project structure before and after features

feature-u In Action — explore feature-u aspects through concrete examples

feature-u Benefits — in summary

References — feature-based articles

Backdrop

Let’s start by chronicling my journey in this process

out of the Starting Gate …

Sooo … I had decided to restructure my project by features. From a design perspective, there were a number of considerations in determining the feature boundaries. I had read all the articles, and applied my design to a new feature-based directory structure.

In general, I was feeling good about my progress. I was starting to see concrete benefits … feature segregation was going to result in code that is much more manageable!

the Hurdles …

However, there were a number of hurdles yet to be resolved …

How can I encapsulate and isolate my features, while still allowing them to collaborate with one another?

How can selected features introduce start-up initialization (even injecting utility at the root DOM), without relying on some external startup process?

How can I promote feature-based UI components in an isolated and autonomous way?

How can I configure my chosen frameworks now that my code is so spread out?

How can I enable/disable selected features which are either optional, or require a license upgrade?

In short, how can I pull it all together so that my individual features operate as one application?

the Goal (what now?)

The overriding goal of feature-u is two-fold:

1. Allow features to Plug-and-Play! This encompasses many things, such as: encapsulation, cross communication, enablement, initialization, and so on. We will build on these concepts throughout this article.
2. Automate the startup of your application!! You have the features. Allow them to promote their characteristics, so a central utility can automatically configure the frameworks used in your app, thereby launching your application. This task must be accomplished in an extendable way, because not everyone uses the same set of frameworks.

feature-u Basics

The basic process of feature-u is that each feature promotes a Feature object that contains various aspects of that feature — things like the feature's name, its Public API, whether it is enabled, initialization constructs, and resources used to configure its slice of the frameworks in use.

In turn, these Feature objects are supplied to launchApp(), which configures and starts your application running. In addition, the returned App object is exported, in order to promote the public API of each feature.

aspects

In feature-u, “aspect” is a generalized term used to refer to the various ingredients that (when combined) constitute your application.

Aspects can take on many different forms:

• UI Components and Routes
• State Management (actions, reducers, selectors)
• Business Logic
• Startup Initialization Code
• And so on…

Not all aspects are of interest to feature-u — only those that are needed to setup and launch the app — all others are considered an internal implementation detail of the feature.

As an example, consider the redux state manager. While it uses actions, reducers, and selectors … only reducers are needed to setup and configure redux.

framework integration

A fundamental goal of feature-u is to automatically configure the framework(s) used in your run-time-stack (by accumulating the necessary resources across all your features). Because not everyone uses the same frameworks, feature-u accomplishes this through Extendable Aspects (you can find them in external NPM packages, or you can create your own).

It is important to understand that the interface to your chosen frameworks is not altered in any way. You use them the same way you always have (just within your feature boundary).

feature-u merely provides a well defined organizational layer, where the frameworks are automatically setup and configured by accumulating the necessary resources across all your features.

eatery-nod App

eatery-nod is the application where feature-u was conceived. It is a react-native expo mobile app, and is one of my sandbox applications that I use to test frameworks. I like to develop apps that I can use, but have enough real-world requirements to make it interesting.

eatery-nod randomly selects a “date night” restaurant from a pool of favorites. My wife and I have a steady “date night”, and we are always indecisive on which of our favorite restaurants to frequent :-) So eatery-nod provides the spinning wheel!

Take a look at the eatery-nod README to get a feel for the application. Screen flows are available, so it really helps in your orientation to the project.

eatery-nod’s primary screen flow

In addition, README files are found in each feature, describing what each feature accomplishes. Take some time now and skim through these resources:

• device — initializes the device for use by the app, and promotes a device API abstraction
• auth — promotes complete user authentication
• leftNav — promotes the app-specific Drawer/SideBar on the app’s left side
• currentView — maintains the currentView with get/set cross-feature communication bindings
• eateries — manages and promotes the eateries view
• discovery — manages and promotes the discovery view
• firebase — initializes the Google Firebase service
• logActions — logs all dispatched actions and resulting state
• sandbox — promotes a variety of interactive tests, used in development, that can easily be disabled

Before & After

Anyone who knows me will tell you that I have an appreciation for a good before/after analysis. Whether it is a home remodel or a software refactor, it helps to chronicle where you have been, so as to quantify concrete achievements, and gives you a sense of accomplishment.

Let’s take a look at eatery-nod’s directory structure (before/after).

For illustration purposes, I have only expanded a few directories, but I think you get the idea.

Before: here is my project's before features …

eatery-nod src BEFORE featuressrc/├──actions/        ... redux actions│     auth.js│     discovery.js│     eateries.js│     ... snip snip├──api/            ... various abstract APIs│     device.js│     discovery.js│     ... snip snip├──app/            ... mainline startup **1**│  │  ScreenRouter.js│  │  SideBar.js│  │  index.js│  └──startup/│     │  createAppStore.js│     │  platformSetup.android.js│     │  platformSetup.ios.js│     └──firebase/│           firebaseAppConfig.js│           initFireBase.js├──appState/       ... redux reducers│     auth.js│     discovery.js│     eateries.js│     ... snip snip├──comp/           ... UI Component Screens│     DiscoveryListScreen.js│     EateriesListScreen.js│     ... snip snip├──logic/          ... redux-logic modules│     auth.js│     discovery.js│     eateries.js│     ... snip snip└──util/           ... common utilities

After: and here is the same project's after features …

eatery-nod src AFTER featuressrc/│  app.js          ... launches app via launchApp() **2**├──feature/│  │  index.js     ... accumulate/promote all app Feature objects│  ├──auth/        ... the app's authorization feature│  │  │  actions.js│  │  │  featureName.js│  │  │  index.js│  │  │  logic.js│  │  │  publicFace.js│  │  │  route.js│  │  │  signInFormMeta.js│  │  │  state.js│  │  └──comp/│  │        SignInScreen.js│  │        SignInVerifyScreen.js│  ├──currentView/ ... other features│  ├──device/      ... feature to initialize the device│  │  │  actions.js│  │  │  api.js│  │  │  appDidStart.js│  │  │  appWillStart.js│  │  │  featureName.js│  │  │  index.js│  │  │  logic.js│  │  │  publicFace.js│  │  │  route.js│  │  │  state.js│  │  └──init/│  │        platformSetup.android.js│  │        platformSetup.ios.js│  ├──discovery/   ... more features│  ├──eateries/│  ├──firebase/│  ├──leftNav/│  ├──logActions/│  └──sandbox/└──util/           ... common utilities used across all features

As expected, the difference in project organization is dramatic!

• Before features — you find constructs for a given feature spread over numerous typed directories.
• After features: all aspects of a given feature are contained in its own isolated directory.
• A notable difference is the dramatic reduction in complexity of the application startup process! The “before features” contained an entire app\ directory of startup code (see [**1**](#226c) above), while the "after features" simply contains a single app.js startup file (see [**2**](#f98f) above). Where did all the complexity go? ... stay tuned!

feature-u In Action

To better understand feature-u, let’s take a closer look at some eatery-nod examples in action.

Each of the following sections briefly introduce a new feature-u topic, correlating sample code from eatery-nod. Additional information is provided through links, both to the feature-u docs, and eatery-nod source code. In some cases the in-lined sample code has been streamlined (to emphasize a focal point), however the caption link will take you to the actual code (hosted on GitHub).

Here are our topics …

1. Simplified App Startup
2. React Platforms
3. Feature Object
4. Feature Initialization
5. Feature Collaboration
6. Framework Integration
7. Feature Enablement
8. Managed Code Expansion
9. UI Component Promotion
10. Single Source of Truth

1. Simplified App Startup

After breaking your application up into pieces (as with features), how do you pull them all back together, and actually start your app running? At first glance, this may seem like a daunting task. As it turns out, however, because of the structure promoted by feature-u, it actually is a very simple process.

To solve this, feature-u provides the [launchApp()](https://feature-u.js.org/0.1.3/api.html#launchApp) function (see: Launching Your Application).

Here is eatery-nod’s mainline …

The first thing to note is just how simple and generic the mainline startup process is. There is no real app-specific code in it … not even any global initialization!

That is because feature-u provides various hooks that allow your features to inject their own app-specific constructs.

The mainline merely accumulates the Aspects and Features, and starts the app by invoking launchApp().

Here are some important points of interest (match the numbers to *n* in the code above):

1. ([*1*](#a002)) the supplied Aspects (pulled from separate NPM packages) reflect the frameworks of our run-time stack (in our example [redux](http://redux.js.org/), [redux-logic](https://github.com/jeffbski/redux-logic), and [feature-router](https://github.com/KevinAst/feature-router)) and extend the acceptable Feature properties — Feature.reducer, Feature.logic, and Feature.route respectively. (See Extendable aspects).
2. ([*2*](#a002))all app features are accumulated from our feature/ directory
3. ([*3*](#a002))as a preview to Feature Collaboration, the exported return value of launchApp() is an App object, which promotes the accumulated Public API of all features.

2. React Platforms

In the example above (see [*4*](#a002)), you see that launchApp() uses a [registerRootAppElm()](https://feature-u.js.org/0.1.3/api.html#registerRootAppElmCB) callback hook to register the supplied rootAppElm to the specific React platform in use. Because this registration is accomplished by app-specific code, feature-u can operate in any of the React platforms (see React Registration).

Here are some [registerRootAppElm()](https://feature-u.js.org/0.1.3/api.html#registerRootAppElmCB) variations:

react web:

react-native:

expo:

3. Feature Object

Each feature is located in its own directory, and promotes aspect content through a Feature object (using [createFeature()](https://feature-u.js.org/0.1.3/api.html#createFeature)).

Here is an example from eatery-nod’s device feature.

As you can see, the Feature object is merely a container that holds aspect content of interest to feature-u. The sole purpose of the Feature object is to communicate this aspect information to launchApp().

We will fill in more detail a bit later, but for now notice that the feature is conveying reducers, logic modules, routes, and does some type of initialization (appWillStart/appDidStart). It also promotes a publicFace that can be used by other features (such as the feature’s Public API).

For more information, please refer to Feature & aspect content.

4. Feature Initialization

Any given feature should not have to rely on an external startup process to perform the initialization that it needs. Rather, the feature should be able to spawn initialization that it depends on.

This could be any number of things, such as:

• initialize some service API
• inject a utility react component at the App root
• dispatch an action that kicks off a startup process
• And more...

To solve this, feature-u introduces two Application Life Cycle Hooks, injected through the following Feature aspects:

1. [Feature.appWillStart({app, curRootAppElm}): rootAppElm || falsy](https://feature-u.js.org/0.1.3/appLifeCycle.html#appwillstart) Invoked one time, just before the app starts up. This can do any type of initialization, including supplementing the app's top-level root element (such as the React component instance).
2. [Feature.appDidStart({app, appState, dispatch}): void](https://feature-u.js.org/0.1.3/appLifeCycle.html#appDidStart)
   Invoked one time immediately after the app has started. A typical usage for this hook is to dispatch some type of bootstrap action.

Here are some examples from eatery-nod:

FireBase Initialization:

Bootstrap Action:

Inject DOM Root Elm:

5. Feature Collaboration

Even though a feature’s implementation is encapsulated, it still needs to interact with its surroundings. To complicate matters, one feature should never import resources from another feature, because it should strive to be plug-and-play. As a result, we need a well-defined feature-based Public API.

To solve this, feature-u promotes a Cross Feature Communication. This is accomplished through the Feature.publicFaceBuilt-In aspect property. A feature can expose whatever it deems necessary through its publicFace. There are no real constraints on this resource. It is truly open.

Typically this involves promoting selected:

• actions
• selectors
• APIs
• And so on

The publicFace of all features are accumulated and exposed through the App object (emitted from launchApp()).

It contains named feature nodes, as follows:

App.{featureName}.{publicFace}

Here is an example from eatery-nod’s auth feature.

Out of all the items found in the auth feature, only two actions and one selector are public.

Here is what the App object would look like for this example:

app: {  auth: {    actions: {      userProfileChanged(userProfile),      signOut(),    },    sel: {      getUserPool(appState),    },  },  currentView: {   // other features    ... snip snip  },}

As a result, the auth feature's public API can be accessed as follows:

app.auth.actions.userProfileChanged(userProfile)app.auth.actions.signOut()app.auth.sel.getUserPool(appState)

6. Framework Integration

Most likely your application employs one or more frameworks (such as redux or [redux-logic](https://github.com/jeffbski/redux-logic)). How are the resources needed by these frameworks accumulated and configured across the many features of your app?

To solve this, feature-u introduces Extendable aspects. feature-u is extendable. It provides integration points between your features and your chosen frameworks.

Extendable Aspects are packaged separately from feature-u, so as to not introduce unwanted dependencies (because not everyone uses the same frameworks). You pick and choose them based on the framework(s) used in your project (matching your project’s run-time stack). They are created with feature-u’s extendable API, using createAspect(). You can define your own Aspect, if the one you need doesn't already exist.

Let’s take a look at a redux example from eatery-nod.

The device feature maintains its own slice of the state tree.

It promotes its reducer through the Feature.reducer aspect:

Because Feature.reducer is an extended aspect (verses a built-in aspect), it is only available because we registered the feature-redux reducerAspect to launchApp() (please refer to Simplified App Startup above).

The key thing to understand is that feature-u (through the feature-redux extension) will automatically configure redux by accumulating all feature reducers into one overall appState.

Here is the reducer code …

A feature-based reducer is simply a normal reducer that manages the feature’s slice of the the overall appState. The only difference is it must be embellished with [slicedReducer()](https://github.com/KevinAst/feature-redux#slicedreducer), which provides instructions on where to insert it in the overall top-level appState.

As a result, the device reducer only maintains the state relevant to the device feature (like its little slice of the world) — a status, a fontsLoaded indicator, and the device location.

SideBar: We are using the astx-redux-util utility’s [reducerHash()](https://astx-redux-util.js.org/1.0.0/api.html#reducerHash) function to concisely implement the feature's reducer (providing an alternative to the common switch statement). I have found that in using a utility like this, for most cases it is feasible to implement all the reducers of a feature in one file (due in part to the smaller boundary of a feature). astx-redux-util also promotes other Higher-Order Reducers. You may want to check this out.

7. Feature Enablement

Some of your features may need to be dynamically enabled or disabled. As an example, certain features may only be enabled with a license upgrade, or other features may only be used for diagnostic purposes.

To solve this, feature-u introduces Feature Enablement. Using the Feature.enabled Built-In aspect (a boolean property), you can enable or disable your feature.

Here is an example from eatery-nod’s sandbox feature:

The sandbox feature promotes a variety of interactive tests, used in development, that can easily be disabled.

Typically this indicator is based on a dynamic expression, but in this case it is simply hard-coded (to be set by a developer).

SideBar: When other features interact with a feature that can be disabled, you can use the App object to determine if a feature is present or not (see: Feature Enablement for more information).

8. Managed Code Expansion

In general, accessing imported resources during in-line code expansion can be problematic, due to the order in which these resources are expanded. The feature-u App object is such a critical resource (because it promotes the Public API of all features), it must be available even during code expansion. In other words, we cannot rely on an "imported app" being resolved during code expansion time.

To solve this, feature-u introduces Managed Code Expansion.

When aspect content definitions require the App object at code expansion time, you simply wrap the definition in a [managedExpansion()](https://feature-u.js.org/0.1.3/api.html#managedExpansion) function. In other words, your aspect content can either be the actual content itself (such as a reducer), or a function that returns the content.

When this is done, feature-u will expand it by invoking it in a controlled way, passing the fully resolved App object as a parameter.

Here is a logic module from eatery-nod’s auth feature:

You can see that the auth feature is using an action from the device feature, requiring access to the app object (see [*2*](#8030)). Because the app object is needed during code expansion, we use the managedExpansion() function (see [*1*](#8030)), allowing feature-u to expand it in a controlled way, passing the fully resolved app object as a parameter.

9. UI Component Promotion

Features that maintain their own UI Components need a way to promote them in the overall app’s GUI. Because features are encapsulated, how is this accomplished in an autonomous way?

To address this, feature-u recommends considering Feature Based Routes via the feature-router extendable Aspect (packaged separately). This approach can even be used in conjunction with other navigational solutions.

Feature Routes are based on a very simple concept: allow the application state to drive the routes! It operates through a series of feature-based routing functions that reason about the appState, and either return a rendered component, or null to allow downstream routes the same opportunity.

Here is a simple example from the device feature.

This route analyzes the current appState, and displays a SplashScreen until the system is ready:

In feature based routing, you will not find the typical “route path to component” mapping catalog, where (for example) some pseudo route('device') directive causes the Device screen to display, which in turn causes the system to accommodate the request by adjusting its state appropriately.

Rather, the appState is analyzed, and if the device is NOT ready, no other screens are given the option to even render ... Easy Peasy!

Depending on your perspective, this approach can be more natural, but more importantly, it allows features to promote their own screens in an encapsulated and autonomous way.

10. Single Source of Truth

Feature implementations (like all coding constructs) should strive to follow the single-source-of-truth principle. In doing this, a single line modification can propagate to many areas of your implementation.

What are some Best Practices for single-source-of-truth as it relates to features, and how can feature-u help?

The Best Practices section highlights a number of feature-based single-source-of-truth items of interest. These are guidelines, because you must implement them in your application code (feature-u is not in control of this).

Here is an example from the eateries feature:

The featureName is used to specify the top-level state location of this feature (see [*1*](#d59b)). feature-u guarantees the feature name is unique. As a result, it can be used to qualify the identity of several feature aspects.

For example:

• prefix action types with featureName, guaranteeing their uniqueness app-wide (see: feature-redux docs)
• prefix logic module names with featureName, identifying where that module lives (see: feature-redux-logic docs)
• depending on the context, the featureName can be used as the root of your feature state’s shape (see: feature-redux docs)

Because feature-u relies on [slicedReducer()](https://github.com/KevinAst/feature-redux#slicedreducer) (in the feature-redux package), a best practice is to use the reducer's embellished selector to qualify your feature state root in all your selector definitions. As a result the slice definition is maintained in one spot (see [*2*](#d59b)).

feature-u Benefits

In summary, the benefits of using feature-u include:

• Feature Encapsulation — isolating feature implementations improves code manageability
• Cross Feature Communication — a feature’s public API is promoted through a well-defined standard
• Feature Enablement — enable/disable features through a run-time switch
• Application Life Cycle Hooks — features can initialize themselves without relying on an external process
• Single Source of Truth — is facilitated in a number of ways within a feature’s implementation
• Framework Integration — configure the framework(s) of your choice (matching your run-time-stack) using feature-u’s extendable API
• UI Component Promotion — through Feature Routes
• Minimize Feature Order Dependency Issues — even in code that is expanded in-line
• Plug-and-Play — features can be added/removed easily
• Simplified Mainline — launcApp() starts the app running by configuring the frameworks in use, all driven by a simple set of features.
• Operates in any React Platform (including React Web, React Native and Expo)

Hopefully this article gives you a feel for how feature-u can improve your project. Please refer to the full documentation for more details.

feature-u allows you to focus your attention on the “business end” of your features! Go forth and compute!!

References

• A feature based approach to React development … Ryan Lanciaux
• How to better organize your React applications? … Alexis Mangin
• How to use Redux on highly scalable javascript applications? … Alexis Mangin
• The 100% correct way to structure a React app (or why there’s no such thing) … David Gilbertson
• Redux for state management in large web apps … David Clark