Julien Goux jgoux

On implementing a client for feature flags in your UI codebase

This document isn't an explainer on Feature Flags, you can find that with my amateur writeup, or literally hundreds of better writeups out there.

This document is also agnostic to the choice of service you'd use: LaunchDarkly or split.io or optimizely or whatever; that's orthogonal to this conversation.

Instead, this document is a list of considerations for implementing a client for using Feature Flags for User Interface development. Service providers usually give a simple fetch and use client and that's it; I contend that there's a lot more to care about. Let's dive in.

To encourage usage, we'd like for the developer experience to be as brutally simple as possible. So, this should be valid usage:

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

	#!/usr/bin/env node
	const path = require('path')
	const generatorHelper = require('@prisma/generator-helper')
	const { Project, StructureKind, VariableDeclarationKind } = require('ts-morph')

	generatorHelper.generatorHandler({
	onManifest(config) {
	return {
	prettyName: 'Filters',
	defaultOutput: path.resolve(__dirname, 'filters'),

	import { multiSortBy } from 'src/shared/utils'

	export type PathNode<T> = {
	id: string
	path: string
	parentId: string
	meta: T
	children?: PathNode<T>[]
	}