If you use server rendering, keep in mind that neither useLayoutEffect nor useEffect can run until the JavaScript is downloaded.
You might see a warning if you try to useLayoutEffect on the server. Here's two common ways to fix it.
If this effect isn't important for first render (i.e. if the UI still looks valid before it runs), then useEffect instead.
function MyComponent() {
TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.
If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)
A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/
The reason to avoid JWTs comes down to a couple different points:
https://twitter.com/snookca/status/1073299331262889984?s=21
Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows.
(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)
So the big deal about css-in-js (cij) is selectors.
This content moved here: https://exploringjs.com/impatient-js/ch_arrays.html#quickref-arrays
| function slugify(string) { | |
| const a = 'àáâäæãåāăąçćčđďèéêëēėęěğǵḧîïíīįìıİłḿñńǹňôöòóœøōõőṕŕřßśšşșťțûüùúūǘůűųẃẍÿýžźż·/_,:;' | |
| const b = 'aaaaaaaaaacccddeeeeeeeegghiiiiiiiilmnnnnoooooooooprrsssssttuuuuuuuuuwxyyzzz------' | |
| const p = new RegExp(a.split('').join('|'), 'g') | |
| return string.toString().toLowerCase() | |
| .replace(/\s+/g, '-') // Replace spaces with - | |
| .replace(p, c => b.charAt(a.indexOf(c))) // Replace special characters | |
| .replace(/&/g, '-and-') // Replace & with 'and' | |
| .replace(/[^\w\-]+/g, '') // Remove all non-word characters |
As a developer, it bothers me when someone sends me a large pdf file compared to the number of pages. Recently, I recieved a 12MB scanned document for just one letter-sized page... so I got to googlin, like I usually do, and found ghostscript!
to learn more abot ghostscript (gs): https://www.ghostscript.com/
What we are interested in, is the gs command line tool, which provides many options for manipulating PDF, but we are interested in compressign those large PDF's into small yet legible documents.
credit goes to this answer on askubuntu forum: https://askubuntu.com/questions/3382/reduce-filesize-of-a-scanned-pdf/3387#3387?newreg=bceddef8bc334e5b88bbfd17a6e7c4f9
(also know as lies and/or alternative facts)
Whether you're developing a web application with native-ish UI, or just a simple modal popup overlay that covers the viewport, when it comes to making things work on iDevices in Mobile Safari, you're in for a decent amount of pain and suffering. Making something "100% height" is not as easy as it seems.
This post is a collection of Mobile Safari's gotchas and quirks on that topic, some with solutions and fixes, some without, in good parts pulled from various sources across the internets, to have it all in one place. Things discussed here apply to iOS8, iOS9 and iOS10.
Screen real estate on smartphones is limited, so Mobile Safari collapses the browser chrome (address bar and optional tab bar at the top, and tool bar at the bottom) when the user scrolls down. When you want to make something span exactly the height of the viewport, or pin something to the bottom of the screen, this can get tricky because the viewport changes size (or
| aws s3 sync s3://oldbucket s3://newbucket --source-region us-west-1 --region us-west-2 |