Skip to content

Conversation

@kmelmon
Copy link
Contributor

@kmelmon kmelmon commented May 14, 2020

This change polishes up some unfinished work in TwoPaneView and gets it close to feature complete.

First some changes to dualscreeninfo:
-Fixed a bug in dualscreeninfo: windowRects was returning the "gap" between the screens instead of the screens. It was also returning a negative height instead of positive.
-Added "deviceRotation" prop to make it easier for TwoPaneView to do layout according to orientation.

And some changes to TwoPaneView:
-Now listening for deviceRotation, can handle layout in both horizontal and vertical directions
-No longer using dimensions to determine how large to size each pane, instead using flex:1
-removed panePriorityVerticalSpanning prop, this was only meant for prototype
-Default props were not working. Fixed.
-Several props were incorrectly copied to state. Fixed.
-Reworked the layout logic and verified all modes work correctly.
-Ensure we always create a pane to take up layout space even if the app didn't supply a child, ensures layout is consistent for each mode.
-Simplified the sample app

Note that I'm bumping the versions on dualscreeninfo and twopaneview to 0.1.0 for a couple reasons. The first reason is I'm adding a new prop. But more importantly, uing a version of 0.0.X causes confusion for the ^ specifier in dependencies - this doesn't work as there are special rules for ^. I worked this out by going to https://semver.npmjs.com and noticing that ^0.0.1 doesn't select any published version of react-native-twopaneview, and ^0.0.2 only selects version 0.0.2. This is weird! Let's not publish any more 0.0.X versions.

Still TBD:
-Use the Hinge component
-Raise onModeChange when layout changes
-Handle threshold of 640

@kmelmon kmelmon requested review from HomeroRR and thewulf7 May 14, 2020 23:38
@kmelmon kmelmon changed the title Finish TwoPaneView TwoPaneView improvements May 14, 2020
import React, {Fragment, Component} from 'react';
import {
View,
Dimensions,
Copy link
Collaborator

@HomeroRR HomeroRR May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Import on Dimensions no longer needed :) #Resolved

y: number;
}

export type DeviceRotation = 'rotation0' | 'rotation90' | 'rotation180' | 'rotation270';
Copy link
Collaborator

@HomeroRR HomeroRR May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we have a DeviceRotation type, why do users still need to use strings to specify the rotation?
Would be nice to have an enum that lists the rotation options so rotation0 can referred as rotation.0 instead of "rotation0" #Resolved

}
return size;
isHorizontalOrientation() {
return (this.state.rotation === 'rotation0' || this.state.rotation === 'rotation180');
Copy link
Collaborator

@HomeroRR HomeroRR May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again an enum on rotation would solve the need to know about the rotation strings #Resolved

Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 #Resolved


type State = {
dims: any,
windowRects: WindowRect[],
Copy link
Collaborator

@HomeroRR HomeroRR May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, do we still need windowRects? #Resolved


return (
<View style={{flexDirection: direction, width: this.state.dims.width, height:this.state.dims.height}}>
<View style={{flexDirection: this.isHorizontalOrientation() ? 'row' : 'column'}}>
Copy link
Collaborator

@HomeroRR HomeroRR May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, now with isHorizontalOrientation, orientation detection should be more reliable #Resolved

let horizontal = this.state.dims.width >= this.state.dims.height;
// TODO - render Hinge
let horizontal = this.isHorizontalOrientation();
let separatorWidth = horizontal ? DualScreenInfo.hingeWidth: '100%';
Copy link
Collaborator

@HomeroRR HomeroRR May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly would be the use case for rendering '100%' of the separatorWidth? #Pending

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the device is in horizontal orientation, the two panes are rendered left/right. Otherwise (in vertical orientation) the two panes are rendered top/bottom. That's what this logic is for: depending on the orientation, the width is either the full width of the screen, or just the hinge width. Make sense?

Your question also was a good catch - there was a bug in that separatorHeight didn't have similar logic. This is fixed now.

I'm having trouble actually testing vertical orientation, as my drop of the emulator isn't doing a re-layout on orientation change. I'm chasing this down now.


In reply to: 425978578 [](ancestors = 425978578)

}
private val windowRects: List<Rect>?
get() = mDisplayMask?.getBoundingRectsForRotation(rotation)
private val windowRects: List<Rect>
Copy link
Collaborator

@HomeroRR HomeroRR May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. #Resolved

],
"dependencies": {
"react-native-dualscreeninfo": "~0.0.1"
"react-native-dualscreeninfo": "0.1.0"
Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing ^ #Resolved


return (
<View style={{flexDirection: direction, width: this.state.dims.width, height:this.state.dims.height}}>
<View style={{flexDirection: this.isHorizontalOrientation() ? 'row' : 'column'}}>
Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you also move it out to separated var? Inline styles are code smell :) #Resolved

}
if (this.state.panePriority === PanePriority.Pane1) {
return this.renderPane1(this.getEntireSize());
if (paneMode === PaneMode.Double) {
Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: you can use switch here #Resolved

}

_handleDimensionsChange = (dimensions: { window: any; }) => {
_handleSpanningChanged = (update: DualScreenInfoPayload) => {
Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add private modifier pls #Resolved

class RNDualScreenInfoModule implements IDualScreenInfoModule {
private mIsSpanning: boolean = false;
private mWindowRects: WindowRect[] = [];
private mRotation: DeviceRotation = 'rotation0';
Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its ok since we have typecheck by Typescript #Resolved

return if (boundings == null || boundings.size == 0) {
listOf(windowBounds)
} else {
val hingeRect = boundings.get(0)
Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better to use boundings[0], and not allocate var #Resolved

val rightRect = Rect(hingeRect.right, 0, windowBounds.right, windowBounds.bottom)
listOf(leftRect, rightRect)
}
else {
Copy link
Contributor

@thewulf7 thewulf7 May 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need for new line here #Resolved

@kmelmon
Copy link
Contributor Author

kmelmon commented May 17, 2020

@HomeroRR I'm checking this in now as I want to have this in with enough time to ferret out any issues before //build which starts on Tuesday.

Feel free to leave any additional comments and I will address this in a follow-up change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants