5 ms·

An Opinionated React Progressive Web App Repository

71 points by simonfl3tcher 10y ago

urs2102 10y ago
You mention that choosing mocha and chai were conscious decisions over jest, any particular reason why?
- simonfl3tcher 10y ago
  It was a personal choice more than anything else. I personally have more experience with Mocha and Chai and I feel like they are slightly more mature than something like Jest. As I suggested in the README, this could very easily be switched out of desired.
rmrfrmrf 10y ago
Any plans to make a Yeoman generator out of it? (Do people even use Yeoman anymore?)
- simonfl3tcher 10y ago
  No plans at the moment. I would like to make this an flourishing open source project so it may be something we discuss later on down the line. The repository is open for contributions
gorm 10y ago
Doesn't seem to work with javascript turned off. In earlier days this was first sign of being progressive, but new generation of developers doesn't seem to care about this?
- WA 10y ago
  Progressive web apps (PWAs) are JS-apps that can be used offline in a browser.
- simonfl3tcher 10y ago
  As @WA suggests PWA's are JS-apps that can be used offline in a browser. You need JavaScript to instantiate the Service Worker which caches the request, without JS and in turn the Service Worker you no longer have a PWA. PWA's are something that Google is pushing pretty hard right now, to me that suggests there is becoming less of a concern around JavaScript being turned off than previous years. https://developers.google.com/web/progressive-web-apps/ https://developers.google.com/web/progressive-web-apps/
  - Touche 10y ago
    Progressive enhancement is not about people turning off JavaScript, it's about JavaScript failing, which can happen for a variety of reasons.
- pluma 10y ago
  Progressive Web Apps (PWAs) are not really related to progressive enhancement. The former is about web apps that bridge the gap between web and native. Technologically the foundation lies in using service workers for offline support, and serving the app over SSL. Not only do these web apps work offline but when using modern browsers on mobile (e.g. Firefox/Chrome on Android) it's possible to "install" them and use them like native apps. The latter is about websites that don't rely on CSS or JS to provide critical interaction, i.e. making the website work if neither CSS nor JS is available (though generally this is simplified to "when JS is disabled"). Apart from the name the two are only related in that both are intended to help users in sub-optimal scenarios (e.g. on slow/unreliable connections).
  - Touche 10y ago
    "web apps" vs. "websites" isn't a black and white thing. SPA advocates like to say they are building "web apps" as an excuse for providing a shitty user experience. Clearly some things are more app-like (Slack) and some things are more site-like (NYT), but there's a giant gray-area in the middle. People in that gray-area call their things apps so they could avoid responsibility.
    - andybak 10y ago
      Yep. I wonder if we could memify this in an attempt to fight back: "Your f*ing blog is not an app" or something similar. The complete abandonment of any form of progressive enhancement is depressing. We need to get some real metrics on user engagement (slow load over poor connections), SEO drawbacks (yes google can index this stuff but does it rank as well?) and accessibility (how well do screen readers really cope?). Get some facts and start hitting people over the head with them.
      - pluma 10y ago
        You might want to look deeper into PWAs. Nothing about PWAs says you can't do server-side rendering. In fact, performance and offline support are major factors in development quality. Lighthouse (linked from the repo) checks for these things too.
- lucideer 10y ago
  As others here have remarked, a PWA is a term with a specific meaning: it was coined with the advent of the Service Worker API to refer to any webapp using the service worker cache. However, that still doesn't rule out producing a "progressively enhanced" progressive web app. In fact, React (which this project uses) makes progressive enhancement even easier with ReactDOMServer and the componentWillMount/componentDidMount differentiation. So the downvotes are particularly unwarranted.
lettersdigits 10y ago
what about including the reducers/sagas/actions/action types inside a component's folder (assuming it has its own reducers/sagas)?
- simonfl3tcher 10y ago
  Personally I have kept these separate before. I would just have /src/actions/{actionType}, but, that is not to say that these cannot be included in the components folder, and actually makes sense given that a certain action is generally associated with a certain component. What is your opinion?
  - lettersdigits 10y ago
    My opinion and current way of working is: * if the reducers/actions/action creators/action types/sagas are UNIQUE to the component and are not being used elsewhere then it should sit together in the same folder . * if they are more generic/being used in more than one place then I would put them all in a separate folder, since all of those parts are actually doing more or less one thing - manage a specific sub-section of your app's state. This sub-section of your app's state can then be shared by many more than one entry point, which is extremely useful for me. A REAL example: I took the redux-login-saga-flow (https://github.com/sotojuan/saga-login-flow/tree/master/app https://github.com/sotojuan/saga-login-flow/tree/master/app), changed the folder structure so now i can just import the login state management into every entry point i want, and bam - it just works, since all of that state sits under 'login'. I can now create a new webpage and add all of the login complexity in only a few minutes of work . I Hope I was clear (edit: some cleanup and spacing)
    - simonfl3tcher 10y ago
      Yep, we very clear and make a lot of sense. Would tend to agree with everything that you have said.
jjg77 10y ago
How would you hook this up to a node.js back end?
- simonfl3tcher 10y ago
  Like I outlined in the README. The aim would be to keep it static while calling out to an API. https://github.com/simonfl3tcher/react-progressive-web-app#hosting https://github.com/simonfl3tcher/react-progressive-web-app#h... To be honest, you could hook this up to server-side rendering one way or another. However, I haven't looked at server-side rending too much, and I am not sure what the affect of doing this would be on the TTI. As a result, I cannot say one way or another whether this would be a good idea or not.
Bahamut 10y ago
As far as I can tell, it is the Webpack offline-plugin doing the heavy-lifting - is this correct?
- simonfl3tcher 10y ago
  I would tend to disagree with that statement. While the webpack offline plugin is creating the service worker which is putting the requests into the cache storage there is a lot more to achieving a good PWA than just a Service Worker. You need to have a manifest.json file which provides all the information for installing your app to your devise. For more information see https://developer.mozilla.org/en-US/docs/Web/Manifest https://developer.mozilla.org/en-US/docs/Web/Manifest. You also need to reduce the Time To Interactivity (TTI) to be under 5,000ms. Webpack is doing a lot of the heavy lifting here by performing tree shaking, vendor chunking and route based chunking. All things that contribute to getting this under 5,000ms. If you would like to know more information as to how to achieve a good PWA, I would urge you to run Lighthouse against the demo which will outline all the things that contribute to a good PWA.
- simonfl3tcher 10y ago
  This is a great check list if you are looking to create a PWA. https://developers.google.com/web/progressive-web-apps/checklist https://developers.google.com/web/progressive-web-apps/check...
hazza1 10y ago
For most people I'd recommended using the official helper app instead - https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#making-a-progressive-web-app https://github.com/facebookincubator/create-react-app/blob/m... Although, in truth I'd use the much smaller preact library - https://github.com/developit/preact-boilerplate https://github.com/developit/preact-boilerplate
- simonfl3tcher 10y ago
  This repository is an opinionated repository and comes with a lot more things than the create-react-pwa. i.e. Webpack, Mocha, Flow, Nightwatch, component structure. I agree, if you wanted to start from scratch with your own structure create-react-pwa is probably a better repository for you. However, if you like the opinions formed in this repo then it will allow you to get started straight away with static type checking, e2e testing, unit testing, tree shaking, and code splitting all built in. You raise a good point regarding Preact, it is something that I have considered but decided to stick with React until it became problematic.

71 points by simonfl3tcher 10y ago

urs2102 10y ago

You mention that choosing mocha and chai were conscious decisions over jest, any particular reason why?

simonfl3tcher 10y ago
It was a personal choice more than anything else. I personally have more experience with Mocha and Chai and I feel like they are slightly more mature than something like Jest. As I suggested in the README, this could very easily be switched out of desired.

rmrfrmrf 10y ago

Any plans to make a Yeoman generator out of it? (Do people even use Yeoman anymore?)

simonfl3tcher 10y ago
No plans at the moment. I would like to make this an flourishing open source project so it may be something we discuss later on down the line. The repository is open for contributions

gorm 10y ago

Doesn't seem to work with javascript turned off. In earlier days this was first sign of being progressive, but new generation of developers doesn't seem to care about this?

WA 10y ago
Progressive web apps (PWAs) are JS-apps that can be used offline in a browser.
simonfl3tcher 10y ago
As @WA suggests PWA's are JS-apps that can be used offline in a browser. You need JavaScript to instantiate the Service Worker which caches the request, without JS and in turn the Service Worker you no longer have a PWA. PWA's are something that Google is pushing pretty hard right now, to me that suggests there is becoming less of a concern around JavaScript being turned off than previous years. https://developers.google.com/web/progressive-web-apps/ https://developers.google.com/web/progressive-web-apps/
- Touche 10y ago
  Progressive enhancement is not about people turning off JavaScript, it's about JavaScript failing, which can happen for a variety of reasons.
pluma 10y ago
Progressive Web Apps (PWAs) are not really related to progressive enhancement. The former is about web apps that bridge the gap between web and native. Technologically the foundation lies in using service workers for offline support, and serving the app over SSL. Not only do these web apps work offline but when using modern browsers on mobile (e.g. Firefox/Chrome on Android) it's possible to "install" them and use them like native apps. The latter is about websites that don't rely on CSS or JS to provide critical interaction, i.e. making the website work if neither CSS nor JS is available (though generally this is simplified to "when JS is disabled"). Apart from the name the two are only related in that both are intended to help users in sub-optimal scenarios (e.g. on slow/unreliable connections).
- Touche 10y ago
  "web apps" vs. "websites" isn't a black and white thing. SPA advocates like to say they are building "web apps" as an excuse for providing a shitty user experience. Clearly some things are more app-like (Slack) and some things are more site-like (NYT), but there's a giant gray-area in the middle. People in that gray-area call their things apps so they could avoid responsibility.
  - andybak 10y ago
    Yep. I wonder if we could memify this in an attempt to fight back: "Your f*ing blog is not an app" or something similar. The complete abandonment of any form of progressive enhancement is depressing. We need to get some real metrics on user engagement (slow load over poor connections), SEO drawbacks (yes google can index this stuff but does it rank as well?) and accessibility (how well do screen readers really cope?). Get some facts and start hitting people over the head with them.
    - pluma 10y ago
      You might want to look deeper into PWAs. Nothing about PWAs says you can't do server-side rendering. In fact, performance and offline support are major factors in development quality. Lighthouse (linked from the repo) checks for these things too.
lucideer 10y ago
As others here have remarked, a PWA is a term with a specific meaning: it was coined with the advent of the Service Worker API to refer to any webapp using the service worker cache. However, that still doesn't rule out producing a "progressively enhanced" progressive web app. In fact, React (which this project uses) makes progressive enhancement even easier with ReactDOMServer and the componentWillMount/componentDidMount differentiation. So the downvotes are particularly unwarranted.

lettersdigits 10y ago

what about including the reducers/sagas/actions/action types inside a component's folder (assuming it has its own reducers/sagas)?

simonfl3tcher 10y ago
Personally I have kept these separate before. I would just have /src/actions/{actionType}, but, that is not to say that these cannot be included in the components folder, and actually makes sense given that a certain action is generally associated with a certain component. What is your opinion?
- lettersdigits 10y ago
  My opinion and current way of working is: * if the reducers/actions/action creators/action types/sagas are UNIQUE to the component and are not being used elsewhere then it should sit together in the same folder . * if they are more generic/being used in more than one place then I would put them all in a separate folder, since all of those parts are actually doing more or less one thing - manage a specific sub-section of your app's state. This sub-section of your app's state can then be shared by many more than one entry point, which is extremely useful for me. A REAL example: I took the redux-login-saga-flow (https://github.com/sotojuan/saga-login-flow/tree/master/app https://github.com/sotojuan/saga-login-flow/tree/master/app), changed the folder structure so now i can just import the login state management into every entry point i want, and bam - it just works, since all of that state sits under 'login'. I can now create a new webpage and add all of the login complexity in only a few minutes of work . I Hope I was clear (edit: some cleanup and spacing)
  - simonfl3tcher 10y ago
    Yep, we very clear and make a lot of sense. Would tend to agree with everything that you have said.

jjg77 10y ago

How would you hook this up to a node.js back end?

simonfl3tcher 10y ago
Like I outlined in the README. The aim would be to keep it static while calling out to an API. https://github.com/simonfl3tcher/react-progressive-web-app#hosting https://github.com/simonfl3tcher/react-progressive-web-app#h... To be honest, you could hook this up to server-side rendering one way or another. However, I haven't looked at server-side rending too much, and I am not sure what the affect of doing this would be on the TTI. As a result, I cannot say one way or another whether this would be a good idea or not.

Bahamut 10y ago

As far as I can tell, it is the Webpack offline-plugin doing the heavy-lifting - is this correct?

simonfl3tcher 10y ago
I would tend to disagree with that statement. While the webpack offline plugin is creating the service worker which is putting the requests into the cache storage there is a lot more to achieving a good PWA than just a Service Worker. You need to have a manifest.json file which provides all the information for installing your app to your devise. For more information see https://developer.mozilla.org/en-US/docs/Web/Manifest https://developer.mozilla.org/en-US/docs/Web/Manifest. You also need to reduce the Time To Interactivity (TTI) to be under 5,000ms. Webpack is doing a lot of the heavy lifting here by performing tree shaking, vendor chunking and route based chunking. All things that contribute to getting this under 5,000ms. If you would like to know more information as to how to achieve a good PWA, I would urge you to run Lighthouse against the demo which will outline all the things that contribute to a good PWA.
simonfl3tcher 10y ago
This is a great check list if you are looking to create a PWA. https://developers.google.com/web/progressive-web-apps/checklist https://developers.google.com/web/progressive-web-apps/check...

hazza1 10y ago

For most people I'd recommended using the official helper app instead - https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#making-a-progressive-web-app https://github.com/facebookincubator/create-react-app/blob/m... Although, in truth I'd use the much smaller preact library - https://github.com/developit/preact-boilerplate https://github.com/developit/preact-boilerplate

simonfl3tcher 10y ago
This repository is an opinionated repository and comes with a lot more things than the create-react-pwa. i.e. Webpack, Mocha, Flow, Nightwatch, component structure. I agree, if you wanted to start from scratch with your own structure create-react-pwa is probably a better repository for you. However, if you like the opinions formed in this repo then it will allow you to get started straight away with static type checking, e2e testing, unit testing, tree shaking, and code splitting all built in. You raise a good point regarding Preact, it is something that I have considered but decided to stick with React until it became problematic.