DEV Community: Jethro Larson

i cant today

Jethro Larson — Thu, 31 Oct 2024 17:37:23 +0000

a bug i posted a fix for
11 months ago
only today released
like bruh, i can't today

i have to fill out forms
and get 4 approvals
on things supposedly critical
like bruh, i can't today

required training due-
on systems i despise
or actually am a master of
like bruh, i can't today

boss says i need skills
but never read my resume
or asked me what i've done
like bruh, i can't today

the nation is in turmoil
and corruption is high
democracy in jeopardy
like bruh, i can't today

TypeScript Tagged Unions are OP

Jethro Larson — Wed, 09 Oct 2024 21:04:08 +0000

Ever struggled with handling multiple object shapes in TypeScript and wished for a more type-safe solution?

If so, you're not alone. Many developers are unaware of the full potential that tagged unions (also known as discriminated unions) offer in TypeScript. This powerful feature can enhance your code's safety, readability, and maintainability. In this article, we'll dive into tagged unions and explore how they can elevate your TypeScript skills.

🏷️ What Are Tagged Unions?

Tagged unions allow you to create types that represent one of several possible shapes, each with a distinguishing property known as the "tag" or "discriminator." This enables TypeScript to narrow down types in conditional checks, ensuring that your code handles all possible cases explicitly.

🤔 Why Should You Care?

Enhanced Type Safety

Tagged unions help catch errors at compile time by ensuring all possible cases are handled. This reduces runtime errors and makes your code more robust.

Clear and Maintainable Code

By explicitly defining the shape of each case, your code becomes more readable and easier to maintain. Future developers (or even future you) will thank you!

Exhaustiveness Checking

TypeScript can warn you if you forget to handle a possible case, ensuring that your code accounts for all scenarios.

📖 Tagged Unions by Example

Consider a scenario where you have different shapes and want to calculate their areas:

// Define interfaces with a discriminant property 'kind'
interface Circle {
  kind: 'circle';
  radius: number;
}

interface Rectangle {
  kind: 'rectangle';
  width: number;
  height: number;
}

interface Triangle {
  kind: 'triangle';
  base: number;
  height: number;
}

// Create a union type of all shapes
type Shape = Circle | Rectangle | Triangle;

// Function to calculate the area based on shape kind
function calculateArea(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      return Math.PI * shape.radius ** 2;

    case 'rectangle':
      return shape.width * shape.height;

    case 'triangle':
      return (shape.base * shape.height) / 2;
}

What's Happening Here?

Discriminant Property (kind): Each interface includes a kind property with a literal type. This property acts as the tag for the union.
Union Type (Shape): Combines all shape interfaces into a single type.
Type Narrowing: Inside the switch statement, TypeScript knows exactly which shape it is dealing with based on the kind property.
Exhaustiveness Checking: The default case with a never type ensures that if a new shape is added but not handled, TypeScript will produce a compile-time error.

🛠️ Example: State Management

Tagged unions are incredibly useful in state management scenarios, such as representing the various states of an asynchronous operation (e.g., data fetching).

interface LoadingState {
  status: 'loading';
}

interface SuccessState {
  status: 'success';
  data: string;
}

interface ErrorState {
  status: 'error';
  error: string;
}

type AppState = LoadingState | SuccessState | ErrorState;

function renderApp(state: AppState) {
  switch (state.status) {
    case 'loading':
      return 'Loading...';
    case 'success':
      return `Data: ${state.data}`;
    case 'error':
      return `Error: ${state.error}`;
    // default case can be omitted because typescript is making sure all cases are covered!
  }
}

🧐 Why Is This Good?

Clear Representation of States: Each interface represents a distinct state of the application, making it easy to understand and manage.
Type Safety with Data Access: When the state is 'success', TypeScript knows that state has a data property. Similarly, when the state is 'error', it knows about the error property. This prevents you from accidentally accessing properties that don't exist in a given state.
Exhaustiveness Checking: If you add a new state (e.g., EmptyState with status: 'empty'), TypeScript will alert you to handle this new case in the renderApp function.
Improved Maintainability: As your application grows, managing different states becomes more manageable. Changes in one part of the code prompt necessary updates elsewhere, reducing bugs.

🎯 Tips for Using Tagged Unions

Consistent Discriminator: Use the same property name (e.g., type, kind, or status) across all types.
Literal Types: Ensure the discriminator property uses literal types ('email', 'sms', etc.) for accurate type narrowing.
Avoid String Enums: Prefer string literal types over enums for discriminators to keep type narrowing straightforward.

👏 Conclusion

Tagged unions are a powerful feature in TypeScript that can help you write safer and more maintainable code. By explicitly handling each possible type, you reduce the chance of unexpected errors and make your code easier to understand.

Give tagged unions a try in your current or next TypeScript project and experience the benefits firsthand!

📚 Further Reading

Streaming ChatGPT API responses with python and JavaScript

Jethro Larson — Tue, 21 Mar 2023 05:36:14 +0000

It took me a while to figure out how to get a python flask server and web client to support streaming OpenAI completions so I figured I'd share.



from flask import Flask, stream_template, request, Response
import openai
from dotenv import load_dotenv
import os

load_dotenv()
# put these values in an .env file parallel to this file
openai.organization = os.environ.get("OPENAI_ORG")
openai.api_key = os.environ.get('OPENAI_API_KEY')
def send_messages(messages):
    return openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=messages,
        stream=True
    )

app = Flask(__name__)

@app.route('/chat', methods=['GET', 'POST'])
def chat():
    if request.method == 'POST':
        messages = request.json['messages']
        def event_stream():
            for line in send_messages(messages=messages):
                print(line)
                text = line.choices[0].delta.get('content', '')
                if len(text): 
                    yield text

        return Response(event_stream(), mimetype='text/event-stream')
    else:
        return stream_template('./chat.html')

if __name__ == '__main__':
    app.run()

chat.html



<!DOCTYPE html>
<html>
  <head>
    <title>Chat</title>
  </head>
  <body>
    <h1>Chat</h1>
    <form id="chat-form">
      <label for="message">Message:</label>
      <input type="text" id="message" name="message">
      <button type="submit">Send</button>
    </form>
    <div id="chat-log"></div>
    <script src="{{ url_for('static', filename='chat.js') }}">
    </script>
  </body>
</html>

You can't use EventSource for this if you want to use POST method, this uses fetch API instead.

chat.js



const form = document.querySelector("#chat-form");
const chatlog = document.querySelector("#chat-log");

form.addEventListener("submit", async (event) => {
  event.preventDefault();

  // Get the user's message from the form
  const message = form.elements.message.value;

  // Send a request to the Flask server with the user's message
  const response = await fetch("/chat", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ messages: [{ role: "user", content: message }] }),
  });

  // Create a new TextDecoder to decode the streamed response text
  const decoder = new TextDecoder();

  // Set up a new ReadableStream to read the response body
  const reader = response.body.getReader();
  let chunks = "";

  // Read the response stream as chunks and append them to the chat log
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    chunks += decoder.decode(value);
    chatlog.innerHTML = chunks;
  }
});

Obviously this is not an optimal chat user experience but it'll get you started.

Creating link tags to locales for SEO in NextJS

Jethro Larson — Thu, 30 Jun 2022 20:58:44 +0000

This wasn't hard but I didn't find good search results for it so here's a quick tip.

I'm using next-translate with nextjs for localization but this technique will probably work with other localization frameworks like next-i18next.

in pages/_app.ts

import Head from 'next/head';
import type { AppProps } from 'next/app';
import {useRouter} from 'next/router';

const supportedLocales = ['ar-ye', 'en-us', 'fr'];

export default function MyApp({ Component, pageProps }: AppProps): ReactElement {
  const {asPath} = useRouter();
  return (
    <>
      <Head>
        {supportedLocales.map(loc =>
          <link rel="alternate" hrefLang={loc} href={`/${loc}${asPath}`}/>)}
      </Head>
      <Component {...pageProps} />
    </>
  );

}

I hope this helps google find your translated pages!

Beautiful Functions: Psi

Jethro Larson — Fri, 07 Jan 2022 20:27:57 +0000

Continuing on with my last post, I want to look at another function which I consider particularly elegant, the psi combinator:

const psi = (f) => (g) => (x, y) => g(f(x), f(y));

In TypeScript:

const psi = <A, B>(f: (x: A) => B) =>
  <C>(g: (x: B, y: B) => C) =>
  (x: A, y: A): C =>
  g(f(x), f(y));

This is also called on in Haskell.

What it does is map a function over both arguments of a binary(two-argument) function. This is similar to the B combinator but changed to work on binary functions.

The quintessential usage is when sorting records:

// given a compare function
const localeCompare = (item1: string, item2: string): number =>
  item1.localeCompare(item2);

// and some accessor function that drills into a data structure
const getName = (person) => person.name;

// compose that accessor with the compare function to drill both sides
const compareNames = psi(getName)(localeCompare);

// which can be passed to a sort method for an array of that structure
people.sort(compareNames)

Interestingly, this is equivalent to doing a map and then sort, but using psi is theoretically more memory efficient:

// generates an extra array
people.map(getName).sort(localeCompare)

Look out for other opportunities to use psi and I'm sure you'll find them. Particularly if you're doing data aggregation or processing.

Pedantic Disclaimer: Psi is usually defined with the binary function as the first argument but I preferred the similarity to B combinator when taking the mapping function as the first.

Beautiful Functions: Compose

Jethro Larson — Thu, 30 Dec 2021 23:15:08 +0000

I'd like to take a look at some functions whose form and function are the epitome of elegant.

The B combinator, sometimes called "compose":

const B = (f) => (g) => (x) => f(g(x))

Which has the type:
(b -> c) → (a -> b) → a → c

in TypeScript:

const B = <A, B, C>(g: (y: B) => C) =>
  (f: (x: A) => B) =>
    (a: A): C =>
      g(f(a));

What it does is combine two unary functions (single-argument functions) together such that the output of the second is the input of the first. This is the core of composing functions in math as well as programming. If you have a couple procedures you want to link and sequence consider using this operator to do so.

const armTheMissiles = (missles: Missle[]): Missle[] => {...}

const fireTheMissles = (missles: Missle[]): void => {...}

const armAndFireMissles = B(fireTheMissles)(armTheMissles)

This is such a core way of writing code that advanced languages like Haskell and F# have operators dedicated to it: . and <<, respectively.

armAndFireMissles = fireTheMissles . armTheMissles

An easy place to integrate this function into your code is in cases where you take a callback that calls a function with it's parameters.

const fetchStuff = () =>
  fetch(...).then(data => parseData(validate(data)))

In this case you can use the B combinator to drop the inner lambda:

const fetchStuff = () =>
  fetch(...).then(B(parseData)(validate))

This way of eliminating lambdas by using composition techniques is called eta-reduction.

It may help to have an idea of what a partially applied B means. I like to think of it as the function has its arms out and is ready for the conga line.

const congaReadyFoo = B(foo);
const congaReadyBar = B(bar);
const congaLine = congaReadyFoo(congaReadyBar(baz));
// where foo, bar, and baz are all unary functions with compatible inputs and outputs.

That all said, it's easy to go too far with this kind of technique.

// probably too far
const congaLine = B(foo)(B(bar)(baz))

This is mainly due to the syntax as when it's an operator it's much easier to follow (haskell):

congaLine = foo . bar . baz

There's many more fun combinators but I wanted to start with one many people may already be familiar with from high school math.

Bonus fact: `B` turns functions themselves into a functor

class Functor f where
  fmap :: (a -> b) -> f a -> f b

instance Functor ((->) r) where
  fmap = (.)

That is, given a function from a -> b, our compose function takes a function which takes something of type a and returns a function which takes something of type b. This means it's totally cool to think of composition as mapping a function over another function.

Git push pitfalls to watch out for

Jethro Larson — Fri, 29 Oct 2021 20:18:13 +0000

Git is powerful but its relatively terse and obtuse api can make it hard to be sure what commands are really doing. Here are a couple pitfalls I've found over the years with git push that it's good to be aware of.

Pushing the wrong thing

You're probably familiar with git push but do you know all the assumptions that calling it without arguments is making?

git push is sugar for git push [default remote] HEAD:[HEAD's upstream branch]. So if your local branch's upstream is set to say 'master' you could accidentally overwrite master.

You can adjust the default behavior for git push by setting the push.default git config

Another trap is git push origin branch_name. It expands to git push origin branch_name:branch_name so if you're not on branch_name and you expect to push your current branch to remote branch_name you may be surprised (ask me how I know!).

Deleting a remote branch on accident

Here's a typo that can burn you hard

DON'T RUN THIS: `git push origin :branch_name'

You may assume that this means push your current branch up as "branch_name" but noooo, it actually will replace the remote branch with nothing, deleting the branch.

The Math of TypeScript's Types

Jethro Larson — Sat, 02 Oct 2021 23:24:47 +0000

I've been studying functional programming for a few years and in doing so I've learned a lot about types that I would not have otherwise. In particular, studying Haskell and related technology begets some interesting concepts. The one I want to talk about this time is "algebraic types".

From wikipedia:

In computer programming, especially functional programming and type theory, an algebraic data type is a kind of composite type, i.e., a type formed by combining other types.

If you've used TypeScript for a bit you've probably been exposed to some of these already.

Sum Types

Let's say we have a short list of commands that an API will support, "list" and "pop". We can use string literal types to represent the valid values:

type ListCommand = 'list'
type PopCommand = 'pop'

Each of these types only have one value--the specific string that is valid. If we want a function that can take either command we can compose these types together using the | operator.

type ValidCommand = ListCommand | PopCommand

const performCommand = (command: ValidCommand) =>

The | type operator creates a sum type of the types to the left and right of it. What you should notice is that the sum adds the potential values together, i.e. ValidCommand accepts ListCommand plus PopCommand. This may be more apparent with bigger types:

type CommandOrFlags = ValidCommand | Flags

You'll remember that Flags had four valid values and ValidCommand has two. Thus CommandOrFlags has six (4 + 2).

So we can add types, can we multiply them too? Yes, indeed!

Product Types

As you may have noticed, you can think of | operator for sum types as "or". Product types are the other half of that, the "and". So then we have to find data structures that represent a type having multiple values simultaneously. Tuple is a great candidate for that since it allows us to have different types at its indices.

type Flags = [boolean, boolean]
const flags: Flags = ?

How many potential values can be assigned to flags?

With this small set we could list them out but we can use what we know about the individual types to figure it out with math.

The type [boolean, boolean] must have exactly two values and those values must be booleans. Booleans themselves have two potential values. If you know that tuples form a product type with the types they contain you just have to multiply 2 x 2 to know that the total inhabitants of the composed type is four.

Another way of encoding product types is to use an object:

type Point = {x: number; y: number}

So in a way you're already using them!

Sum types are a monoid

Monoid is an interesting mathematical structure that is pretty simple.

Composition: Monoid is type with a combine operation that can join to values of the same monoid. a o b = c where a b and c are same type, and o is the operation.
Associativity: The operation must be associative (a o b) o c = a o (b o c)
Unit: operation must have a "unit" value that doesn't change the value it's composed with. a o unit = unit o a = a

As an example Arrays form a monoid where concat is the operation and [] is the unit:

// Composition
[1,2].concat([3,4])
// is same as
[1,2,3,4]

// Associativity
[1,2].concat([3,4]).concat([5,6)
// is the same as
[1,2].concat([3,4].concat([5,6]))

// Unit
[1,2].concat([])
// same as 
[].concat([1, 2])
// same as
[1, 2]

The thing I actually wanted to share is that types themselves form a monoid with | as the operation and never as the unit!

// Composition
type Foo = 1 | 2

// Associativity
type Bar = 1 | (2 | 3)
type Bar = (1 | 2) | 3

// Unit
type Baz = 1 | never
type Baz = never | 1
type Baz = 1

Mathematically there is also a monoid for product types but I haven't found a way to make it work in TypeScript.

Getting more mileage out of sum types in TypeScript

In exploring usage of sum types you may run into some challenge in writing functions that use them:

type Error = string
type Message = string

type Response = Error | Message

const handleResponse = (resp: Response) => {
  // wait. How do I actually have different behavior
  // since both cases are strings at run-time???
}

A trick to make this work is to provide some extra data at runtime so that your code can discriminate between the members of the sum. This is called a discriminated union.

type Error = {kind: 'Error'; message: string}
type Message = {kind: 'Message'; message: string}

type Response = Error | Message

const handleResponse = (resp: Response): string => {
  switch(resp.kind){
    case 'Error': {
      console.error(resp.message)
      return 'Fail'
    }
    case 'Message':
      return resp.message
  }
}

Switch is used here as poor man's pattern matching. TypeScript has good support for this technique and will make sure you have your cases covered if you leave off the default case.

You can even have empty types to union with states that have no other data:

type Error = {kind: 'Error'; message: string}
type Message = {kind: 'Message'; message: string}
type Pending = {kind: 'Pending'}

type Response = Error | Message | Pending

const handleResponse = (resp: Response): string => {
  switch (resp.kind) {
    case 'Error': {
      console.error(resp.message)
      return 'Fail'
    }
    case 'Message':
      return resp.message
  }
  // TS ERROR: Function lacks ending return statement and return type does not include 'undefined'.ts(2366)
}

Then to fix it you can just handle the case:

const handleResponse = (resp: Response): string => {
  switch (resp.kind) {
    case 'Error': {
      console.error(resp.message)
      return 'Fail'
    }
    case 'Message':
      return resp.message
    case 'Pending':
      return 'Pending'
  }
}

That's all for now. I hope this gives you new things to think about and you get a chance to use Sum types to better model your applications.

Edit note: I'd like to give a special thanks to @Phantz for the extra knowledge they dropped in the comments!

5 tips for creating dysfunctional teams

Jethro Larson — Thu, 09 Sep 2021 22:08:49 +0000

There are so many blog articles showing how to make teams more effective but what if you need your team or organization to go belly-up or grind productivity to a halt? This guide will give you concrete strategies for making sure that success is a distant memory.

1. Find the Weakest Links

Whenever something goes wrong make sure that one individual receives a majority of the blame. That person should be one of the individual contributors. While it may seem more effective to blame a manager for the mistakes of their team as that could cause loss of faith in management, the effect of dragging a worker through the coals will be more widespread. Quickly workers will learn that mistakes aren't learning opportunities but career-destroying disasters that they must protect themselves from at all costs. Workers also learn that their managers don't have their back when mistakes happen no worry there.

Within a couple sprints everyone will be covering their asses, and spending a lot of time making sure everyone knows how careful and productive they are. They'll also jump at the smallest provocation to disclaim responsibility for any minor infraction and will sabotage each other to avoid the Eye of Sauron.

2. Make Strong Commitments

One of the best ways to harm a team long term is to develop a crunch-culture and the best way to do that is to make time-bound promises to stakeholders before work has even begun. Commit to public demos at industry conferences, set drop-dead dates that really mean something. Make plans that fully utilize all your available funding so that the only way that the team even partially succeeds is by everything going impossibly perfect or by working hellacious overtime.

When the team starts getting progress back into green make sure to set "stretch goals" that affect management bonuses to keep that heat cranked.

3. Reward the Heroes

This one is unintuitive but works really well. You may think that people that are super-smart and working crazy hours to bail the team out of near-miss disasters are your worst enemy, but remember that your goal is to prevent sustained engineering. Lavish praise and bonuses on these champions and everyone else will realize that success doesn't come from sustainable practices but from letting things fall apart and clawing a janky success from the jaws of defeat.

4. Make the Data Work for You

Even though data-driven decision-making is a hallmark of effective organizations, all you have to do to flip this around is massage the data a little. You'll find with very little effort that with careful analysis and omission you can justify any claim or project you want to. To pull this off however you need to hoard your data and only give others the graphs that you curate. An alternative approach is cast doubt on any existing metrics you don't like. When your audience is confused that's the perfect place to insert your opinion. Then everyone in the room will fight over whose opinion is right and your job is done.

5. Make the Workplace Competitive

This approach is easy to defend as being based on Charles Darwin's natural selection. Take your workforce and separate it into as many small groups as you can, and make the org tree really deep. Then have have competition reign at every level. ICs should compete with each other for fixed bonuses and promotions. Managers should compete with each other for headcount and be paid relative to the number of people working for them so they're encouraged to scale their teams massively. Project managers have to fight for schedule time and development resources for every project. Make sure that everyone learns that the best way to succeed is to take the biggest slice of the pie.

Functional React State Management with FunState and TypeScript

Jethro Larson — Fri, 23 Jul 2021 20:47:54 +0000

React 16.8 gave us hooks, a concise way of organizing our components and separating complexity from our functional components. With hooks like useState we could consider eschewing state management solutions entirely. However, trying to useState on medium to large applications has quite a few challenges:

Using many useState calls bloat components and causes an explosion of variables to manage as each call creates value and setter functions. This in-turn bloats child components as you have to add properties for all the related values and setters.
Code with useState can be difficult to write unit tests for.
It can be hard to refactor logic out of complex components(essentially requires custom hooks which are themselves hard to unit test.)
No convenient way of dealing with immutable nested data (other than the JS spread operator)
useReducer adds its own complexity and while simpler than redux, it introduces actions and reducers which then have to be managed in their own ways.
Making useState enclose a complex state object can solve some of the problems but makes it harder to write child components that are only operating on a subset of the bigger state nodes.

Another State-Management Library Appears!

FunState is a new state-management solution that leverages the convenience of useState with an api that allows for fractal, testable, and composable components.

Refactoring to Fun

Let's start with a small component using vanilla React to show how you'd convert to using fun-state:

export const Counter: FC<{
  value: number,
  onChange: (x: number) => unknown
} = (props) => {
  const onCountChange: ChangeEventHandler<HTMLInputElement> = (e) => {
    const val = parseInt(e.currentTarget.value, 10);
    if (isFinite(val)) {
      props.onChange(val);
    }
  };
  const onUp = () => props.onChange(inc);
  const onDown = () => props.onChange(dec);
  return (
    <div>
      <input value={value} onChange={onCountChange} />
      <button onClick={onUp}>up</button>
      <button onClick={onDown}>down</button>
    </div>
  );
};

// Usage in an App
const App: FC = () => {
  const [counterValue, setCounterValue] = useState(0);
  return (
    <div>
      <Counter
        value={counterValue}
        onChange={setCounterValue} />
    </div>
  );
};

Here we can swap out useState for useFunState

import {FC, useState} from 'react';
import useFunState from '@fun-land/use-fun-state';
import {FunState} from '@fun-land/fun-state';

export const Counter: FC<{state: FunState<number>>}> = ({state}) => {
  const value = state.get();
  const onCountChange: ChangeEventHandler<HTMLInputElement> = (e) => {
    const val = parseInt(e.currentTarget.value, 10);
    if (isFinite(val)) state.set(val);
  };
  const onUp = () => state.mod(inc);
  const onDown = () => state.mod(dec);
  return (
    <div>
      <input value={value} onChange={onCountChange} />
      <button onClick={onUp}>up</button>
      <button onClick={onDown}>down</button>
    </div>
  );
};

const App: FC = () => {
  const counterState = useFunState(0);
  return (
    <div>
      <Counter
        state={counterState} />
    </div>
  );
};

You may reasonably be thinking, "How is this better?" Let's explore how this code changes over time.

What if we want to have an array of counters?

Thankfully we don't have to change the implementation of Counter in either approach.

Vanilla:

const App: FC = () => {
  const [counters, setCounter] = useState([0, 1, 2, 3, 4]);
  return (
    <div>
      {counters.map((counter, i) => (
        <Counter
          value={counter}
          onChange={(val) => setCounter( counters.map((c, j) => i === j ? val : c))} />
    </div>
  );
};

FunState

import {index} from '@fun-land/accessor';

const App: FC = () => {
  const countersState = useFunState([0, 1, 2, 3, 4]);
  return (
    <div>
      {countersState.get().map((_, i) => (
        <Counter state={countersState.focus(index(i))} />
      )}
    </div>
  );
};

The magic here is that since Counter expects a FunState<number> instance, we just need to focus on one. index is an Accessor that can point to a specific item in an array, so no custom state handling required. We're just connecting wires.

Unit Testing

One of the useful properties of components using FunState is that since the state is first-class it can be passed in. FunState also provides a library-agnostic FunState constructor, mockState, to ease unit testing.

import {render, fireEvent} from '@testing-library/react';
import {mockState} from '@fun-land/fun-state'

describe('Counter', () => {
  it('increments state when up button pressed', () => {
    const counterState = mockState(0);
    const comp = render(<Counter state={counterState} />);
    fireEvent.click(comp.getByText('up'));
    expect(counterState.get()).toBe(1);
  });
});

No magic mocks or spies required!

Another neat trick is to extract functions from the body of your components to keep cyclomatic complexity under control.

For example let's extract onCountChange:


const onCountChange = (state: FunState<number>): ChangeEventHandler<HTMLInputElement> = (e) => {
    const val = parseInt(e.currentTarget.value, 10);
    if (isFinite(val)) state.set(val);
  };

Then in the component you can just partially apply the state:

...
<input value={value} onChange={onCountChange(state)} />

Then you can test the handler directly if you like:

describe('onCountChange', () => {
  it('updates the state if a valid integer is passed', () => {
    const counterState = mockState(0);
    onCountChange(counterState)({currentTarget: {value: 12}} as ChangeEvent)
    expect(counterState.get()).toEqual(12);
  });
});

What's great about FunState

Rather than adding indirection of actions and reducers just set the state in event handlers without shame
Focus into the state and pass subsets of it to functions or child components.
Write unit tests easily with provided mockState.
Good type-safety with typescript so the compiler can ensure that everything is copacetic
First-class state makes refactoring easier.
Integrate into existing React 16.8+ application without having to change anything else.
Also works with React Native
Tree-shakable so you only bundle what you use.

This is just the tip of the iceberg and I plan to go more in-depth on future articles. Give a ❤️ if you'd like to see more!

A Case for snake_case

Jethro Larson — Thu, 10 Dec 2020 20:01:07 +0000

The common naming convention in many languages I've used over the years has been camelCase. I've come to expect it and find other forms ugly or impractical. However, I only recently thought critically about it. It turns out there was a better alternative the whole time that works for more people in more places in more cases.

Let's start with the downsides of snake_case:

Looks blocky
Increases width of multi-word names
Uses more characters
Can be ambiguous when to capitalize letters

But the upsides are a bit more compelling IMO:

Easy to read by everyone, not just programmers. Related Study
Words can be capitalized based on their domain rather than to separate them. e.g. is_HTML_valid
Valid identifier in every practical programming language I'm aware of (unlike spit-case)
Doesn't cause problems when variable name needs to be put in case-insensitive contexts like urls or file names

The only reasons I can think of to not switch my style completely to snake_case are the divergence from standard styles of my language communities and the associated linters.

I'm willing to bet that the RustLang community had similar thoughts and that's why they took snake as the standard. Good on them!

Mapping out your Projects

Jethro Larson — Thu, 27 Aug 2020 03:10:53 +0000

I've been kicking around in my head the basic way I do project management for non-software stuff and I think it has some interesting applications in software development.

I usually start with some kind of todo list but rarely is that sufficient for mapping out the work of non-trivial projects. I think that's because work very often has dependencies and order of completion isn't merely driven by anyone's opinion-based priorities. To encode the concrete dependencies I've started building little flow-charts to capture what things need to be done, their status and in what order.
Here's an example from my treehouse project:

This particular chart has been really useful because I have a small workforce (my kids and some of their friends) and I need to give them concrete things to do that are within their skills.

Working alone, I can just reevaluate what the next step is myself and that works a lot of the time but I've found it hard to list off all the remaining tasks that are unblocked on the job site. I share the chart with the kids and they can just pick up anything green, or if they can't decipher it I can break things down as needed.

I think this kind of diagram is good for answering these questions:

What can be done now?
What is in progress?
What is blocking progress towards completion? (e.g. do we need to buy materials or complete dependent tasks)
What has been completed?
What are our next major goals and what do we have to do to achieve them?

It doesn't show time spent, complexity, HR allocation, or estimation. However I can look at it and see that potentially half a dozen people can work on the project simultaneously without conflict. I can also use this graph to create a disposable work list for the day and I have to wonder is that really a better model than a persistent work list (kanban or scrum board). I can see what blockers can be prioritized to maximize utilization or work toward specific milestones.

Give this exercise a shot the next time you have a non-trivial project and I'd love to hear how it goes.