Plans: add main plan component — PlanFeatures

[lamosty]

Add PlanFeatures component as a part of bigger plans-redesign started in #5715.

Example usage

import PlanFeatures from 'my-sites/plan-features';
import { PLAN_FREE } from 'lib/plans/constants';
import QueryPlans from 'components/data/query-plans';

export default MyComponent() =>
   <div>
      <QueryPlans />
      <PlanFeatures plan={ PLAN_FREE } />
   </div>

Testing

1. PlanFeatures was added to devdocs into App Components;
2. Navigate to http://calypso.localhost:3000/devdocs/app-components/plan-features;
3. See the redesigned plan components (free, premium and business);
4. Look for errors;
5. Is everything fine?

Screenshots

Note: In the second screenshot, the Business plan has a strange price. This is probably related to the recent PR #6001 by @gwwar but she's already working on a better solution here: #6046. That's why I've left it as it is.

If it is not related to that, I'll fix it.

Although this is still work in progress, I think I've arrived to a presentable code so please review. :)

cc @gwwar @rralian @mtias @artpi @retrofox

Test live: https://calypso.live/?branch=add/plan-features-plan

[gwwar]

I understand what you're doing here, but this may be somewhat difficult to maintain in the future. Maybe add a list of feature references to the plan object instead?

e.g.

    [ PLAN_FREE ]: {
        getFeatures: () => [ FEATURE_3GB_STORAGE, FEATURE_WP_SUBDOMAIN,  ... ]
        getTitle: () => i18n.translate( 'Free' ),
        getPriceTitle: () => i18n.translate( 'Free for life' ),
        getProductId: () => 1,
        getDescription: () => i18n.translate( 'Get a free blog and be on your way to publishing your first post in less than five minutes.' )
    },

[lamosty]

Hmm, I thought we don't want to duplicate the references (as they are currently made from the opposite direction). But I'll implement this as I think it's a better solution. We also don't need the order prop in features because we can just order them in the array.

[gwwar]

👍 Looking good so far. #6046 should fix the visual oddities with price. Let me know if you need help with new selectors.

[lamosty]

@gwwar Thanks for all the comments.

I've added the new selectors (in #6082) and rebased this PR on top of that PR so please ignore the noise. Does it look better? :)

[gwwar]

Hmm this could get out of sync too. If we need the reverse lookup maybe lets remove this, and add in helper function like:

getPlansForFeature( feature )

We could also memoize the results if this is called frequently

[lamosty]

Good point. Do we want to do it in this PR? I don't need the getPlansForFeature helper fn here, that's why I'm asking. I think it's better suited for a standalone PR.

[gwwar]

We can leave this for a future PR

[gwwar]

Looking good! I left a few notes, but when you're ready, this is good to 🚢

[lamosty]

@gwwar I've rebased this PR on top of master but I'm getting errors now (screenshots below) which I wasn't getting before. I started rebasing this on Friday (so the first rebase includes your #6046). After the first rebase, I think I got no new errors. However, I then pulled in new code in master today, rebased it again and now I'm getting the errors (screenshots below).

The first part about state validation failed is a bit unknown to me (I only know that we store state to localForage and on loading it back we validate it — but I don't know what I should do with this error). The second part refers to my-sites/plan-features/index.jsx. I'm getting bill_period_label out of a plan object, like this:

billingTimeFrame: getPlan( state, planProductId ).bill_period_label

However, initially when there are no plans data, it probably fails because undefined.bill_period_label is not a thing (of course). Shouldn't we add the loading placeholder plan like it's currently being done on the /plans page?

[gwwar]