mikaelbr

### Keybase proof

I hereby claim:

  * I am mikaelbr on github.
  * I am mikaelb (https://keybase.io/mikaelb) on keybase.
  * I have a public key ASDxC69lniQqB3KAMknf6mi1us1IGvVW5UhrreB7wlE9DAo

To claim this, I am signing this object:

mikaelbr

Bli kvitt implisitt prosjektkunnskap med snevre linting-regler

I tillegg til blomster på første dag, får nye team-tilskudd ofte utdelt fiendtlige footguns. Samme footgun som resten av teamet har: Implisitt prosjektkunnskap. Eller prosjektnormer om du vil. Den kunnskapen de som har vært i kodebasen for alltid bare kjenner på kroppen. Ting du absolutt må unngå å gjøre, men er vanskelig å fange opp og krever alle konstant på alerten. Vi kan være gode på Code Reviews og ha gode rutiner, men all manuell sjekk vil være sårbart. All denne implisitte kunnskapen tilrettelegger for et minefelt. Som i all programmering er eksplisitt kunnskap bedre enn implisitt kunnskap. Ingen kommer på å lese dokumentasjon i tilfelle det kan stå noe relevant, og kommentarer har for liten kontrast i editoren. Vi trenger noe bedre system for a fange opp dette!

Det finnes allerede veldig gode mekanismer for å håndheve implisitte regler i en kodebase, slik det har gjort i et par ti-år: Linting! Statisk analyse av kodebasen og validerin

mikaelbr

{ "superstyles": [
    "American Wild Ale",
    "IPA",
    "New England IPA",
    "Imperial Stout",
    "Strong Ale",
    "Triple IPA",
    "American Pale Ale",
    "Black IPA",
    "Berliner Weisse",

mikaelbr

{
  "ut_bid": "5071040",
  "desc": "Time to take another trip to fourth dimension! Seriously dry hopped with Citra, Strata and Mosaic Lupomax hops. Cheers!",
  "percent": 12,
  "ut_rating": 4.37,
  "name": "Tesseract",
  "brewery": "Salikatt",
  "session": 0,
  "style": "IPA - Quadruple",
  "superstyle": "Quad",

mikaelbr

// in App.tsx
type AlertWithId = {
  message: string;
  type: "info" | "error";
  id: number;
};

// Part 1: The container to hold values
const AlertContext = createContext<AlertWithId[]>([]);
function Content() {

mikaelbr

module.exports = {
  meta: {
    type: 'problem',
    fixable: 'code',

    schema: [
      {
        type: 'object',
        additionalProperties: {
          type: 'string',

mikaelbr

module.exports = {
  meta: {
    type: 'problem',
    fixable: 'code',

    messages: {
      avoidableModuleWithAlternative:
        'Package {{ actualModule }} should be avoided. Use {{ suggestedModule }} instead.',
      avoidableModule: 'Package {{ actualModule }} should be avoided.',
    },

mikaelbr

module.exports = {
  meta: {
    type: 'problem',
    fixable: 'code',

    schema: [
      {
        type: 'object',
        properties: {
          translateFunctionIdentifier: {type: 'string'},

mikaelbr

import {useEffect, useState} from 'react';

/**
 * A specialized useState hook for doing isLoading messages. This delays
 * setting flag as true for `delayTimeInMs`. This is to avoid unnecessary loading indicators.
 *
 * @param {boolean} initialState initial flag, true if loading false otherwise.
 * @param {number} [delayTimeInMs=400] milliseconds to delay before setting flag to true
 * @returns {[boolean, React.Dispatch<React.SetStateAction<boolean>>]} usual useState return
 */

mikaelbr

Proper way to Type React Components

I was slow to embrace TypeScript. Not because I think TypeScript is bad, but more for my love of the dynamism of JavaScript. Surprisingly, I find myself looking back at the past projects and they've all been in TypeScript. I think it might be time to face the truth: I mostly code in TypeScript. But in my React projects, there has always been one thing bothering me: React.FC.

For some reason when I was learning TypeScript and React almost all blog posts, tutorials and examples were using React.FC to type up function components. And