Add parent-child relationship to features

[vudzkostek]

When having multiple flags related to one feature (eg. we have a feature that we can enable with one flag and because we are also developing two extension to this feature we have another two flags etc.) it would be nice if there would be a possibility to group flags.
Eg. by adding groupId = "" in flag declaration:

SomeFeature {
        withOption("Enabled")
        withDefaultOption("Disabled")
        withGroupId("FeatureSet1")
}

And based on that we could introduce some new way of representing flags in groups:

• expandable list - regular items (without group) could be represented as switches, groups could be represented as expandable list items
• child screen - regular items (without group) could be represented as switches, groups could be items without switch that would open additional screen with child flags.

Related to issue: #82

[MiSikora]

There are two ideas here. Grouping flags and having some parent–child relation between the flags.

As far as the grouping goes you can at the moment group features in tabs using Gradle modules. I think it is a better idea than groupId as it also requires you to decouple flags in your code.

// First module
laboratory {
  featureFactory {
    packageName = "com.app.first"
    isPublic = true
    projectFilter { it == project }
  }

  FeatureA {
    withOption("Enabled")
    withDefaultOption("Disabled")
  }
}

// Second module
laboratory {
  featureFactory {
    packageName = "com.app.second"
    isPublic = true
    projectFilter { it == project }
  }

  FeatureB {
    withOption("Enabled")
    withDefaultOption("Disabled")
  }
}

Then in the app code.

import com.app.first.featureGenerated as firstModule
import com.app.second.featureGenerated as secondModule

val configuration = LaboratoryActivity.Configuration.builder()
    .laboratory(Laboratory.inMemory())
    .featureFactories(mapOf(
        "First" to FeatureFactory.firstModule(),
        "Second" to FeatureFactory.secondModule(),
    ))
    .build()
LaboratoryActivity.configure(configuration)

It will group them like this.

The only thing is that generated factories need to be in separate packages, which might be annoying (but personally I like that it forces you to split it logically in the code as well).

Now to the second part – parent–child relationship. It's not that straightforward because the example assumes that a feature has only two states. My first idea would be to do it like this.

laboratory {
  parentFeature("ParentFeature") {
    isEnabledByDefault = true // optional parameter

    ChildFeature {
      withDefaultOption("FirstOption")
      withOption("SecondOption")
      withOption("ThirdOption")
    }
  }
}

This way you can have a switch on a parent item as it is constrained only to two values and depending on a state of this switch the children could be expanded or contracted. It also prevents you from mixing group IDs between different modules.

[AlexKrupa]

How about children depending on options instead of features?

Consider this hierarchy:

ParentFeature:
  |- Disabled
  |- EnabledLegacy
     |- FirstLegacyChildFeature
     |- SecondLegacyChildFeature
  |- EnabledModern
     |- FirstModernChildFeature
     |- SecondModernChildFeature
        |- Enabled
        |- Disabled

Another thing to consider is the direction of dependencies. It seems to me that it would make sense for parents to define their children instead of the opposite. That way the hierarchy of features (and their options) would match a project's module tree.

Am I missing something?

[MiSikora]

Yes, linking to parent options makes much more sense. The UI will be harder though but that is a separate topic.

[MiSikora]

@vudzkostek I changed the issue title. If you feel like there is a need for different grouping mechanism please open another issue. Though IMO using Gradle modules solves this problem.