-
-
Notifications
You must be signed in to change notification settings - Fork 147
Conversation
Codecov Report
@@ 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 |
import renderMobile from './mobile'; | ||
import renderTablet from './tablet'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 theirenv
whether they are ontablet
orphone
.
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 () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no expect statement...?
There was a problem hiding this comment.
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
🥇
<ApolloProvider client={testClient}> | ||
<FriendProvider> | ||
<AuthProvider initialAuthUser={initialAuthUser}> | ||
<ProfileModalProvider> | ||
{children} | ||
</ProfileModalProvider> | ||
</AuthProvider> | ||
</FriendProvider> | ||
</ApolloProvider> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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
<ApolloProvider client={testClient}> | ||
<FriendProvider> | ||
<AuthProvider initialAuthUser={initialAuthUser}> | ||
<ProfileModalProvider> | ||
{children} | ||
</ProfileModalProvider> | ||
</AuthProvider> | ||
</FriendProvider> | ||
</ApolloProvider> |
There was a problem hiding this comment.
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.
253d739
to
dfe8657
Compare
Description
This is an Initial roadmap to supporting the tablet screen. The goal of supporting the current feature is as follows.
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
andportrait
mode independently, which we aren't currently considering, that could be inside thetablet
orphone
file itself. However, I'd wanted to make this clear thatphone
andtablet
rendering sourcecode rely separately upon each file.Tests
tablet
fromcoverage
currently.mobile
tests still exist and thisPR
won't affect test codes to be updated.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.yarn lint && yarn tsc
yarn test
oryarn test -u
if you need to update snapshot.