quannt

Resources:

• https://www.w3.org/TR/WCAG21/
• https://webaim.org/
• https://www.apple.com/accessibility/
• https://a11y-101.com/
• https://www.microsoft.com/design/inclusive/
• https://marcysutton.github.io/gatsby-a11y-workshop/

Tools:

• https://www.npmjs.com/package/eslint-plugin-jsx-a11y

paulnguyen-mn

Bí kíp cho buổi phỏng vấn ReactJS thành công 🎉

AGENGA:

1. Một vài lưu ý chung
2. Ôn tập kiến thức JS/ReactJS
3. Cày thuật toán, giải thuật
4. Tìm hiểu về công ty mà mình xin ứng tuyển

bradtraversy

Node.js Deployment

Steps to deploy a Node.js app to DigitalOcean using PM2, NGINX as a reverse proxy and an SSL from LetsEncrypt

1. Sign up for Digital Ocean

If you use the referal link below, you get $10 free (1 or 2 months) https://m.do.co/c/5424d440c63a

2. Create a droplet and log in via ssh

I will be using the root user, but would suggest creating a new user

sebmarkbage

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

sebmarkbage

The Rules of React

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.

What Functions Are "Pure"?

A number of methods in React are assumed to be "pure".

On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.

cdiggins

React Best practices

I have summarized and compiled a list of React.JS best practices from various sources across the internet.

From the React docs

• https://reactjs.org/docs/components-and-props.html

  • props must be readonly

• https://reactjs.org/docs/state-and-lifecycle.html

mikeal

const r2 = require('r2')

let doJsonThing = async (path, propname) => {
  let res = await r2(`http://api.com${path}`).json
  return res[propname]
}

addyosmani

Some quick thoughts on https://twitter.com/dan_abramov/status/884892244817346560. It's not ignorant at all to ask how browser vendors approach performance. On the V8 side we've discussed bytecode precompilation challenges a few times this year. Here's my recollection of where we stand on the idea:

JavaScript engines like V8 have to work on multiple architectures. Every version of V8 is different. The architectures we target are different. A precompiled bytecode solution would require a system (e.g the server or a CDN) to generate bytecode builds for every target architecture, every version of V8 supported and every version of the JavaScript libraries or bundles bytecode is being generated for. This is because we would need to make sure every user accessing a page using that bytecode can still get the final JS successfully executed.

Consider that if a cross-browser solution to this problem was desired, the above would need to be applied to JavaScriptCore, SpiderMonkey and Chakra as well. It would need to ca

addyosmani

Problem: How can we preprocess JavaScript (at build-time or on the server-side) so engines like V8 don't have to spend as much time in Parse? This is a topic that involves generating either bytecode or a bytecode-like-abstraction that an engine would need to accept. For folks that don't know, modern web apps typically spend a lot longer in Parsing & Compiling JS than you may think.

• Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
• One angle to this problem is we all ship too much JavaScript. That's one perspective. We could also look at preprocessing.
• We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
• 1. Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu

vlucas

import { createCipheriv, createDecipheriv, randomBytes } from "crypto";

const ENCRYPTION_KEY: string = process.env.ENCRYPTION_KEY || ""; // Must be 256 bits (32 characters)
const IV_LENGTH: number = 16; // For AES, this is always 16

/**
 * Will generate valid encryption keys for use
 * Not used in the code below, but generate one and store it in ENV for your own purposes
 */
export function keyGen() {