feat(aio): force live-example to embedded-style on narrow screen#15887
feat(aio): force live-example to embedded-style on narrow screen#15887petebacondarwin merged 2 commits intoangular:masterfrom
Conversation
|
The angular.io preview for 9adc212 is available here. |
gkalpak
left a comment
There was a problem hiding this comment.
No tests for DeviceService ? 😱
There was a problem hiding this comment.
Do you need all previous values? I would expect we only care about the last one.
There was a problem hiding this comment.
I frankly don't know how to test DeviceService itself because it interacts directly with the browser environment and I have no idea how to simulate that. I'm open to ideas.
Note that we never tested this interaction before my refactor. Thanks to the DeviceService, we can simulate the effects of different devices on the application code w/o actually changing devices.
My bad. Should be new ReplaySubject<number>(1); . Fixing.
There was a problem hiding this comment.
I am not thrilled to access window directly here, but not a blocking issue 🌊
There was a problem hiding this comment.
Do you have a suggestion?
There was a problem hiding this comment.
In another PR, I used a Global provider so that I can more easily/cleanly mock it in tests. But maybe I am overthinking it. I am too used to AngularJS' $window 😁
There was a problem hiding this comment.
We should have a test for both embedded and non-embedded plnkrs.
There was a problem hiding this comment.
Can we please move all the helpers in one place?
9adc212 to
8ff736f
Compare
|
The angular.io preview for 8ff736f is available here. |
There was a problem hiding this comment.
Wow! OK, I will trust StackOverflow on this one 😁
There was a problem hiding this comment.
why do we use useragent string for this? it's the viewport resolution that matters not if it's a mobile device. Can we just use that instead?
There was a problem hiding this comment.
@IgorMinar I thought about that. It is the device and not the viewport that determines whether the link should show.
On desktop I might have the browser window narrow. I can always expand it to allow the plunker to play. I can also download the code. Neither of these options are available on mobile.
Are you suggesting that we change the logic so that plunkers/download are only available when the viewport is a certain width? I'm not sure what that width is but we could experiment. The download block, based on width, would be silly but we could get over it.
I await your decision.
There was a problem hiding this comment.
Please use viewport size. Only developers will see the site in narrow mode on desktop.
gkalpak
left a comment
There was a problem hiding this comment.
A couple of nitpicks.
Regarding the DeviceService tests: Not a blocker (especially since we didn't test this before), but there is some logic in DeviceService that could be tested.
(An injectable global/window would indeed come in handy here.)
There was a problem hiding this comment.
Unnecessary space between isMobileCheck and () 😁
8ff736f to
9d304ce
Compare
|
The angular.io preview for 9d304ce is available here. |
b493409 to
fba26fb
Compare
|
The angular.io preview for fba26fb is available here. |
|
Reworked the logic to depend on viewport width and eliminate user-agent check. See revised initial PR comment which explains everything. Adjusted PR title accordingly. |
gkalpak
left a comment
There was a problem hiding this comment.
Can you write up the rules of when each plnkr style is applied (and whether it should be opened in a new tab etc). I am pretty confused atm 😕
There was a problem hiding this comment.
Isn't this supposed to be flat-style (with a dash)?
There was a problem hiding this comment.
It can be any of the aliased choices - "flatstyle", "flat-style", or "flatStyle" - known to appear in the docs. I didn't feel it was worth testing them all. But I will pick the first mentioned, "flat-style"
There was a problem hiding this comment.
Nit: this.attrs.name --> attrs.name 😃
There was a problem hiding this comment.
Oops. Copy/paste error. Just "when ... requested"
There was a problem hiding this comment.
The "rules" are described in the documentation at the top.
There was a problem hiding this comment.
We are calling this onDestroy in ApiService and SwUpdatesService. Let's be consistent 😁
There was a problem hiding this comment.
In this block, we know that width > this.narrowWidth.
…ilable Adds DeviceService to detect mobile device and listen for window resize events.
fba26fb to
aced5e0
Compare
Regular plunker is unusable on narrow screen Refactors LiveExampleComponent and adds tests. Refactor width detection to `DeviceService` because need to know width change in 2 places. Keep “disable” option add in earlier spikes because simple and potentially useful in future.
aced5e0 to
d00565b
Compare
|
The angular.io preview for aced5e0 is available here. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Updated
@IgorMinar asked that "mobile" screen constraint be determined by viewport size, not user-agent.
After further experimentation, I determined that, while the regular style plunker is useless on narrow screens, the embedded-style plunker is functional which means that we can show plunkers on mobile devices.
Therefore, this PR's 2nd commit changes the logic. It forces plunkers to embedded style on narrow (1000px) screens. It allows download of sample zips (I suppose you might want to email it from your phone).
It removes the user-agent test for mobile devices from the first commit. It keeps the refactoring of window resize in the
DeviceServicebecause that check is needed in two places and because it seems like a favorable abstraction for future use.@sjtrimble CSS changes to control the embedded image width on narrow screens is more valid than ever.
Original
Cannot run plunkers on mobile devices nor does it make sense to download code sample to such devices. Therefore, should detect when on mobile and tell user that the live example is not available.
PR adds
DeviceServiceto detect mobile device. The check does not consider a tablet (e.g., iPad) a mobile device because I believe that plunkers should display fine on them. While it is foolish to download the code to a tablet, we do not prevent it.DeviceServicealso listen for window resize events. Moved window resize detection fromAppComponenttoDeviceService.displayWidthobservable so others can hear about it from a shared, device-focused service.I thought this would be important for addressing the no-LiveExample-on-mobile requirement. It turns out it wasn't needed but I kept it there because it feels like
AppComponentshould delegate this responsibility to a service that knows about the device.Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x")