Feature Enablement

By default all Features are active. If however you wish to disable a feature, you merely set it's Feature.enabled boolean property (part of the Built-In aspects):

export default createFeature({
  name:     'sandbox',
  enabled:  false,
  ... snip snip
});

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:

export default createFeature({
  name:     'sandbox',
  enabled:  inDevelopmentMode(),
  ... snip snip
});

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

How does it work?

Because feature-u is responsible for aggregating assets across all features, it's a very simple process to disable a feature ... the features supplied to launchApp() are merely pruned to a set of active features. It's just as though disabled features never existed (logically).

To fully understand how this works, consider the following characteristics of a disabled feature (read this table like a sentence ... injecting the header in front of each column):

The internal implementation of Feature Enablement is extremely straightforward! The underlying reason for this simplicity is that feature-u is in charge of the setup and configuration of your application. Easy Peasy! I love it when a design comes together!!

Feature Existence and Dependencies

When a feature is completely self-contained (i.e. it has NO fassets definition), then there are no other consideration in disabling it ... you simply disable it and it disappears!

If however one feature depends on another (i.e. it has fassets definition), then there are additional factors to consider.

As you know, the Fassets object is used to facilitate Cross Feature Communication. You can also use it to determine whether a feature is present ... through it's Fassets.hasFeature() method.

• It could be that featureA will conditionally use featureB if it is present.

  if (fassets.hasFeature('featureB') {
    ... do something featureB related
  }
  

• It could be that featureC unconditionally requires that featureD be present. This can be checked in the appWillStart() Application Life Cycle Hook.

  appWillStart({fassets, curRootAppElm}) {
    assert(fassets.hasFeature('featureD'), '***ERROR*** I NEED featureD');
  }
  

Note: As an alternative to using Fassets.hasFeature(), you can simply reason over the existence of "well-known fasset resources" specific to a given feature.