markerikson

// See https://blog.isquaredsoftware.com/presentations/react-redux-ts-intro-2020-12/#/36 for slides
// My basic render function structure:
function RenderLogicExample({
  someBoolean, // 1) Destructure values from `props` object
  someList,
}) {
  // 2) Declare state values
  const [a, setA] = useState(0);
  const [b, setB] = useState(0);

gaearon

function MyResponsiveComponent() {
  const width = useWindowWidth(); // Our custom Hook
  return (
    <p>Window width is {width}</p>
  );
}

antfu

TypeScript  21 hrs 47 mins  ████████████████▒░░░  67.1%
Vue.js       6 hrs 21 mins  ██████▓░░░░░░░░░░░░░  19.6%
JSON         2 hrs 10 mins  ████▒░░░░░░░░░░░░░░░   6.7%
JavaScript         46 mins  ███▒░░░░░░░░░░░░░░░░   2.4%

dhh

ruby '2.7.1'

gem 'rails', github: 'rails/rails'
gem 'tzinfo-data', '>= 1.2016.7'  # Don't rely on OSX/Linux timezone data

# Action Text
gem 'actiontext', github: 'basecamp/actiontext', ref: 'okra'
gem 'okra', github: 'basecamp/okra'

# Drivers

iansu

Create New App

JavaScript Template

npx create-react-app@next --scripts-version=@next --template=cra-template@next my-js-app

TypeScript Template

npx create-react-app@next --scripts-version=@next --template=typescript@next my-ts-app

getify

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

gatsbyjs-employees

To the Gatsby Community,

We want to start by specifically thanking Nat Alison. We support her and commend her bravery in speaking out. It is not easy to stand alone. What she experienced at Gatsby was unacceptable and speaks to wider issues. We thank her for putting pressure on the company to fix them. We vow to double down on those efforts.

While we have worked hard to give feedback and help create a healthy work environment over the past few years, change has been far too slow and the consequences have been real. The previous weeks have intensified the need for rapid change by increasing employee communication and allowing us to collectively connect some dots. We are just as outraged. As a result, we have posed a series of hard questions to management as well as a list of concrete actions they need to take.

Kyle Mathews' public apologies to both Nat Alison and Kim Crayton are small actions swiftly taken that signal the possibility for change but don't speak to the systemic issues that must be addressed.

mxstbr

const en = {
  titles: {
    default: `What's on your mind?`,
    idea: `Share an idea`,
    issue: `Report an issue`,
    other: `Tell us anything!`,
  },
  categories: {
    idea: `Idea`,
    issue: `Issue`,

tannerlinsley

Replacing Create React App with the Next.js CLI

How dare you make a jab at Create React App!?

Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.

Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.

So why

WillMayger

// Script tag to include in <head>:
<script
  type="text/javascript"
  src="//maps.googleapis.com/maps/api/js?key=YOUR_API_KEY_GOES_HERE&language=en&libraries=places"
></script>


import React, { useState, useEffect } from "react"

// Async google places autocomplete function