# Pony Foo Latest articles published on Pony Foo This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Bootstrapping a UI component library DevFeed: [Bootstrapping a UI component library]() Original publisher: [Read original article]() Author: nico@ponyfoo.com (Nicolás Bevacqua) Published: 2021-12-16T14:38:04Z Content type: article Language: en Sources: [Pony Foo]() Topics: [Design system](), [Library](), [ui](), [Development](), [Figma]() Tags: [architecture](), [article](), [component](), [design-system](), [developers](), [development](), [figma](), [ui]() ### AI overview The article explains how a startup built and adopted a UI component library called Ryu. It discusses the library's design tokens and core components, its close alignment with Figma, and how standardization separates design concerns from feature development and business logic. ### Source excerpt Building -- and adopting -- a component library in the context of a vibrant business is no easy feat. Here are a few things we've learned. At a small startup, the timing is never quite right to start a component library. Extremely quick iteration is not usually associated with putting together a standardized set of components and conventions to use across your app, as your components and conventions change all the time in the frenzy of finding product-market fit! Nevertheless, component libraries can be tremendously valuable in separating design concerns from feature development and business logic, eventually leading to faster-than-ever iteration. In this article we'll explore what went into our component library -- we called it Ryu -- and what we left out, the tradeoffs we made along the way, and the vision for its future. Let's go! What does a component library consist of? In essence, our component library consists of colors, sizes, fonts, line heights, and even media breakpoints and z-indices. When building a component library you don't generally come up with these values, but rather you take them from what Design has already fleshed out -- probably in Figma. The role of our component library is to mirror Figma as closely as possible, so that developers need not worry about getting the design aspect of their feature work, and can instead focus on getting business logic and its edge cases right. In this sense, the component library can and should be the bridge that melds together Design, Product, and Engineering, effectively acting as the source of truth for our design system is. To that end, we need an understanding across the organization that, while Design has the last word on how the experience we offer looks and feels, Engineering requires it be standardized into a core set of functionality like inputs, buttons, tooltips, menus, tables, drawers, and anything else the designs require. This distinction essentially buckets design work into two categories: new core co ## React Patterns for Fetching, Storing, and Retrieving Data DevFeed: [React Patterns for Fetching, Storing, and Retrieving Data]() Original publisher: [Read original article]() Author: ryan.glover@cleverbeagle.com (Ryan Glover) Published: 2019-06-03T12:20:42Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [React](), [hooks](), [REST API](), [Remote Procedure Call (RPC)](), [GraphQL]() Tags: [autosave](), [code](), [data](), [graphql](), [hooks](), [react](), [refs](), [rest-api](), [rpc](), [state]() ### AI overview A tutorial on common React patterns for fetching, storing, and retrieving data. It emphasizes using simple approaches such as hooks, lifecycle methods, and local state, while noting that Redux or other architectures may be appropriate in some cases. ### Source excerpt Handling data in React can be treacherous if you don't know your way around. Learn some common patterns for fetching, storing, and retrieving data in this guide to help you avoid messy code traps. React's flexibility means you can handle data in a lot of different ways. This guide will teach you patterns for fetching, storing, and retrieving data in React without the stress of maintaining a complex system. As part of my mentorship business, I have the unique opportunity to work with React daily across a wide range of projects. Teaching others how to build their own software products, I've come to find that most problems in React can be solved with some very simple techniques. While some cases may call for a full-blown architecture using something like Redux (or other fanciness), a lot of the time React's built-in lifecycle methods and local state do the trick. In my opinion, the mark of a really great developer is one who can solve a problem with as few moving parts as possible. While it can feel great to build a monument to engineering in the form of a complex system, often it's just overkill. In this tutorial, I'm going to share what I call my "data survival kit:" the most common patterns and hacks I use in my day-to-day work for managing data. By the time you finish, you'll have everything you need to build data-driven UIs that offer a polished user experience. Loading Data via Hooks As most folks are building "database apps," loading data is arguably one of the most common tasks to perform. Ultimately, where your data is coming from dictates your need for this. This pattern is best utilized in apps using a REST API or an RPC (remote procedure call) to fetch data. For example, if you're loading data via GraphQL, it's likely that you'll use this technique sparingly (e.g., when you need to fetch data programmatically as opposed to on page load), relying on tools like Apollo to load your data for you. import React, { useEffect, useState } from 'react'; function Post ## Discovering patterns with React hooks DevFeed: [Discovering patterns with React hooks]() Original publisher: [Read original article]() Author: m@peka.la (Maciek Pekala) Published: 2019-05-13T12:15:55Z Content type: article Language: en Sources: [Pony Foo]() Topics: [React Hooks](), [React](), [hooks](), [ui]() Tags: [best-practices](), [coding](), [components](), [hooks](), [patterns](), [react](), [react-hooks]() ### AI overview An exploration of patterns that emerge when building stateful React components with hooks. The article introduces the author's Choco pattern, which combines Context, a Hook, and a Component for top-level, centralized, unique UI widgets that expose functionality to other application components. ### Source excerpt One of the things I enjoy the most about coding is discovering patterns. Being aware and mindful of the patterns emerging in your codebase can make it easier to keep that codebase consistent, readable and easy to navigate. Most patterns will remain unspoken, and some, that prove notably elegant, are named and promoted as best practices. Others might even be candidates for a basis of a new abstraction, although I recommend restraint as it's worth remembering that abstractions are expensive. If you're not familiar with the topic or React hooks, there is plenty of introductory as well as in-depth materials out there. I can also shamelessly recommend my talk on hooks from a recent React Copenhagen meetup. What follows assume at least some understanding of what hooks are and how to use them. Pattern extinction level event Discovering new patterns is relatively rare when working with established technologies, but every now and then a new idea comes up that stirs things up within some ecosystem. Enter React hooks. Hooks enable a drastically different way to build stateful components in React, which means that they also invalidate 1 a lot of the established patterns. However, being an exceptionally well thought-through and composition-friendly abstraction, hooks enabled new, elegant patterns to emerge. Over the last few months, I've been building apps with hooks and I've been having a lot of fun discovering these patterns. I'd like to share one, that I've grown especially fond of. For the lack of a better name, and for sole the purpose of this blog post, let's call it the Choco pattern (from Context, HOok, COpomonent). The pattern comes useful when you need a UI widget which is top-level, centralised and unique across the application and needs to expose some functionality to the rest of the components in the app. It might sound vague at the moment, so let's try to go through solving a concrete problem where I noticed the Choco pattern manifest itself. Exhibit A: Feature tog ## Disguise Driven Testing: Jest Mocks In Depth -- Part 2 DevFeed: [Disguise Driven Testing: Jest Mocks In Depth -- Part 2]() Original publisher: [Read original article]() Author: jsmapr1@gmail.com (Joe Morgan) Published: 2019-04-22T09:26:23Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [Testing](), [Jest](), [Mocking](), [Code](), [App]() Tags: [code](), [data](), [function](), [jest](), [mocking](), [testing]() ### AI overview This tutorial explains how Jest mocks can isolate external data, side effects, impurities, and third-party dependencies so tests remain consistent and predictable. It demonstrates testing an employee-creation function whose default fields can be overridden while its generated key is treated as incidental. ### Source excerpt Mocks are a great way of preventing AJAX calls in tests, but they can also help you isolate side effects and impurities that can create complicated tests. As you learned in Part 1, mocks are a great way to handle external data or any data that is likely to change. Mocking external data will likely be your most common use case and for a good reason. You want your tests to stick as closely to your code as possible this includes all dependencies. Still, there are times when a dependency creates a testing specific problem. In other words, the code works as you would want it to in production, but in a testing environment can make consistent, predictable tests hard or nearly impossible. Some of your third party code may have side effects or some form of impurity that will complicate your testing. Maybe the code has certain expectations of the DOM. Maybe it will change slightly depending on the order of operations. In all cases, the code is out of your control, but you need it to be predictable. Creating Predictable Outcomes with Mocks Suppose you have an application that manages employees or users. You need to make a simple function that will create a new employee, but you want to make sure that the employee always contains certain fields and will have a unique id. Your code will look something like this: import uniqueId from 'lodash/uniqueId' export function createEmployee(details) { return { name: '', position: '', ...details, key: uniqueId() } } In this case, you are using the Lodash method uniqueId to, well, create a unique ID. Specifically you are creating a key that you can use if you do any manipulations on an array of employees. The key, though, is a minor thing. For the most part, your tests should focus on other aspects of your code such as ensuring default fields while allowing those fields to override. Here are two simple tests. import { createEmployee, } from './utils' describe('createEmployee', () => { it('should create a blank employee', () => { const blank ## Conflict Resolution and Code Reviews DevFeed: [Conflict Resolution and Code Reviews]() Original publisher: [Read original article]() Author: nico@ponyfoo.com (Nicolás Bevacqua) Published: 2019-04-10T10:00:46Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [Code review](), [Pull Request](), [Git](), [Code]() Tags: [checkout](), [code-review](), [code-reviews](), [git](), [git-commit](), [github](), [tips]() ### AI overview A tutorial on reviewing conflict resolution in large Git pull requests. It shows how to recreate the merge with conflict markers locally so reviewers can isolate and inspect the changes made to resolve conflicts, while ignoring unrelated branch changes. ### Source excerpt Have you ever tried to do a code review on a PR that merges a large release branch or feature branch back into mainline, fixing merge conflicts? It's not pretty. The diffs are often and easily very big, -- 50k+ LOC big -- have hundreds of commits, and the actual changes made by the engineer resolving the merge conflicts are virtually impossible to spot. This article covers one nifty trick I've been using lately in these cases that lets you review exactly the conflict resolution, while ignoring the mountains of changes that don't represent any conflicts (and can thus be safely ignored). Check out the PR locally If you haven't done this before, you can just add the author's remote (provided they're using a fork, otherwise you can skip this step) like so: $ git remote add nico https://github.com/nico/repo.git Then we can fetch the PR branch, let's assume it's called fix-merge-conflicts and it was merging branch-with-conflicts into master, fixing the conflicts along the way: $ git fetch nico fix-merge-conflicts $ git checkout fix-merge-conflicts Assess the situation The git log should indicate they've merged a couple branches. The commit hashes are the key bits here. $ git log -1 HEAD commit a9c9ed7gcc0a76670d86df4b732f1f219ccb48de (HEAD -> fix-merge-conflicts) Merge: aecf730802 ba9918dad5 Author: Bloodninja Date: Mon Apr 8 12:32:38 2019 +0000 Merge remote-tracking branch 'branch-with-conflicts' And now we can verify that these indeed belong to each of the branches we care about: $ git branch --contains=aecf730802 master * fix-merge-conflicts $ git branch --contains=ba9918dad5 branch-with-conflicts * fix-merge-conflicts Now for the magic git checkout -b what-were-they-thinking git reset --hard aecf730802 git merge --no-ff ba9918dad5 # this will conflict git add . git commit -m WIP At this point, what-were-they-thinking is the version of the conflict resolution where you just committed things exactly as git merge left them, conflict markers and all. ## Disguise-Driven Testing: Jest Mocks in Depth DevFeed: [Disguise-Driven Testing: Jest Mocks in Depth]() Original publisher: [Read original article]() Author: jsmapr1@gmail.com (Joe Morgan) Published: 2019-03-28T03:18:25Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [Jest](), [Testing](), [Code](), [API](), [Development]() Tags: [api](), [code](), [dependencies](), [external](), [fetch](), [jest](), [json](), [test](), [testing](), [tool]() ### AI overview This tutorial explains why impure functions and external dependencies make testing difficult, using date calculations and API data fetching as examples. It presents Jest mocks as a way to replace function results and simplify tests. ### Source excerpt Testing can be simple. In fact, it is simple. Well, it is simple until impurities slip in. Code that would be easy to test becomes a nightmare as soon as you get impure data (like date checks) or complex external dependencies (such as DOM manipulations or large 3rd party libraries). The part that tends to frustrate developers most is when they have code that's easy to read, easy to write, but difficult to test. No one wants to spend more time on their tests than they do on their code. Consider an example. Let's say you needed to write some code that checks to see if a given date is two weeks from today. If they date is far enough away, you get an empty string. If the date is less than two weeks away, you get an error message: import moment from 'moment'; export const message = 'Date must be two weeks from now' export function isAtLeastTwoWeeks(date) { const isLater = moment(date).isAfter(moment().add(2, 'weeks')); return isLater ? '' : message; } That's pretty simple code. But how do you write a test for it? Things can get tricky fast. Here's an even more basic example. You want to fetch some data from an API and display the first couple items: export function getRecent() { return fetch('/albums') .then(response => response.json()) .then(albums => { return albums .reverse() .slice(0, 2) .map(({title}) => title); }) } Simple to read. Simple to understand. But how would you test it without hitting the live API? There's an unfortunate belief that testing is hard. Early in my career, I heard one developer estimate that it doubled development time. And he was arguing for testing, that it was worth the extra time. The problem is that most testing is easy. But testing impure functions can be very, very difficult. Fortunately, the Jest testing framework has simplified a lot of the complexities behind testing. The secret is a tool called a mock. A mock is effectively a shortened version of a function. Instead of running the function you stub out the result you want. Your cod ## The Action Pattern: Clean, Obvious, Testable Code DevFeed: [The Action Pattern: Clean, Obvious, Testable Code]() Original publisher: [Read original article]() Author: ryan.glover@cleverbeagle.com (Ryan Glover) Published: 2019-03-26T12:02:06Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [Code](), [Test-driven development](), [Development](), [mock api](), [Mobile]() Tags: [action-pattern](), [api](), [app](), [beginner](), [code](), [javascript](), [patterns](), [tdd]() ### AI overview A tutorial introduces the action pattern for organizing complex JavaScript code. It uses a mock signup API endpoint for a mobile app and emphasizes explicit names, single-purpose functions, modular files, and test-driven development. ### Source excerpt Let's convert a mock API endpoint for signing up new users in a mobile app into using the action pattern. When I first started writing software on the web, my code was a mishmash. Every project was loaded with unnecessarily long files and code left commented, thrown to the side of the road like an abandoned vehicle. The theme of the day was: unpredictability. Under ideal conditions--the happy path--I was able to make my code work. But what I couldn't do was make my code work consistently. One time through my code would work, then the next an anonymous 500 Internal Server Error would send me spiraling for days. I was able to squeak by, but the thought of having to continue answering emails from clients that read "this isn't working..." was a life I didn't want to lead. Taking off my beginner's hat, I started to see what other, more experienced programmers were up to. I'd heard about Bob "Uncle Bob" Martin in passing, eventually discovering his Clean Coders series. I was hooked. For the first time, he was answering questions others on my path hadn't. My primary question? "How do I organize complex code?" As far as questions go that was a ball of yarn, but over several videos he explained the parts I was missing: Using explicit names that can't be mistaken. Breaking your code into functions that do one thing. Using TDD (test-driven development) to guide yout work. Still green, some of this made sense and some of it didn't. The other problem was that Bob's language of choice was Java, not JavaScript. This meant that I was able to grasp what he was saying at a high level, but practically I was still stumped. Several iterations later... Eventually, what Bob taught started to sink in. As I gained experience, I slowly started to organize my code into a pattern (supported by a short list of rules): Any code that involves multiple steps should be moved into its own file/module. That file/module should be given a name that describes what those steps lead up to. Each step in that cod ## React State: Choose Wisely DevFeed: [React State: Choose Wisely]() Original publisher: [Read original article]() Author: jsmapr1@gmail.com (Joe Morgan) Published: 2019-03-19T13:22:59Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [React](), [Redux](), [context](), [Code]() Tags: [component](), [javascript](), [react](), [redux](), [state](), [state-management]() ### AI overview This tutorial compares three approaches to managing state in React: local component state, global state using Redux, and Context. It evaluates them by implementation speed, data encapsulation, and accessibility from other components. ### Source excerpt Proper state handling in React will make your components simple and maintainable. Poor choices will give you lots of headaches in the long-term. There are plenty of options for managing state in a React app. But there's very little guidance about which one you should use in any situation. Let's fix that. The solution you pick to manage state should fit they way you want to use the items you hold in state. Your choice should also make it easy for you to update, reuse, and refactor your code. In other words, your choice of state management can make your life easy or hard. Here's a non-exhaustive list of things you should consider: How quickly can you add new state code? How well encapsulated is your stateful data? How easy is it to pull the data into a new component? Let's use this list as a basis for comparing different ways of handling state. To do this, we'll make the same simple component using three different forms of state handling. By making the same thing three ways, you'll get a few nice perspectives. First, you'll see that any approach can solve any problem. This is important because if you know that you can solve nearly any problem with any form of state management, you can turn your attention from the technical problem of getting it working, to the more abstract problem of making it work well in your over all application. Second, by making the same thing three ways, you'll start to see the subtle differences which can become big headaches as an applications grows. What are the three ways to manage state? Local State: State stored directly on the component. Global State: A global store. In this example, you'll use redux. Context: A newer API that lets you access state higher up the tree. Using the three points of comparison and the three ways of managing state, you'll be able to build a nice table that will let you compare the different options. Local Global Context Easy ? ? ? Encapsulated ? ? ? Available ? ? ? Alright. Let's get started. You'll be making a ## GraphQL in Depth: What, Why, and How DevFeed: [GraphQL in Depth: What, Why, and How]() Original publisher: [Read original article]() Author: ryan.glover@cleverbeagle.com (Ryan Glover) Published: 2019-03-12T12:01:43Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [GraphQL](), [API](), [CRUD](), [Code]() Tags: [api](), [apollo](), [code](), [crud](), [graphql](), [rest](), [tutorial]() ### AI overview An in-depth tutorial introducing GraphQL, explaining how it works, how it compares with REST, and how to use types, queries, mutations, and schemas to build a simple API. ### Source excerpt GraphQL is all the rage, but what exactly is it? In this in-depth walkthrough, we take a look at what GraphQL is, how to use it, and why you should use it. Learn why GraphQL is all the rage! We'll walk through the implementation of a schema for a popcorn company's API, learning about types, queries, and mutations as we go. I love popcorn. As I'm writing this, I'm snacking on a bowl of multi-colored kernels, lightly seasoned with Flavacol (hint: this is the movie theater's secret) and I'm feeling a twinge of hubris in my eye... "I should start a popcorn company..." Well, that's a terrible idea, Ryan! But, for the sake of this tutorial, it's the best idea you've had all week. In this tutorial, we're going to learn how to create a simple, GraphQL-based API for a popcorn company. All we need is a name. Seeing as how I'm quite fond of sarcasm, how about... Sarcastic Kernels: The Popcorn You Love to Hate to Eat™ Perfect! And like any self-respecting nerd, it only seems right to start writing some code before we come up with a sound business plan. To get started, let's wrap our heads around what GraphQL is and how it compares to REST. What is GraphQL? GraphQL is a client-side query language coupled with a pattern -- formally known as a "schema" -- for organizing the creation, reading, updating, and deleting of data in your application (yeah, that CRUD). We say "application", here, and not database because GraphQL is data-source-agnostic, meaning it doesn't care where your data lives. From the outside looking in, GraphQL can seem quite scary. Does the "Graph" part mean I have to learn about graph databases? Does the QL (query language) mean I have to learn I have to learn a brand new programming language?! Not quite. To calm your nerves, the harsh truth is: GraphQL is just a dressed up GET or POST request. Wait, what?! Yep. While GraphQL as a whole does introduce some new concepts for organizing and interacting with your data, behind the curtain, GraphQL still relies on a good ol' ## JavaScript Performance Pitfalls in V8 DevFeed: [JavaScript Performance Pitfalls in V8]() Original publisher: [Read original article]() Author: benedikt.meurer@googlemail.com (Benedikt Meurer) Published: 2019-03-05T16:32:03Z Content type: article Language: en Sources: [Pony Foo]() Topics: [JavaScript](), [V8](), [Compiler](), [Optimization](), [inlining](), [Programming]() Tags: [bytecode](), [compilation](), [compiler](), [function](), [inlining](), [internals](), [javascript](), [optimization](), [performance](), [v8]() ### AI overview This article explains two performance pitfalls in the V8 JavaScript engine. It discusses engine heuristics such as speculative optimization and inline caching, then describes V8's method-based JIT compilation, optimization limits, and inlining. ### Source excerpt In recent years, JavaScript engines have improved on all fronts. The performance of JavaScript has reached a level where it can easily compete with programming languages that have traditionally been considered more appropriate for high-performance computing. This is not only true for V8, the JavaScript engine inside of Chrome and Node.js, but for all major JavaScript engines, including ChakraCore, the engine inside of Edge, JavaScriptCore, the engine inside of Safari, and SpiderMonkey, the engine inside of Firefox. Not only did the peak performance improve, but engines also managed to deliver more consistent and predictable levels of performance. Given that JavaScript is a highly dynamic language, all of this performance is based on choosing the right heuristics in the engine. JavaScript engines use techniques like speculative optimization and inline caching to speed up execution of the likely path. But heuristics can also easily work against you, and it helps to be aware of them. So today I'm gonna share some background on two subtle performance pitfalls in the V8 JavaScript engine. Being aware of these potential pitfalls might help you to resolve issues if you get bitten by these more easily. Optimization limit The compilers built into V8 - both the TurboFan optimizing compiler and the Ignition bytecode generator - are so-called method JITs, meaning the unit of compilation is always a method, aka a function in JavaScript speak. The optimizing compiler is able to include the bodies of other methods when it finds hot call sites and sees potential for further optimizations via doing this, which is commonly referred to as inlining. Contrast this with other runtimes that use so-called tracing JITs - LuaJIT and PyPy are popular examples here - where the unit of optimization is an arbitrary sequence of consecutive bytecodes that have been executed repeatedly previously. In both method JITs as well as tracing JITs, there's always an upper limit on the size of the input th