Steps to deploy a Node.js app to DigitalOcean using PM2, NGINX as a reverse proxy and an SSL from LetsEncrypt
If you use the referal link below, you get $10 free (1 or 2 months) https://m.do.co/c/5424d440c63a
I will be using the root user, but would suggest creating a new user
I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
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() {
All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
| // I'm suggesting we add a new "adopt X from <Y />" syntax to the JSX language | |
| // it would de-sugar to render prop children, but look and read better than | |
| // what we currently have. For example: | |
| // 1. | |
| // this sugar | |
| function MyComponent(props) { | |
| adopt foo from <Bar />; | |
| return <div>{foo}</div>; | |
| } |
Next.js, Nginx with Reverse proxy, SSL certificate
Zach Caceres
Javascript does not have the typical 'private' and 'public' specifiers of more traditional object oriented languages like C# or Java. However, you can achieve the same effect through the clever application of Javascript's function-level scoping. The Revealing Module pattern is a design pattern for Javascript applications that elegantly solves this problem.
The central principle of the Revealing Module pattern is that all functionality and variables should be hidden unless deliberately exposed.
Let's imagine we have a music application where a musicPlayer.js file handles much of our user's experience. We need to access some methods, but shouldn't be able to mess with other methods or variables.
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
| function Pubsub() { | |
| this.events = {}; | |
| } | |
| Pubsub.prototype.publish = function(event, args) { | |
| if (!this.events[event]) { | |
| return false; | |
| } | |
| var subscribers = this.events[event]; |