Update page component to match v1.10.2

[andrewpye]

Brings polaris-page in line with the latest Polaris release and tidies up the component's structure. New features include responsiveness for page actions, an optional separator between page header and content, and a singleColumn width option.

Separator:

Example of actions responsiveness in the dummy app (N.B. the caret for the secondary actions list doesn't render because the icon's not included in the dummy app and didn't seem worth adding just for this):

P.S. template source for the above GIF is just a simple page with a primary action and a couple of secondary ones:

{{#polaris-page
  title="This is the application route"
  primaryAction=(hash text="Primary" action=(action (mut primaryClicked) true))
  secondaryActions=(array
    (hash text="Secondary 1" action=(action (mut secondary1Clicked) true))
    (hash text="Secondary 2" action=(action (mut secondary2Clicked) true))
  )
}}
  <div>Primary clicked: {{primaryClicked}}</div>
  <div>Secondary 1 clicked: {{secondary1Clicked}}</div>
  <div>Secondary 2 clicked: {{secondary2Clicked}}</div>
{{/polaris-page}}

[vladucu]

couple of comments / questions

[vladucu]

can we list here actionGroups property and add a TODO?

[vladucu]

use gt computed

[vladucu]

the Polaris breadcrumbs uses a nav for the tag and doesn't has this class? Should we update like in polaris and move the class in a div in the page-header component?
or is there something I'm missing?

[vladucu]

don't see this destructive condition in Polaris

[andrewpye]

Great catch, thanks!

[vladucu]

should this each be wrapper in a if secondaryActions?

[vladucu]

all these wrapper elements are super neat....but I wonder if it wouldn't be much more readable if we'd just use if else statements even if that means a bit of duplication

[andrewpye]

It'd mean a lot of duplication, basically the entire template. That'd make maintaining any future updates (which are likely to be fairly minor I'd guess since the React implementation seems to have matured a lot) trickier, both in terms of knowing that each update has to be added twice, and from the extra amount of code the maintainer will have to scroll through. I do see where you're coming from though, so I'll add comments to each of the potentially confusing wrapper-element usages so that their intent can be seen instantly 👍

[vladucu]

sounds good

[vladucu]

same, can we drop this and just use @private/@public for doc

[vladucu]

can we list above for action properties supported...seems some are not supported, mark them as TODO

[andrewpye]

@vladucu I'll do this under a separate PR where I'm going to remove the inconsistencies between using text/content and onAction/action for action hashes 👍

[vladucu]

looks great man!

Let's merge this and update #86 ...will jump on that right after

[vladucu]

👍