What are groups for and how to use them?

[artm]

I can see that features can be placed in groups, but what does it mean?

Can a feature participate in multiple groups?
Can a group be toggled on off?
Can a custom strategy find out feature's group(s)? How?

[artm]

After having read the sources I've found that groups are exclusive (a feature can only be in one group) and are only used to group the features in the dashboard at the moment.

I'm looking for a way to implement subscribable feature bundles and I think I could almost use groups for that. My current idea is to implement a "subscription" strategy that sort of does the opposite of what it sounds like :-) Each client is subscribed to a number of feature bundles (= groups) and this strategy switches off any feature the current client isn't subscribed to. This way the product managers can flip individual features for all subscribers (with db strategy) or just themselves (with cookies strategy).

To implement this I would need to be able to find out inside the custom strategy to which group a feature belongs (given a feature symbol). I guess I can find that by reading the sources further, but it would be helpful for the others if the groups were explained in more details in the readme (including the API I'm looking for).

[rolftimmermans]

Groups are for visually grouping only. I'm not entirely sure I understand your use case, have you managed to figure out a possible solution?

[artm]

I planned it, but haven't gotten back to implementing it yet. I'll probably be able to implement all I need on the application side.

My use case is as follows:

1. the application consists of several "big features", say A, B and C
2. every customer has access to a custom set of "big features", e.g. customer x subscribes to A+B and customer y to A+C.
3. every "big" feature is being developed with "small features" (actual flipfloppable features), e.g. A is A1, A2, A3, ..., B = B1, B2, B3, ... etc.
4. product manager tests new small features, they would want to toggle individual features on for themselves. Say they're testing a feature B4
5. if product manager approves a small feature B4, they want to enable it for all customers with subscription to the big feature B.

So when I saw that flipflop has feature groups I though we could base the subscribable "big features" on groups. That is still my plan. My idea is to have a "group subscriptions" strategy which for a current customer disables any feature from unsubscribed groups. This way the product manager can simply enable the B4 using database strategy and it will remain enabled for all customers with group B subscription, but will be disabled by the group subscription strategy for the customers without subscription to B.

Does that make any sense?

[rolftimmermans]

It seems to me you have a very specific use case, and I guess that with a custom strategy you should be able to implement it. That's how they were designed at least.

If you run into any issues creating a custom strategy please post here again!