- Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
- pathname - The "file/directory" portion of the URL, like
invoices/123
- search - The stuff after
?
in a URL like/assignments?showGrades=1
. - query - A parsed version of search, usually an object but not a standard browser feature.
- hash - The
#
portion of the URL. This is not available to servers inrequest.url
so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things. - state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.
- pathname - The "file/directory" portion of the URL, like
const CANCEL = Symbol(); | |
class CancellationToken { | |
constructor() { | |
this.cancelled = false; | |
} | |
throwIfCancelled() { | |
if (this.isCancelled()) { |
# MIT No Attribution | |
# | |
# Copyright 2022 Ben Kehoe | |
# | |
# Permission is hereby granted, free of charge, to any person obtaining a copy of this | |
# software and associated documentation files (the "Software"), to deal in the Software | |
# without restriction, including without limitation the rights to use, copy, modify, | |
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to | |
# permit persons to whom the Software is furnished to do so. | |
# |
(I'm enjoying doing these raw, barely edited writeups; I hope they're useful to you too)
This is my own writeup on feature flags; for a deep dive I'd recommend something like Martin Fowler's article (https://martinfowler.com/articles/feature-toggles.html).
So. Feature flags. The basic idea that you'll store configuration/values on a database/service somewhere, and by changing those values, you can change the user experience/features for a user on the fly.
Let's say that you're building a new feature, called 'new-button' which changes the color of buttons, which is currently red, to blue. Then you'd change code that looks like this -
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: