Plugins Feature Gate

[johnHackworth]

This PR adds a mocked example to the jetpack manage disabled warning in the plugins list. Also, creates a (dumb) component used to render a non clickable mocked example of any set of components, with some opacity gradient on top.

So, pretty much, transform this error screen:

Into this one:

How to test:

1. Go to any of your jetpack sites and disable Manage.
2. Go to http://calypso.localhost:3000/plugins
3. Switch to the manage disabled site
4. You should see the error screen
5. Make sure you can't interact anyway with the mocked components, neither with the mouse pointer or the keyboard.

And now, we can discuss the pros and the cons of this approach, @alternatekev @rickybanister @mtias @enejb @ebinnion

[mtias]

I fear this would complicate components by adding these early returns. What if we just do a css display: none for this limited use?

[johnHackworth]

yeah, I don't even need it, if I don't pass the mock site, it would not show this toggles... but if the point of the mocked-components is to show how the feature would work if active, I guess the interactive part is the most interesting one to show

[enejb]

missing a space in if(. I think showing the toggle is important. I wonder if we could capture the click event on the layer above. And not make it something that gets passed to the children under below. I am not sure if this approach would work as well because the user could tab into the toggle.

[johnHackworth]

Fixed the if(. I agree that the toggles are important. They are pretty much all the point of this section ... I think being able to see that you could interact with your plugins from there would be the more important part of this preview.

About how to disable them without passing a prop... well, if we could do something like what you are saying, something in the parent component, what would be neat. But I can't really figure out how to do it in another way, so any idea would be more than welcome :)

[mtias]

The result is definitely more compelling.

I think it may make sense if we encourage components to have a doc/example.json mocking data — something that is used for tests, potentially devdocs, and feature gate. Otherwise it seems like a lot of overhead.

[enejb]

I think that the overhead is fine. I think mock data should be minimally relavent. Even though we are duplicating the code. The code would only be loaded on the cases where we really need it. So plugins and the dev docs. I think this kind of optimization is not yet necessary.

I left some notes on the other PR. The code above looks good to me.

[johnHackworth]

About overhead ... if it's ok to reduce the examples to the most significative components of a view (like I did with this case, using only plugin-items it may be ok, since it will require some mocked json, but it would be small enough to be manageable from the component. If we wanted to try to represent the whole view there we would end with much bigger jsons and that would be a problem.

[rickybanister]

It looks good design-wise. @alternatekev is this the correct empty content image? Should it be the Jetpack logo?

I also agree about setting a standard of having mock data in an example.json file.

[alternatekev]

@rickybanister @johnHackworth Yes, it should be the Jetpack logo which is here: https://cloudup.com/ciQEft83LX3

[alternatekev]

@johnHackworth Instead of the gradient you've got, can we replace it with this:

background: linear-gradient(to bottom, rgba(243, 246, 248, 0.4), rgba( 243, 246, 248, 1));

[johnHackworth]

@alternatekev hmmm, I think there was some problems uploading the jetpack logo... I only see a white square in that link:

[johnHackworth]

Looking good!

@alternatekev @enejb if there isn't any big issue about anything, could we merge this PR so I can keep working in the ones that depends on it? Any change request could be added to a new issue

[enejb]

This sentence could be improved a bit.
Feature Example is a component used to render an mocked example of any feature. It renders whatever children it receives. The example is covered by a layer of fading gradient that gives the user a sense of UI that they are missing.

[enejb]

I left some really minor comments. That can be address just before you rebase and merge.

I also noticed that in my preview the autoupdates disabled. Which is pretty cool. Since it gives the user a very accurate picture of what to expect.

See:

Feed free to merge after addressing the minor issues.