Skip to content
This repository has been archived by the owner on May 7, 2023. It is now read-only.

Roadmap to tablet screen support #100

Merged
merged 5 commits into from
Feb 4, 2020
Merged

Roadmap to tablet screen support #100

merged 5 commits into from
Feb 4, 2020

Conversation

hyochan
Copy link
Member

@hyochan hyochan commented Feb 1, 2020

Screen Shot 2020-02-01 at 4 42 16 PM

Screen Shot 2020-02-01 at 4 41 51 PM

Description

This is an Initial roadmap to supporting the tablet screen. The goal of supporting the current feature is as follows.

  1. Do not implement the same thing twice other than the design.
  2. Provide independent circumstances so that the code is well-read in each condition (phone or tablet?).
  3. Do not write the test code twice.
    • I have ignored the tablet screen from the jest coverage. However, I'd like to include the rendering test for the tablet in the future.

** NOTE **
If you want to support the landscape and portrait mode independently, which we aren't currently considering, that could be inside the tablet or phone file itself. However, I'd wanted to make this clear that phone and tablet rendering sourcecode rely separately upon each file.

Tests

  • Ignore tablet from coverage currently.
  • mobile tests still exist and this PR won't affect test codes to be updated.
  • Add test for DeviceProvider.

Checklist

Before you create this PR confirms that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I signed the [CLA].
  • Run yarn lint && yarn tsc
  • Run yarn test or yarn test -u if you need to update snapshot.
  • I am willing to follow-up on review comments in a timely manner.

@hyochan hyochan added this to the Beta Release milestone Feb 1, 2020
@codecov
Copy link

codecov bot commented Feb 1, 2020

Codecov Report

Merging #100 into master will decrease coverage by 0.52%.
The diff coverage is 98.16%.

@@            Coverage Diff            @@
##           master    #100      +/-   ##
=========================================
- Coverage   89.23%   88.7%   -0.53%     
=========================================
  Files          44      33      -11     
  Lines        1152    1036     -116     
  Branches      123     116       -7     
=========================================
- Hits         1028     919     -109     
+ Misses         75      69       -6     
+ Partials       49      48       -1

@hyochan hyochan self-assigned this Feb 1, 2020
Comment on lines +21 to +22
import renderMobile from './mobile';
import renderTablet from './tablet';
Copy link
Contributor

@marsinearth marsinearth Feb 2, 2020

Choose a reason for hiding this comment

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

Do you have a specific reason why you separated these two seemingly-almost-same files rather than making some branches in styled-components with media queries in one script?

Copy link
Contributor

Choose a reason for hiding this comment

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

I am also worried about maintenance issues with repeated codes. want to hear how @hyochan think about it

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted to make them dependant even we have the duplication.
This is easier for contributors to test out in their env whether they are on tablet or phone.
For step-level code like our project, it isn't a good idea to weave things together.
We'll try to integrate them and make it shorter when we met those stages.

Copy link
Member Author

Choose a reason for hiding this comment

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

In addition, it looks the same now, but if you see our design in figma, there are much-complicated ones like [Message].

We also don't know yet what's coming next.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wanted to make them dependant even we have the duplication.
This is easier for contributors to test out in their env whether they are on tablet or phone.
For step-level code like our project, it isn't a good idea to weave things together.
We'll try to integrate them and make it shorter when we met those stages.

That makes sense! it is really good. code sharing sometimes makes it hard to read and that leads other issues when working with different people!

});

describe('Interactions', () => {
it('should setUser', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

no expect statement...?

Copy link
Member Author

Choose a reason for hiding this comment

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

Leaving out for your PR 🥇

Comment on lines +35 to +43
<ApolloProvider client={testClient}>
<FriendProvider>
<AuthProvider initialAuthUser={initialAuthUser}>
<ProfileModalProvider>
{children}
</ProfileModalProvider>
</AuthProvider>
</FriendProvider>
</ApolloProvider>
Copy link
Contributor

Choose a reason for hiding this comment

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

damn...these perplexed contexts are out of the form of beauty. I'll definitely work on manipulating Apollo client state management [1][2] to contribute getting rid of them.

Copy link
Contributor

Choose a reason for hiding this comment

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

@marsinearth do you mean the nested form of providers? this might be helpful

Copy link
Member Author

Choose a reason for hiding this comment

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

That is a good idea! I hope you can bring up a better code and announce it to us in the meetup.
Also, don't forget to commit expect statement you want to accomplish in the previous review.

Copy link
Contributor

@godon019 godon019 left a comment

Choose a reason for hiding this comment

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

An interesting approach, I would like to try this and then see how it scales as app grows

Comment on lines +35 to +43
<ApolloProvider client={testClient}>
<FriendProvider>
<AuthProvider initialAuthUser={initialAuthUser}>
<ProfileModalProvider>
{children}
</ProfileModalProvider>
</AuthProvider>
</FriendProvider>
</ApolloProvider>
Copy link
Contributor

Choose a reason for hiding this comment

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

@marsinearth do you mean the nested form of providers? this might be helpful

- Add [DeviceProvider] to distinguish the device in the first hand.
- Disable tablet.tsx from collecting coverage since it`s interaction testing in mostly covered in mobile.
- Seperate the ui rendering with mobile & tablet and common utilities are passed by index.tsx.
@hyochan hyochan merged commit d67ed76 into master Feb 4, 2020
@hyochan hyochan deleted the feat/tablet-support branch February 4, 2020 02:15
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants