When building components, we mostly start out with a minimal API, as we mostly have a clear initial idea of what the Component should do. But as requirements start to change, our API might start to evolve a long the way too. We start adding more props to cover conditional or special cases etc. Sometimes we use optional props, as in not required, or we might start using flags, as in boolean props or enums, to handle variants. Let's take a closer look at optional props and what effects these can have on our UI representation.
/** | |
* @module FigmaLiveEmbed | |
* @author Davo Galavotti | |
* @version 0.1 | |
* | |
* Based on Youtube code component by Jan Van Boghout | |
*/ | |
import * as React from 'react' | |
import { Frame, FramerEvent, Animatable, PropertyControls, ControlType } from 'framer' |
gcd() { | |
git clone "$1" && cd "$(basename "$1" .git)" | |
} |
alias.a add . | |
alias.aliases config --get-regexp alias | |
alias.bi bisect | |
alias.ci commit -m | |
alias.co checkout | |
alias.colast checkout - | |
alias.db branch -D | |
alias.laf fsck --lost-found | |
alias.last log -1 HEAD | |
alias.nb checkout -b |
[user] | |
name = <ur-name> | |
email = <ur-email> | |
[core] | |
editor = vim -f | |
excludesfile = /Users/<name-of-mac>/.gitignore_global | |
[color] | |
ui = true | |
[alias] | |
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --abbrev-commit |
(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 -
int[][] result; | |
float t, c; | |
float ease(float p) { | |
return 3*p*p - 2*p*p*p; | |
} | |
float ease(float p, float g) { | |
if (p < 0.5) | |
return 0.5 * pow(2*p, g); |
self.addEventListener('install', (e) => { | |
e.waitUntil( | |
caches.open("precache").then((cache) => cache.add("/broken.png")) | |
); | |
}); | |
function isImage(fetchRequest) { | |
return fetchRequest.method === "GET" && fetchRequest.destination === "image"; | |
} |
EDIT: Well this has been linked now so just an FYI this is still TBD. Feel free to comment if you have suggestions for improvements. Also here is an unrolled Twitter thread of a lot of the tips I talk about on here.
I've been doing frontend for a while now and one thing that really gripes me is the interview. I think the breadth of knowledge of a "Frontend Engineer" has been so poorly defined that people really just expected you to know everything. Many companies have made this a hybrid role. The Web is massive and there are many MANY things to know. Some of these things are just facts that you learn and others are things you really have to understand.
Every time I interview, I go over the same stuff. I wanted to create a gist of the TL;DR things that would jog my memory and hopefully yours too.
Lots of these things are real things I've been asked that caught me off guard. It's nice to have something you ca