GoogleChromeLabs / react-shrine

"Shrine" Progressive Web App sample built with React
https://react-shrine.web.app/
Apache License 2.0
331 stars 54 forks source link

Feature/latest version based #13

Closed anton-karlovskiy closed 5 years ago

anton-karlovskiy commented 5 years ago
  1. this project was bootstrapped with latest version of create-react-app and ejected -> quite stable in local and build
  2. upgraded or replaced deprecated packages like material ui and connected react router etc
  3. the main purpose of this dev was to implement connection aware code-splitting/lazy loading PS: this project is based on react 16.8.6 and react-dom 16.8.6 -> we can use react hooks
addyosmani commented 5 years ago

Some UX requests using https://react-shrine.firebaseapp.com/category/fashion/1 as an example:

Can we change .item-view-wrapper .item-display .image-container from 180px to something between 250px to 300px so that the main item image is a little larger?

Can we change the zoomed in view so it renders within the main shell of the application with an 'X' to return back to the normal product view? Something like this?

http://localhost:5000/category/feature/1/zoom image

anton-karlovskiy commented 5 years ago

Some UX requests using https://react-shrine.firebaseapp.com/category/fashion/1 as an example:

Can we change .item-view-wrapper .item-display .image-container from 180px to something between 250px to 300px so that the main item image is a little larger?

Can we change the zoomed in view so it renders within the main shell of the application with an 'X' to return back to the normal product view? Something like this?

http://localhost:5000/category/feature/1/zoom image

Yes, let me change the ux as commented.

addyosmani commented 5 years ago

Thank you, Anton. Something I noticed in the built version during testing:

Normal load - 106KB script

image

Clicking on the item to get the magnifier view loads another ~1KB dynamic/async chunk

image

This chunk does not appear to contain the react-magnifier package. I think this is because that dependency is being included in one of the other chunks (maybe runtime or main) which is still being loaded when you are on a slower connection.

Could we investigate further? (e.g we might need to turn on proper source-maps and check the output with source-map-explorer to see where react-magnifier ended up).

My guess is we may need something like https://webpack.js.org/plugins/split-chunks-plugin/ (or another approach) to ensure that we're breaking react-magnifier into a chunk that is not included in the default vendor bundles.