Kit này ghép nhiều skill/command lại thành một workflow gồm bốn bước chính: setup, initial design system, prototype, và implement. Bước setup hỏi user về tech stack và lưu lại flow để các bước sau không phải hỏi lại.

#1 UI Kit workflow: bốn bước từ setup đến implement

Dispatch #1: UI kit workflow: bốn bước từ setup đến implement

Technical analysis of the Ax TypeScript framework for building LLM-powered agents with DSPy capabilities.

Ax Framework

Ax framework breakdown


![](assets/builder-design-pattern.pdf)

## Problem statement

We want to create complex object without worrying too much about the hows, we could use Factory pattern to abstract away those details and just give us the output, but the drawback is you get a fixed same object everytime. There will be cases where you need to tweak some properties of that object to get the desired result, look no further than the Builder pattern.

## Builder design pattern

Create a Builder of the object you wanna build, e.g. QueryBuilder, ButtonBuilder, etc,...

Add methods that act as steps to gradually build your object, this method must return an instance of the builder itself to allow method chainning (not required but a very distinct feature of this pattern).

Have a method that finalizes and output the actual object, conventionally it's called "build()".

Let's say we to build a Drink object, consider the following example of a DrinkBuilder class:

```ts
class DrinkBuilder implements Builder {
  private drink: Drink;
  private name = "";
  private ingredients = [];

  constructor() {}

  name(n: string) {
    this.name = n;
    return this;
  }

  addIngredient(name: string, ml: number) {
    this.ingredients.push({ name, ml });
    return this;
  }

  // where the actual building happens
  mix() {
    return new Drink(this.name, this.ingredients);
  }
}
```

And then we can use it like this:

```ts
new DrinkBuilder()
  .name("JagerBomb")
  .addIngredient("Jagermeister", 30)
  .addIngredient("Redbull", 120)
  .mix();

new DrinkBuilder()
  .name("JagerGrenade")
  .addIngredient("Jagermeister", 30)
  .addIngredient("Tequila", 30)
  .addIngredient("Vodka", 30)
  .addIngredient("Redbull", 50)
  .mix();
```

Notice how by defining each step as method we (the consumer, one that uses the builder) can easily add/skip/modify certain properties of the object, this would all have been hidden away by the Factory class. And the method chaining helps with the readability too.

## Real life examples

jQuery was one of the early pioneers to adopt this pattern in their APIs, those little `$(something).on("click", func).toggle("class")...` is the Builder pattern in action. In fact, the javascript ecosytem is very fond of this pattern, some other libraries that make use of this are:

- [wretch](https://github.com/elbywan/wretch) - a wrapper for native Fetch API with intuitive syntax
- [zod](https://github.com/colinhacks/zod) - a schema validation library
- [Spotify Nodejs wrapper](https://github.com/thelinmichael/spotify-web-api-node) - A wrapper for Spotify's web api
- and many others...

## Pros & cons

Pros:

- Readablity: each step of the builder communicates clearly what it's doing and what parameters it requires.
- Flexibility: the ability to add X, modify Y, skip Z without modifying the internal logic.

Cons:

- For each object that you wanna build, you will need to create a separate Builder class for it, this can quickly become a problem as the codebase grows.

## Reference

- <https://refactoring.guru/design-patterns/builder>


Builder, one of the creational patterns, allows user to construct complex object step by step while still maintaining flexibility.

Introduce the builder pattern and its use cases


https://www.youtube.com/watch?v=CQuTF-bkOgc
tl;dr

three main categories that most UI libraries fall into
a/ pure: pure css, no javascript/composite styling, what you write is what you get when compile (tailwind, SASS), focus on **how they look**
b/ behavioral: pure javascript for a11y purpose, unstyled (no css at all) components to make them work the same across different browsers (headlessUI, radix, react-aria), in other words - focus on how they work
c/ style system: predefined components that are built upon a layer of pure css (tailwindUI, bootstrap, mantineUI, daisyUI), **opinionated a.k.a they (the library author) will mostly decide how their components look**

The problem with bootstrap
_"Why use Tailwind when you already have Bootstrap?"_

- Tailwind is not another Bootstrap, a `justify-center` class maps exactly to 1 line of css code, you have total control over what is being shipped to the user, whereas a `.btn` class in Bootstrap expands to +50 line of css styles and custom variables, you can customize it but it will not be a joyful experience.

the problem with MUI
-material ui is the hybrid version of (b) and (c) category: it has predefined components that look a certain way, it also has javascript underneath to handle all of its component interaction (datepicker, button, input, etc...) -> it gives you a decent head start but it also limits your ability to go far, once your reach the cap a.k.a "I want my component to look and behave sightly different then the one in example" then you start look for solution, tweaks, hacks, workarounds and find out that it will require a huge effort or even sometimes impossible.

TL;DR when in doubt use tailwind, if you're new to css it'll help you learn css faster, if you already know css it'll help you go faster **and** improve the quality of your component output.

![](assets/202210162154-the-best-of-css-tldr_pasted-image-20221016215600.webp)
![](assets/202210162154-the-best-of-css-tldr_pasted-image-20221016215643.webp)
![](assets/202210162154-the-best-of-css-tldr_pasted-image-20221016215646.webp)


Tailwind is not another Bootstrap, a `justify-center` class maps exactly to 1 line of css code, you have total control over what is being shipped to the user, whereas a `.btn` class in Bootstrap expands to +50 line of css styles and custom variables, you can customize it but it will not be a joyful experience.