Progressive Web Apps
What makes a web app, a Progressive Web App?
“Progressive Web Apps provide an installable, app-like experience on desktop and mobile that are built and delivered directly via the web. They’re web apps that are fast and reliable. And most importantly, they’re web apps that work in any browser.” - Google Codelabs
Progressive Web Apps have specific attributes:
- Fast - it should load visible content to the page quickly, as quickly as if you were opening a native app on your device.
- Reliable - it shouldn’t vary in load time or responsiveness.
- Responsive - it should work on both mobile and desktop platforms with a single codebase (so if you’re considering building a native application, you should strongly consider building a PWA instead).
- Installable - a user should have the option to install the app, without using an app store, and have the same user experience as an installed app, regardless of network connection.
Common Error When Calling Dispatch Actions in Redux
I recently met with a senior developer and we got on the topic of calling dispatch actions in Redux.
He said that, even for developers with more experience, it’s a frequent mistake to forget to call a dispatch action correctly by appending this.props to the function call. So simple, but apparently he sees it actually happen pretty often.
So, instead of a correct call like this inside a container (or ‘smart’) component:
this.props.getFetchedData()
Your call will look like this:
getFetchedData()
The way you’ll know that you’ve made this mistake is when it appears that your dispatch action just doesn’t execute ( possibly without any generated error). If you console.log() at different points inside your function, you’ll see that the action function will be called and will execute, but it stops executing at the line that contains the dispatch .
I’ve had this happen to me without any error to give me a hint at my mistake. It simply stopped executing when it hit the dispatch() . It was strange.
Remember that when you mapDispatchToProps() , or use the connect() helper function from react-redux, you’ve made your dispatch actions available as props, and therefore have to call them appropriately. Otherwise, you’re calling it as just a function, because you imported it into your component.
So hopefully if you understand why it happens, you’ll be more likely to remember the fix if (or when, apparently) it happens to you.
Here are some additional reading resources on the subject:
- Implementing Container Components (Redux.js.org)
- How to get simple dispatch from this.props using connect w/ Redux? (Stackoverflow)
- Connect: Dispatching Actions with mapDispatchToProps (React-Redux.js.org)
The Geolocation API
The Geolocation API allows the user to provide their location to an application if they wish to. The Geolocation API is provided through the navigator.geolocation object. If the navigator.geolocation object exists, then Geolocation services are available. Here’s a simple example to test if geolocation services are available, provided by MDN:
if ("geolocation" in navigator) {
/* geolocation is available */
} else {
/* geolocation IS NOT available */
}
BEM Naming Convention
BEM stands for Block, Element, Modifier. The BEM methodology is to use a standard naming convention when naming classes in HTML and CSS. It was created to make the relationship between your HTML and CSS intuitive and easy to understand. By using this method, as a project gets larger, the ability to apply styles to a project stays manageable.
Imagine a developer that is new to a project codebase. If the class names used utilize some form of standard and semantics, it is easy to read and understand which styles impact which elements. It would be much easier to update, add or change styles without having to worry about possible random impacts in other areas of the project. It would also be much easier to apply those same styles to other blocks or elements in the project. Following the BEM naming convention is an easy way to do this, and most developers won’t need any additional introduction to the project code before jumping in.
Here’s an explanation of each component:
Block
- Consider this the parent element, or a top level abstraction.
How to Handle CORS Error
CORS stands for Cross Origin Resource Sharing. You probably already know about CORS and have very likely run into some issues because of it. Browsers have a security step built in to prevent cross-site request forgery, which is when malicious sites ‘hijack’ a browser’s cookies to access the secure site those cookies belong to.
A simple example would be if you use your username and password to sign into a secure site, like Facebook for instance. After authentication, Facebook would then store a session cookie in your browser. This cookie is how you can navigate from page to page within Facebook and not have to provide your username and password every time you open a new page.
Remember, HTTP is a stateless protocol, which means that the connection between the browser and the server is lost once the transaction ends, so it doesn’t remember that you signed in to Facebook already. The cookies that are stored in your browser are what tell Facebook that you are signed in.
The problem that can happen is when a malicious site gains access to those session cookies and then tries to access Facebook with them (pretending to be you). During a normal request/response interaction between the browser and the server, the browser includes origin information in the server request that includes the protocol, domain and port that are being used during that request. The server then includes this origin information in it’s response to the browser, and the browser checks that the origin information matches.
So where CORS comes into the picture is when the browser detects that the origins of the server and web application don’t match, like when a malicious site is sending a request to the server with your ‘hijacked’ cookies. When this happens, the browser will block the request, issuing a CORS error.
As front end developers, we’re likely to run into CORS errors while develping applications that access web APIs. During development and testing, our browser is sending requests to, and receiving responses from, our local server. But our application is also sending a request to a web API for information that will be used in our application. This triggers the Cross Origin Resource Sharing error.
Here’s how you can get around the issue, during development, and then during production:
During development, you can install a Chrome extension that will allow you to turn off/on CORS security checks in the browser. The name of the extension is Moesif Origins & CORS Changer. This extension has worked for me, allowing me to test my application without any CORS errors. It’s also safe, since I am in control of turning it on and off as needed (just remember to turn it off when you don’t need it!)
Now, while this works great during development and testing, on my machine, it’s not going to work in production bacause users of your application probably don’t have the Moesif extension installed, and even if they did you wouldn’t want to ask them to turn it on! Why should they trust you?
During production, you can use a proxy server to send the requests to your web API. If you were really listening closely ealier, you may have noticed that the CORS issue is concerned with browser-to-server requests/responses. So, if you use a proxy server, you can avoid the CORS issue altogether, because the requests/responses are now server-to-server.
There is a Heroku app that is available to use for this, and it worked well for me. It’s https://cors-anywhere.herokuapp.com. The way to utilize this method is to prepend the URL in your Fetch (or XMLHttpRequest) call with this proxy url. So, for example, a Fetch API call to:
https://your-web-api.com/info
would be replaced with:
https://cors-anywhere.herokuapp.com/https://your-web-api.com/info
The first time I tried these two methods, I installed the Moesif extension and tried it first (and it worked). Then I turned off the extension and tried the method of prepending the cors-anywhere.herokuapp, which also worked just fine.
An important note about these methods, is that they both essentially turn off CORS checking in the browser, which isn’t safe for all situations, so be mindful. If you need them, there are additional resources out there on how to create your own proxy to use with your application, thus eliminating the need to use the cors-anywhere approach in production.
If you are having CORS errors, I would absolutely recomment reading up on it, how it works, and where to look in your browser console (hint: the Network tab) to see the details of the requests and responses between the browser and server. It’ll help you understand what specifically is causing the browser to block requests and therefore what to ‘google’ to find the answer. And MDN is a good place to start…
