DEV Community: Niki

The silent promise that will kill your Node.js server

Niki — Fri, 23 Jan 2026 06:35:01 +0000

You've got a production server. It's been running fine for hours. Then suddenly it crashes. No warning, no graceful degradation. Just dead.

The culprit? A single line of code that looks completely innocent:

saveMessageToDatabase(stream);

The Setup

You're building a chat API. When a user sends a message, you want to stream the response back immediately while saving it to the database in the background. Classic fire-and-forget pattern:

async function handleChat(request) {
  try {
    const stream = await callAI(request);

    // Fire and forget - don't wait for this
    saveMessageToDatabase(stream);

    return stream;
  } catch (error) {
    console.error('Failed:', error);
  }
}

Looks fine. What could go wrong?

The Kill Shot

Three hours later, the AI provider has a hiccup. The stream connection drops mid-transfer. saveMessageToDatabase throws an error.

Your server is dead.

"PM2/Docker/Kubernetes will restart it!" Sure — and you've still lost every in-flight request, any unsaved state, and your users just saw an error. Prevention beats recovery.

Why try-catch Didn't Save You

try-catch only catches errors from awaited promises:

// ❌ This try-catch is useless
try {
  saveMessageToDatabase(stream); // Returns immediately
} catch (error) {
  // Never reached
}

Without await, the function returns a Promise and exits the try block successfully. The actual error happens later, asynchronously, after the try-catch is long gone.

When that Promise eventually rejects with no handler attached, Node.js sees an "unhandled rejection" and, depending on your Node version, terminates the process.

The Fix

One character. Well, a few:

saveMessageToDatabase(stream).catch(() => {});

That's it. By attaching .catch(), you tell Node "I know this might fail, and I'm handling it." The callback can be empty if you're logging inside the function. You just need to mark the Promise as "handled."

The Pattern

For any fire-and-forget async operation:

// Always attach .catch() to floating promises
doSomethingAsync().catch(() => {});

// Or log the error if you want visibility
doSomethingAsync().catch(err => {
  console.error('Background task failed:', err);
});

The Lesson

try-catch and async/await are not magic. They follow specific rules:

try-catch only catches synchronous throws and awaited rejections
A Promise without await or .catch() is a ticking time bomb
"Fire and forget" still needs a .catch() — you're forgetting the result, not the error

Your server will thank you.

My go-to patterns for full-stack/frontend projects

Niki — Thu, 15 Jan 2026 11:50:06 +0000

After working on quite a few frontend and full-stack projects (mostly React + TypeScript + some flavour of server/backend), I kept coming back to the same handful of patterns. They bring structure, reduce mental overhead, and make the codebase feel maintainable even as it grows.

These aren't revolutionary, but they're pragmatic choices that have worked well across different apps. Here's the current set I reach for almost every time.

1. React Query + Query Key Factory pattern

I end up using TanStack Query (React Query) in nearly every project. To keep query keys consistent, readable, and refactor-friendly, I follow the query key factory approach.

Centralised factories make keys predictable and give great auto-completion:

// lib/query-keys.ts
export const bookingKeys = {
  all: ['bookings'] as const,
  detail: (id: string) => [...bookingKeys.all, id] as const,
  upcoming: (filters: { patientId?: string; page: number }) => [
    ...bookingKeys.all,
    'upcoming',
    filters,
  ] as const,
};

Then in components:

useQuery({
  queryKey: bookingKeys.detail(bookingId),
  queryFn: () => getBooking(bookingId),
});

The same factory file becomes the single source of truth for invalidations too. You can define an invalidation map and trigger queryClient.invalidateQueries() calls from one place:

// Same file or a companion invalidations.ts
export const invalidateOnBookingChange = (queryClient: QueryClient) => {
  queryClient.invalidateQueries({ queryKey: bookingKeys.all });
  // Or more granular:
  // queryClient.invalidateQueries({ queryKey: bookingKeys.upcoming(...) });
};

Having invalidations centralised means you can easily track and manage data freshness across different parts of the app (dashboard, lists, details pages) without hunting through components or mutations. One change here ripples everywhere consistently.

2. Server Actions / Server Functions

I almost never write traditional API routes anymore. Instead, I use whatever flavour of server actions / functions the framework provides:

These are still essentially API-like endpoints under the hood—they can be called directly (e.g., via fetch or form POST), so you must protect them with authentication, rate limiting, CSRF tokens (where applicable), and input validation just like any API.

The big wins come from less boilerplate and more purpose-driven code:

Direct function calls from client → no manual endpoint definitions
Automatic type safety between client and server
Easier error handling and revalidation
Colocated logic (form → action → DB → response)
Better integration with React's Suspense and transitions

It's not magic, it just removes ceremony while keeping security responsibilities intact.

3. Permission / Authorisation Management with CASL

Most apps end up needing fine-grained permissions. I centralise that logic with CASL.

Define abilities once (often user/session-based):

import { AbilityBuilder, createMongoAbility } from '@casl/ability';

export const defineAbilitiesFor = (user: User | null) => {
  const { can, cannot, build } = new AbilityBuilder(createMongoAbility);

  if (user?.role === 'admin') {
    can('manage', 'all');
  } else if (user) {
    can('read', 'Booking', { patientId: user.id });
    can('create', 'Booking');
    can('update', 'Booking', { patientId: user.id });
    cannot('delete', 'Booking'); // explicit deny example
  }

  return build();
};

Then use in services with simple conditionals:

class BookingService {
  static async updateBooking(user: User, bookingId: string, data: Partial<Booking>) {
    const ability = defineAbilitiesFor(user);

    const booking = await getBookingDetails(bookingId); // from queries
    if (!ability.can('update', booking)) {
      throw new Error('Not authorized to update this booking');
    }

    // Proceed with update...
    await updateBooking(bookingId, data);
  }
}

Or inline:

if (ability.can('read', subject('Booking', { ownerId: user.id }))) {
  // show sensitive data
}

Keeps permission logic declarative, testable, and out of business-flow code.

4. Lightweight Repository / Query pattern

I keep a queries/ folder with plain async functions that are pure DB statements and nothing else:

// queries/bookings.ts
export async function getBookingDetails(id: string): Promise<Booking | null> {
  // Drizzle/Prisma/etc. query only
  return db.select().from(bookings).where(eq(bookings.id, id)).limit(1);
}

export async function updateBooking(id: string, data: Partial<Booking>): Promise<void> {
  // Pure update, no side effects
  await db.update(bookings).set(data).where(eq(bookings.id, id));
}

Strict rules for these functions:

Only data access (i.e. SELECT, INSERT, UPDATE, DELETE)
No business logic
No authorisation checks
No emails, queues, external calls, or side effects
Reusable from any service

This thin Data Access Layer makes swapping ORMs trivial (change only queries/ files) and keeps services focused on orchestration.

5. Optimistic Initial Data in React Query

Pass SSR/SSG-fetched data as initialData to avoid loading flashes:

useQuery({
  queryKey: bookingKeys.upcoming({ page: 1 }),
  queryFn: () => actions.bookings.getUpcomingBookings({ page: 1 }),
  initialData: page === 1 ? initialUpcoming : undefined,
});

SSR is non-negotiable today. The era of plain Create React App SPAs is over. Even the React team officially deprecated CRA for new apps in early 2025 and recommends frameworks instead. Modern file-based routing frameworks (Next.js, Tanstack Start, Astro, etc.) all have SSR/SSG built in. Leveraging that initial data improves perceived performance, reduces layout shifts, and gives users something meaningful on first paint. Why throw it away?

6. Container / Presentational aka Smart / Dumb Components pattern

I still like this classic separation:

Presentational (dumb): only props, no hooks/state/fetching → pure UI, very easy to unit test and reason about
Container (smart): handles data, state, orchestration, passes props down

Example:

// Presentational – great for snapshot/visual testing
function BookingListView({ bookings, isLoading, page, totalPages, onPageChange }) {
  if (isLoading) return <Skeleton />;
  return (
    <>
      <ul>{bookings.map(b => <BookingItem key={b.id} booking={b} />)}</ul>
      <Pagination page={page} total={totalPages} onChange={onPageChange} />
    </>
  );
}

// Container
function BookingList() {
  const { bookings, isLoading, page, setPage, totalPages } = useBookings();
  return <BookingListView {...{ bookings, isLoading, page, totalPages, onPageChange: setPage }} />;
}

The dumb components become trivial to test in isolation, since it requires no mocking data layers or auth.

7. Custom Hook pattern

Any time you see a component growing fat with state + data fetching + pagination + error handling → extract it to a custom hook.

Before: 50+ lines of useQuery/useState/session logic inside the component.

After:

function PatientDashboard({ initialUpcoming, initialPast, initialNext }) {
  const {
    upcoming,
    past,
    nextAppointment,
    isLoadingUpcoming,
    upcomingPage,
    setUpcomingPage,
    // ...
  } = useDashboard({ initialUpcoming, initialPast, initialNext });

  return (
    <div className="space-y-8">
      <NextAppointmentCard booking={nextAppointment} isLoading={isLoadingNextAppointment} />
      <BookingList bookings={upcoming.data} page={upcomingPage} onPageChange={setUpcomingPage} />
      {/* ... */}
    </div>
  );
}

The rule: If you see useState, useEffect, useQuery (or similar) clustered together for one clear purpose → extract to a custom hook.

Components stay focused on rendering.

8. Strategy pattern (e.g. for third-party providers)

When you might switch providers (Zoom → Google Meet → others), hide the implementation behind a unified interface.

// services/meeting.ts
class MeetingService {
  static async createMeeting(input: CreateMeetingInput) {
    // strategy selected by config / env
    return activeMeetingProvider.create(input);
  }
}

Keeps services clean and future-proof.

Wrapping Up

These patterns show up in almost every project I work on now. Together they deliver:

Readable, well-organised code
Fewer weird logic bugs (everything has its place)
Lower maintenance cost (easier tests, fewer surprises)
Faster feature development (less time fighting structure)

And most importantly, when everything follows clear conventions (and you document them in a single ARCHITECTURE.md or similar) AI tools like Cursor or Copilot suddenly become much more accurate. They "get" the patterns right away and generate code that actually fits, without you prompting it 10 more times to put it all in the right folders, in the right format.

All the classic engineering benefits, without overcomplicating things.

I am an AI Engineer

Niki — Mon, 20 Oct 2025 20:14:41 +0000

Over the past year, I've completed five projects for medium and large established companies. Four were greenfield builds from scratch; the other involved integrating AI features into an existing platform.

I'm fundamentally a software engineer who's deeply curious about AI. I've gravitated here because it's fascinating.

That said, if you need to pin me on the AI spectrum, AI Engineer fits best. The field is still evolving, so titles are a bit of a mess. I mean, we're still debating software engineering titles after decades!

In this post, I thought I'd tell you more about what I actually do day-to-day and what I believe makes me an AI Engineer.

Why "AI Engineer"?

While looking for gigs, I’ve seen a LOT of job titles. They're like a startup's org chart - fluid and confusing. Here's some that I saw and what job descriptions and requirements they had:

Machine Learning Engineer: Heavy on deploying ML models at scale, often with a focus on production pipelines (e.g., using Kubernetes for model serving). It's more ops-intensive.
Data Scientist: This is a classic data role. They dive into data analysis, hypothesis testing, and storytelling with stats. They might build prototypes in Jupyter notebooks and prepare a presentation about findings, but they're not usually wiring it all into a full app.
Data Engineer: The pipeline maestro. They build ETL processes, manage data lakes on AWS S3 or GCP BigQuery, and ensure data flows cleanly.
Deep Learning Engineer: Specialised in neural nets, often researching architectures like transformers or GANs. Think tweaking layers in PyTorch for cutting-edge performance.
AI Solutions Architect: Basically a Solutions Architect (or DevOps?) that knows how to work with AI-specific tools. They design high-level systems, advise on cloud setups (e.g., Azure AI vs. Google Vertex), and align tech with business goals. Less coding, more diagramming and cloud infrastructure setup.
Research Engineer: Academia-adjacent, pushing boundaries with papers. They invent new algorithms, not integrate them into products.
Algorithm Engineer: I've seen this pop up too: focused on optimising core math, like efficient sorting for AI inference.

The AI space is still nascent, so overlap is huge, and for some roles the title and description were completely different from what I have here.

For me, AI Engineer screams hands-on builder. I'm not theorising in a lab or handling streams of petabytes of data, but rather I'm crafting end-to-end solutions that work in the real world.

What does an AI Engineer actually do?

At my core, I'm solving software engineering problems in an AI context. I take AI capabilities (like pre-trained models from Azure AI Foundry or OpenRouter) and make them work in production.

Here's a breakdown of my toolkit and typical tasks:

1. Model setup and tweaking

On every project I had to choose a foundation model (e.g., OpenAI GPT-5, XAI Grok-4, Gemini-2.5 from Google AI, or Google Vertex).

So far I never had to fine-tune a model for a production-ready project; most things were resolved via different prompting or extra context. I did fine-tune once in a hackathon we had at Sainsbury’s, and if I had to do it for a project, I would just use standard platform-provided tools.

For example, Azure has a guide on techniques, fine-tuning data formats, and tools it has to improve general LLMs. This would be my starting point.

Another important and frequent task I found myself doing is testing and experimenting with prompts, handling token limits, and just making sure it behaves more or less deterministically.

“Deterministic” as in “trying to control” or “predict” what the output will be so that we could prep our code/app/ui for this.

Counterintuitive? Yes. But that’s what a lot of companies want, that’s what I’ve seen the most amongst requirements.

2. Integration and infrastructure

LLM calls are just API calls to someone else’s infrastructure. These calls can’t exist on their own; you have to embed them into a framework.

Of course, some LLM- or AI agent-oriented frameworks have a built-in server, like LangGraph server, but not all, and quite often those are raw. I, personally, don’t like using those in production.

So what I did was set up either a FastAPI server, where I could add auth middleware, database integrations, custom routing, or just use existing Next.js or Astro API routes as a back-end to expose AI models or agents, and custom SSE or WebSockets setup to handle real-time responses in the front-end.

With that setup came lots of Docker containers. Lots and lots of Docker images… 😄

3. Frontend and user experience

Why would you do all this infrastructure if no one will be able to interact with it? So we’re putting on a front-end engineer hat and handle all those streaming chat responses token-by-token for that snappy feel with React and TypeScript.

Moreover, LLMs not only generate text but also images. And they accept images and docs. So I spent a lot of time debugging multimodal issues, figuring out why an LLM rejects an image, converting it to base64, and sending it correctly via REST API.

And then doing the same vice versa.

Also, lots of parsing and formatting tasks, because LLMs don’t like HTML. So if you scraped a page and want to feed it into an LLM, then you better convert it to markdown.

Same goes for tables. LLMs don’t understand tables. Transforming them to an LLM-appropriate markdown or JSON is what I did.

4. End-to-end problem solving

Just like any software project, there’s a lot more to handle end-to-end, like observability and monitoring with tools like Azure Insights, Sentry, LangSmith; ensuring low latency; adding guardrails and AI configs so that AI doesn’t say anything inappropriate; API rate limiting; error handling (do you send an error as a chat message or show a toast with an error message?); handling secrets (because we’re not inexperienced vibe coders who push secrets to public repos, are we?)…

Essentially, all of the classical software engineering, I’d say. Just with a bit of AI twist. 🤷

What I’m not touching

I'm not touching the "data territory" much. If you need me to:

Scour datasets, clean outliers with Pandas,
Train from scratch on SageMaker,
Evaluate with metrics like ROC-AUC or Weights & Biases dashboards,
Iterate on hyperparameters...

...I can do it (I know the theory from self-study and curiosity). But that's veering into Data Scientist/Engineer land, and if you’re not doing PoC you better find someone who’s better at this.

My sweet spot is software issues. Things like:

Debugging why a model inference fails in production.
Optimising API endpoints for 100ms response times.
Ensuring cross-browser compatibility for AI-generated content.
Scaling from prototype to handling 10k concurrent users.
Integrating with legacy systems (e.g., bridging AI outputs to a monolithic Java backend).

I’m a blue-collar worker of the AI World

In essence, as an AI Engineer, I'm the bridge between fancy AI models and real apps. I handle the coding, setup, and fixes to make everything work smoothly in production. From my five projects with different companies, I've learned this role is all about practical building, not data crunching or research.

No PhD needed. Just strong coding skills and a love for getting AI into users' hands.

Understanding the Agentic Commerce Protocol: your guide to selling on ChatGPT

Niki — Mon, 06 Oct 2025 09:13:12 +0000

The e-commerce world just got a major upgrade with the launch of ChatGPT’s Instant Checkout, powered by the Agentic Commerce Protocol (ACP). If you haven’t checked it out yet, go to agenticcommerce.dev to see what it is. As a software engineer with zero experience in ACP let me tell you how I understand it (in simple terms).

Because I know that starting tomorrow, companies will start posting job listings asking for “5+ years of ACP experience”. So, let’s figure out what it takes to get shops selling on ChatGPT.

The Easy Way In: Etsy and Shopify Merchants

If you run your shop on Etsy or Shopify, you’ve hit the jackpot. These platforms are already integrated with ChatGPT’s Instant Checkout. No extra coding, no fuss. Your products are automatically eligible to appear when users search for stuff like “large t-shirt under $40.” OpenAI has done the heavy lifting, so Etsy and Shopify merchants are live (or rolling out soon) with zero setup. Lucky you!

For Everyone Else: Here’s the Work

If you aren’t on Etsy or Shopify, integrating with ChatGPT requires some effort. Don’t worry - it’s manageable, especially if you’ve built e-commerce APIs before. The process boils down to four steps:

Registering
Pushing products
Setting up checkout endpoints
Capturing payments

Let’s walk through it.

Step 0: Register as a Merchant

First, you need to get your shop approved by OpenAI. Head to chatgpt.com/merchants and fill out the merchant application form. It’s straightforward - provide details about the business, primary product categories, and whether you’re setting up a product feed or checkout integration. OpenAI reviews submissions on a rolling basis (expect 1-2 weeks). This step ensures only vetted merchants join the ecosystem, keeping things secure and trustworthy.

Step 1: Push Products to ChatGPT’s Collection

Once approved, you need to make ChatGPT aware of your products. This isn’t a public web search. ChatGPT uses a curated registry of approved ACP implementers to ensure compliance, accuracy, and trust. You’ll provide a product feed in a structured JSON format, either via an endpoint (e.g., /products/feed) or a file, following OpenAI’s Product Feed Spec.

Here’s what goes in the feed:

Product details: ID, name, description, price, images.
Variants: Size, color, etc. (e.g., “large blue t-shirt”).
Availability: Stock status, shipping options.

You can update the feed every 15 minutes to reflect price changes or stock levels or whatever. Right now, product rankings are organic, based purely on relevance to the user’s query (e.g., “large t-shirt under $40”). No paid promotions yet, but I bet OpenAI will add that soon. Capitalism always finds a way!

Step 2: Set Up Checkout Endpoints with ACP

When a user finds a product in ChatGPT and clicks “Buy,” the magic happens through the Agentic Commerce Protocol. Think of ACP as a standardized API with predictable inputs and outputs that any AI agent (like ChatGPT) can understand. It’s like USB-C for commerce - universally agreed-upon formats that make life easier. My iPhone’s Lightning cable still drives me nuts in a USB-C world! But I digress.

Here’s how it works:

Initiate Checkout: ChatGPT sends a POST request to your /checkout_sessions endpoint to start the process. The payload includes buyer info (name, email, maybe address—ChatGPT often pre-fills this to speed things up), items, and shipping details.
Iterate and Update: As the user selects sizes, delivery options, or tweaks the cart, ChatGPT sends more requests to update the session (e.g., POST to /checkout_sessions/{id}).
Complete Purchase: When the user enters payment details (e.g., card or Apple Pay), ChatGPT sends a secure payment token to /checkout_sessions/{id}/complete. You create the order and process the payment.

These endpoints map to your client’s existing backend (e.g., inventory, tax calculations), so you’re just wrapping your current APIs in ACP’s format.

Step 3: Capture Payments and Orders

Payments are handled via your existing provider, with Stripe being the easiest (it supports ACP’s Shared Payment Token out of the box). ChatGPT passes a secure token (no raw card data, keeping it PCI-compliant), and you charge it using your usual payment flow. If you’re not on Stripe, you’ll need to align your provider with ACP’s Delegated Payments Spec. Fulfillment (shipping, returns) stays with your existing systems, and you update ChatGPT via webhooks (e.g., “order shipped”).

Why This Matters

ACP makes AI-driven commerce predictable and scalable. Unlike custom APIs that vary by platform, ACP’s standardized endpoints mean your shop can work with ChatGPT today and other AI agents tomorrow. It’s a win for developers like me who love consistency. Plus, you stay in control as the merchant of record, owning the customer relationship without ChatGPT getting in the way.

Getting Started

Here’s the plan if you already want to get your e-shop on ChatGPT:

Apply: Submit the merchant form at chatgpt.com/merchants.
Build Feed: Create a product feed endpoint or file with your client’s product data.
Add Endpoints: Implement ACP’s /checkout_sessions and related endpoints, mapping to your existing APIs.
Test and Launch: Use OpenAI’s sandbox to test, get certified, and go live.

This is just a generic overview guide. Didn't want to get into the weeds too much. But if you have any questions or want some assistance making this work for your shop - get in touch, I'll be happy to help. 🙌

From 60 to 25 hours: practical tips for effective AI-assisted development

Niki — Thu, 15 May 2025 21:06:31 +0000

TL;DR

Cut development time by 60% (from 60 to 25 hours) using AI tools effectively
Choose your tech stack yourself - don't let AI make these decisions
Set up your project structure manually - AI tends to use outdated packages and weird folder structures
Break down tasks into small, specific requests for AI - don't ask it to build entire features at once
Provide relevant documentation snippets to help AI understand framework-specific requirements
Keep context minimal - attach only relevant files, not entire codebases
Start fresh sessions for new features to avoid recurring patterns
Always refactor AI-generated code - it tends to be messy and needs cleanup
Try different AI models to find what works best for you (Claude, Gemini-2.5, etc.)

Bottom line: Use AI to handle tedious tasks while maintaining control over architecture and design decisions

I was doing one of the projects, I was using Copilot and I noticed that I finished this project way faster than I ever finished a similar project in the past. 25 vs 60 hours. AMAZING, no?! 🔥

I was like turbo-charged! I was able to do code as fast as my ADHD mind was thinking about different aspects of it: layout, styling, state management, comms with back-end API, DB schema and relationships, error handling…

All of this I was able to keep in my head AND be productive! Which is usually not the case, and I end up with a bunch of TODO comments and no code (at first).

And then refactoring all that multiple times using a different design pattern!

So this blog post is an instruction on how to make yourself productive with AI copilot/cursor/whatever, instead of fighting with LLM, swearing at it and rejecting all of its work.

You don't need AI to select the stack

Maybe a little bit of DeepSearch.

When starting you should already know what tech stack and patterns you're going to use.

The only reasons you should use AI at the start of the project if you wanna compare frameworks for your particular use case, e.g. zustand vs jotai.

In my case I knew I had to use Astro, because it was a front-end project with only some back-end required. It was perfect.

This was a "live app", i.e. all users needed to be notified of the changes, so obviously I had to use WebSockets for that.

And then data was of predictable shape, had lots of relationships, so it meant SQL, and PostgreSQL in particular. LOVE it! I'm even subscribed to Postgres Weekly! 🐘

I also wanted Drizzle ORM to manage all the migrations and CRUD operations.

I knew that multiple components in React would need to interact with the same state, so I went with effector. It's my favourite because of the sample , you can do some crazy logic with it, e.g.

sample({
    // Watch for submitForm event, when it gets triggered ...
  clock: submitForm,
  // ... take the $userName store's state ...
  source: $userName
  // ... and transform the state (`name`) AND the parameters from the submitForm function (`password`)
  // into parameters that signInFx would accept...
  fn: (name, password) => ({ name, password }),
  // ... and then call the function with signInFx({ name, password })
  target: signInFx,
});

Isn't that awesome?! AND it all lives outside of your UI logic. SO clean!

I could've also gone with nanostores, that Astro is promoting.

And, obviously, shadcn for UI components. Is there any other option?

Ok, I like HeroUI as well.

The rest feel raw or just weird.

To sum up:

Don't let AI choose your tech stack for you.

Init the project

Don't ask AI to do it. It's just gonna do the shit job, use outdated packages, and setup weird-ass folder structure.

Set it up yourself. The way YOU like. The way YOU are used to work.

So I did. Just followed the Astro setup on shadcn basically

npx create-astro@latest astro-app  --template with-tailwindcss --install --add react --git

I needed a dashboard. So I just took blocks from shadcn and adjusted items to just the ones I need.

No AI. You're gonna spend more time explaining AI what you want.

Same with things like Dockerfile . There are templates, you can just copy and tweak it. Do it yourself, it's quicker.

Release the Kraken AI!

Once you have the setup ready, it's time to outsource some work.

The only way I felt productive and content with what AI was giving me, is when I described step by step how I'd do it myself.

So for the form I went

Create a AddItem form React component using Tanstack Form.
It should have 3 inputs: customer (text, required), order number (text, required), vehicle (select field with Van and Truck as options, required)
It should have 2 buttons add (submit) and reset (nullify all the values in all the fields).
onSubmit create a function with empty body. We'll implement it later.

Keep it short

Notice how I didn't let it go further. If I didn't it might've went ahead and created some weird function, and an /api/form route, it would've made all decisions for me.

And I didn't want it to. I wanted it to make it the way I think is right.

So that's one of the key secrets to make AI productive.

Stop Copilot from going. Don't ask it to do the entire project. Just ask it do a component.

Then an endpoint. Then a util function. Then ask it to put it all together. AI is like children. Asking it too many things at once, will make it ignore your important details that you gave it.

It's never OpenAI

For programming, I noticed, I never use any models released by OpenAI.

It's always Claude, either Sonnet 3.5 or 3.7 or, now, Gemini-2.5.

Gemini-2.5 is actually considered the best as of today.

Although GPT-4.1, they said, should be good at coding. And vibing…? Or is that GPT-4.5?

Anyway, switch some models up, see which ones vibe the best with you.

It's all about vibes these days, isn't it?

Help it see what you see

I've noticed that Cursor is doing web search. But Copilot isn't yet. So the model will not know everything, especially if it's new or rarely used.

Like Astro. All models are really shit at Astro. Try asking it create an action with a certain input and output. Any one of them is gonna do such a shit job, that you'd start doubting the rest of its abilities.

Insert snippets from Get Started or Example pages from the docs. This context would really help AI in generating the code that you have in your head and not a random shit from the internet.

Or you can setup MCP for yourself that would do the docs search for you, e.g.

I haven't done that for myself yet tho.

Don't overdo the context

You know how most (?) AI code editors let you attach files for context? This is an awesome feature!

They also let you attach code bases. This is dumb.

Remember, LLMs are like children: you give them too much, they'll forget most of it, you'll get garbage.

Attach only the relevant files for the ask.

Don't let it see all of it. In fact...

Close the session once you done the feature/ask. Let it start over.

That way you don't get it stuck in a recurring shit-generating pattern. Let it be a gold fish with a memory limited to a feature.

Refactor

Once the feature is done, you won't be able to look at it, it's gonna be heinous.

ABR - Always Be Refactoring.

The generated code will be all over the place, it's gonna have weird if/else logic, triple and quadruple ternary operators, repeated code… Complete unreadable mess!

So you need to go through it with a fresh eye, move some functions out, change the logic… Refactor!

Notice your wins

If you don't notice any significant wins when working with AI help, then you're either a) been working with AI for ages now and used to it (not the case today, I'd say) or b) it didn't work for you, fix it.

For me I noticed these wins:

I switched from React provider pattern (I forgot I was using Astro) to state management in "vanilla JS" way in under 2 mins;
I quickly scaffolded a gigantic switch statement for handling events for WebSockets on the server and associated actions it needs to take, e.g. call to DB, filter and map things out, handle errors, etc.;
I created effector stores and events and connected all of them in multiple samples in under 5 mins with minor refactors, a thing I was always dreading to do even considering my admiration for sample ;
I went from using react-use-websocket hook, to using socket.io after realising that islands architecture wouldn't work with the hook, to native implementation of WebSockets, after learning that socket.io has a compatibility issue with my server;
I scaffolded (and later refactored into a decent code) forms with validation and styling with a UI and form libraries of my choice in 5 mins. And I hate doing forms. This is the best win of all.
I then refactored, cleaned and made all of my components, util functions, API endpoints, etc. small, testable, humanly readable, and DRY in less than 10 mins.

Most important win is, I didn't lose myself, the coder, the programmer that likes to write code, create and make shit work.

I just outsourced the annoying and tedious bits that made my job soulless and energy draining.

That's what AI is good for.

Creating a simple RAG in python with AzureOpenAI and LlamaIndex

Niki — Thu, 24 Oct 2024 12:33:53 +0000

During a recent stream, I explored the process of ingesting a PDF using LlamaIndex and AzureOpenAI. This blog post will guide you through the steps to accomplish this task.

The objective was straightforward: answer questions based on information contained in PDF files stored in a folder. Here's the process we'll follow:

Embed the PDF data: Convert PDFs into a format comprehensible for AI
Initialise AzureOpenAI and provide it with the embedded data
Ask a question and analyse the response

While the LlamaIndex documentation provides an excellent guide, I've included some visual aids to enhance clarity.

Setting Up the Environment

First, let's install the necessary packages:

pip install dotenv llama-index llama-index-llms-azure-openai llama-index-embeddings-azure-openai

Note that AzureOpenAI is not included in the llama-index package and must be installed separately.

Configuring AzureOpenAI

Navigate to Azure AI Studio and deploy your chosen model.

Once deployed, configure LlamaIndex to use it with the following settings:

Settings.llm = AzureOpenAI(
    engine="gpt-4o-mini",
    api_key=os.environ.get('AZURE_OPENAI_API_KEY'),
    azure_endpoint=os.environ.get('AZURE_OPENAI_ENDPOINT'),
    api_version="2024-05-01-preview",
)

BUT.

Azure openAI resources unfortunately differ from standard openAI resources as you can't generate embeddings unless you use an embedding model.

This means that we need a separate embedding model for generating embeddings. Let’s do that.

Deploy an embedding model that starts with text-embedding-*, since in this case we're working exclusively with text.

Configure LlamaIndex to use the embedding model:

Settings.embed_model = AzureOpenAIEmbedding(
    model="text-embedding-3-small",
    deployment_name="text-embedding-3-small",
    api_key=os.environ.get('AZURE_OPENAI_API_KEY'),
    azure_endpoint=os.environ.get('AZURE_OPENAI_EMBEDDING_ENDPOINT'),
    api_version='2023-05-15',
)

Implementing the RAG System

With the setup complete, let's load PDFs into the data folder and query the model:

def main():
    documents = SimpleDirectoryReader("data").load_data()
    index = VectorStoreIndex.from_documents(documents)
    query_engine = index.as_query_engine()
    response = query_engine.query("Can we advertise online gambling to under 18 year olds?")
    print(response)

To run the script in our virtual environment:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python ./src/main.py

And we get a response of

No, advertising online gambling to under 18 year olds is not permitted. Marketing communications must not exploit the vulnerabilities of this age group, and any advertisements that feature under-18s or are directed at them are likely to be considered irresponsible and in breach of established rules.

Future Improvements

We can make it better by embedding the data once and storing it in a database like Azure CosmosDB, which is a MongoDB at its core. This means we get rid of repetitive embedding overhead every time we run the script, allowing the LLM to access pre-embedded data directly from the database. I'll cover this in my future posts.

And here is the repo with this and any future code.

How I cut the deployment time of an Astro (Node.js) site on Azure from 1 hour to ~3 mins

Niki — Mon, 23 Sep 2024 13:54:04 +0000

Before:

After:

The way Azure sets it up for you when you go through the steps of deploying a new Azure Web App service is objectively horrible. This is what Azure pushes to your repo:

# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js version
        uses: actions/setup-node@v3
        with:
          node-version: "20.x"

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present

      - name: Zip artifact for deployment
        run: zip release.zip ./* -r

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v4
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: "Production"
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    permissions:
      id-token: write #This is required for requesting the JWT

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v4
        with:
          name: node-app

      - name: Unzip artifact for deployment
        run: unzip release.zip

      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZUREAPPSERVICE_CLIENTID }}
          tenant-id: ${{ secrets.AZUREAPPSERVICE_TENANTID }}
          subscription-id: ${{ secrets.AZUREAPPSERVICE_SUBSCRIPTIONID }}

      - name: "Deploy to Azure Web App"
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: "app-name"
          slot-name: "Production"
          package: .

So what’s happening here is that we

Build the project in GitHub actions
Zip it
Send it to Azure
Unzip it
Run it

The problem is that we’re zipping it together with node_modules folder. So sending it and unzipping it takes a LOT of time. 🤯

I’m not sure why they recommend it this way, but after reading a bunch of poorly worded and outdated Azure guides and some short StackOverflow posts, I’ve figured out the way a Node.js app should be deployed.

Essentially we need to only send the code from GitHub to Azure and build right there. For that you don’t need to do any post-install scripts or anything, Azure App Service does it for you, here are the steps that it goes through as soon as the code reaches the service.

But it doesn’t do that by default, so you need to enable it. You do that by setting the environment variable SCM_DO_BUILD_DURING_DEPLOYMENT to true in Settings > Environment variables in Azure Portal.

Once we’ve done that, we now need to remove the build step from our GitHub Actions workflow and we’re done. Here is how the template looks like now. 👇

# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  prepare:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - uses: actions/checkout@v4

      - name: Zip artifact for deployment
        run: zip release.zip ./* -r

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v4
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: prepare
    environment:
      name: "Production"
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    permissions:
      id-token: write #This is required for requesting the JWT

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v4
        with:
          name: node-app

      - name: Unzip artifact for deployment
        run: unzip release.zip

      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZUREAPPSERVICE_CLIENTID }}
          tenant-id: ${{ secrets.AZUREAPPSERVICE_TENANTID }}
          subscription-id: ${{ secrets.AZUREAPPSERVICE_SUBSCRIPTIONID }}

      - name: "Deploy to Azure Web App"
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: "web-app"
          slot-name: "Production"
          package: .

There are also a few “gotchas” I’ve noticed when deploying to Azure Web App service:

Forget yarn or pnpm. npm only. There is no way you can get those into App Service environment. And if there is, I really don’t think it’s worth the effort. Azure is using Kudu so you better know its ins and outs, I feel like, if you decide to install additional packages there.
HOST=0.0.0.0 PORT=8080 before your start script, which in my (Astro) case was node ./dist/server/entry.mjs . You can’t pick the port. I tried. Didn’t work.
Node version 20.14 is what it’s currently running in Azure as of the moment of writing this post. It was hard to find, they don’t print it in the dropdown when you select the environment when deploying the App Service. I got a few errors because the Node version wasn’t what my app was expecting 🤷‍♂️

And most important tip: upgrade your service to paid. The whole build and deploy process is unbearably slow on a free plan. But, frankly, that’s not an Azure specific issue, that’s most of PaaS nowadays, isn’t it?

Hope that helps! 😎

Astro.js as an alternative to Next.js: pushing the limits

Niki — Wed, 17 Apr 2024 10:02:29 +0000

I’m tired of Next. I want to try something fresh. So I thought this was the time I look into other frameworks. Where would I go? Nuxt? Remix? Nah…

Astro! Let’s test it and see if it can handle modern project requirements.

Here is the repo, follow along!

Why am I doing this?

Next.js is complicated. But some of the best websites out there use a plain, vanilla JS. We don’t need anything fancy to build great products. I mean, we could use a bit of help from a simple (!!) framework that gets out of your way and lets you deliver. And I want to find that framework.
Next.js v13 was a ~~shit~~ shift. In v13 Next.js introduced a mentality shift with RSC on how we develop an app, and since I have to shift my mentality, I’d like to shift it in all possible directions. Open my mind a little bit more than I have to.
Vercel is not your friend. And Next.js is THEIR product. Sooner or later I feel like we’ll be shifting our mentality to adjust to how Vercel wants us to do things. I don’t wish to be locked in like that.
I’m just tired of Next.js. Every company makes me work with Next.js. Always Next. I don’t really mind, but I miss those times when I was talking about Next as a “new framework” that we “should look into adopting”! I and others like me did a very good job. Well done, folks! But now I want to mix things up a bit, time to try something fresh! Again! 😅

So I guess you could say that Next.js is the reason I’m looking into Astro. 😁

Enter Astro.js

I’ve been ignoring it like I do with Remix and Svelte and a bunch of other frameworks. However, I’ve learned that Astro is different, and I’m gonna talk about how it’s different later in the post.

First, I needed to define a set of criteria with which I could judge its usefulness. How do I identify whether I should choose it (or recommend it) for a new project?

So I started thinking and reflecting on all the companies and all the projects I ever I worked with. What was I doing there? What requirements they had in common? What kind of work they were assigning to me?

And so I defined a list of such things, things that I was doing on EVERY job or contract. This is what everyone wanted me to do from tiny startups to humongous enterprises.

Has React & TypeScript: because I’ve rarely seen a company that wants Vue or plain JavaScript. Everyone wants React and it has to be with TypeScript.
Static pages: Fetch content from headless CMS at build time, create the HTML page and host it somewhere on a simple host.
Global state management shared between components without prop drilling: Because there’s always at least a menu of some sort that you need to control from 3 different places.
Custom theme (global): everyone has its own colours, fonts, etc. No hardcoding and repeating/copy+pasting those HEX values all over the CSS files!
Scoped CSS (e.g. .module.css): no one wants to load ALL of the CSS for every page and then use 1/100th of it.
SSR rendered content that needs to be changed or updated from the client (e.g. using @tanstack/query), e.g. you know that sidebar with filters on a page that lists a couple of dozens of products?
User Authentication with multiple hidden pages: we don’t want to need to auth the user only on the client side. Let’s redirect the user on the server, i.e. BEFORE they get to the protected page.
Localisation and internationalisation: I’ve done a bunch of projects that needed two or more languages. I’m doing one now that requires more than eight languages and more than ten geos/territories!
Embedding Google Analytics and other tracking tools: because if it’s a client-facing site we gots to know about our visitors, right?
Design System in a Storybook: every company I joined (and I do mean EVERY) wanted their React components displayed neatly in a Storybook for all kinds of stakeholders to see/play with.
Testing, incl. unit, integration and visual (i.e. snapshot testing).
Server API function (or action) where secret keys can be used.
Incremental Static Regeneration (ISR), for cases when we have hundreds or even thousands of pages.
Deploy to a custom Docker-based environment somewhere to AWS Fargate, because not every company out there wants to use Vercel, Railway, and other “cool” and “hip” platforms.

So I did this silly “Frankenstein” project with those requirements. Let’s talk about the results!

Findings

Astro is EXPLICIT

The main conclusion that I got out of it is that Astro.js is like putting your project on a diet. On a JavaScript diet.

The thing about Astro is that it promotes the ****“reduced JavaScript” approach. That’s a whole other kind of mentality shift than what I initially was hoping for.

So it doesn’t render JavaScript unless you EXPLICITLY tell it to.

“Explicit” is the word I’d associate with Astro. While Next hides a lot of implementation details, Astro does nothing of such a thing and leaves implementation to us, developers.

If you want some interactivity with JavaScript on the front-end - you need to write it, e.g. addListeners in the script tags. Otherwise, Astro ships nothing to the browser.

Before I wasn’t really thinking explicitly much about how much JavaScript is and isn’t used in the browser. Most of the time, I just let frameworks figure this out for me, and only when we were starting to have issues with performance, etc. only then I start looking “under the hood” and optimising.

All in all, I’m happy with this approach. I kinda like it. Cognitively it feels easier to work this way.

This leads to the next point.

React is just a sprinkle on top

Astro allows you to use ALL sorts of UI frameworks. Including React. BUT!

React is a UI library. And Astro is using it as such. RSC is not a thing there (yet?). So if you’re writing a .tsx/ .jsx file, you can be 100% sure it’s going to be rendered, live and work only in the browser.

Yes, you can certainly feed it server-fetched data, so the user doesn’t see the loader for too long. But it still remains a client only component.

For that reason, you can’t really use React ONLY or go too deep component-wise. They’re all end up on the client.

Do you want that? Is that a good thing? It depends on the project.

If you need to render things on the server first, say, for SEO reasons, and make it interactive, then I’d assume you’d need to have a conditional variable, e.g.

const hasBeenChangedByUser = false

return {hasBeenChangedByUser ? <ReactComponent /> : <AstroComponent /> }

And both <AstroComponent /> and <ReactComponent />, in this case, would look very similar. You could do a sharable code though, because Astro still allows rendering .tsx component on the server, it just strips them of all the JavaScript, making them redundant for React purpose but great for layout, etc.

In my experience, there weren’t many cases when we’d had to create something drastic like that, rather a healthy balance of server vs client. So this “React == UI only” approach doesn’t really bother me. I can render what I need on the server inside .astro component, and components that need to be overly interactive, they’re client in any framework anyway, because interactivity == JavaScript.

No providers!

With Astro, we have two types of files: .astro and .tsx. Guess what .astro components can’t have that React just LOVES?

Providers!

Here’s another mentality shift for you. If you were thinking in a providers pattern, you need to snap out of it. You can no longer store your theme in a provider. No more RadixUI or MantineUI for you.

So to have a theme and reusable CSS variables you’d need to go with how Tailwind works. Tailwind doesn’t use providers. It stores all the variables in it’s own config file.

Something like NextUI would work, i.e. a “New Gen” UI framework. It’s Tailwind based AND it works in both .astro and .tsx files. Amazing!

To be frank, my last 4 projects were Tailwind-based. So I don’t see a problem with that. I can live with that choice.

Guess WHAT also generally uses providers?

State managers!

The time has come for the new kind of state managers

We want to store state across Astro and React components. One state, two frameworks. How do you do that?

Framework agnostic state managers!

In its docs, Astro recommends nanostores, but I’ve used effector in the past. And LOVED IT. So I’ve used it for this project as well.

State managers like these are just JavaScript. They don’t care what frameworks they’re used with. They do have wrappers for them, e.g.

import { useUnit } from "effector-react";
// ...
const { text, size } = useUnit({
  text: $text,
  size: $size,
});

but you can do without them.

Have you noticed that in v5 @tanstack/query moved on from using provider pattern for their QueryClient, e.g.

import { QueryClient, QueryClientProvider } from "react-query";

const queryClient = new QueryClient();

function App() {
  return <QueryClientProvider client={queryClient}>...</QueryClientProvider>;
}

to a more function-based approach, e.g.

import { QueryClient, useQuery } from '@tanstack/react-query'

const queryClient = new QueryClient()

function App() {
    const query = useQuery({ ... }, queryClient)
  //...
}

There’s a reason for that, I think. It’s more flexible, more universal, doesn’t lock you into a particular framework. You can fetch data on the server in .astro component, store it in your queryClient and then use it in a React component on the client with useQuery.

Switch React to Vue and you won’t need to touch the state in any way. Amazing refactoring experience, isn’t it? 🤯

Following the providers rant…

i18n

Since there are no providers, we need to somehow communicate the language we’re working with to every component when setting up our localisation. So we do it this way 👇

// In Astro component
---
const lang = getLangFromUrl(Astro.url);
---
return <Modal client:only="react" lang={lang} />

// Then in Modal.tsx
export const Modal = ({ lang }) => {
    const t = useTranslations(lang);

    return (
        <ModalHeader>
           {t("modal.header")}
        </ModalHeader>
    )
}

So the language won’t be coming from a provider, but rather as a prop. And we’ll be getting it from our server .astro pages.

Which, again, to me isn’t a big deal. It’s just different. It works and it still looks nice. We can even define a “parent” interface that we’ll be using for all the prop types, e.g.

interface PropsBase {
    lang: string
}

interface ComponentProp extends PropsBase {
    //...
}

Astro is just like Next but more explicit

I keep coming back to that word.

In a lot of other aspects, Astro is not that different from Next developer experience and mentality-wise. I didn’t even feel pain when switching. I already knew where things would go, where things would come from, how to structure a project, etc.

Astro has its own place for getServerSideProps (or use server); it has an api folder you can create to store some serverless functions in; it runs in node and you can build a Dockerfile for it. and you can throw all your Google Analytics scripts to PARTYTOWN, just like you’d do in Next.

And if you need to set up SSR authentication, you can do that, it’s pretty straightforward. I was able to set up one with Supabase Auth.

So it’s just like Next, but better.

Just a few ‘gotchas’ though…

The “gotchas”

Astro has no runtime. This means no unit tests. This also means no Storybook for your Astro components (although, they’re working on it!)

Can you live with that?

I’d say yes. When it comes to testing, server-rendered components don’t have much interactivity going on anyway, no user clicks, no state changes, etc. So tests might be considered redundant or over-engineer.

And the layout render we can always test in e2e/integration/visual kinds of tests with Cypress or PlayWright.

As for Storybook, well, not everything needs to be in a Storybook. Surely we can find a nice balance.

Astro needs more work

At the moment ISR comes down to cache control/invalidation in SSR pages, not static page regeneration.

There is no per-page building, no ISR. If you rebuild static pages, you rebuild all of them.

The build is fast though, as it was pointed out, Astro certainly can handle 10K+ pages.

Nonetheless, the Astro team is already thinking and working on the build engine. So it will only become better.

Not even more confusing as it was in Next.js case, I hope… 😅

To sum up

Astro is great. But it is slightly different from the way Next.js projects are done and not everyone would be happy to compromise. And that’s ok. We all have our own set of requirements, values, goals, the environment we work in, etc.

However, I think Astro is the future. And I don’t mean Astro framework. I think the Astro way of doing things: explicit, transparent, and minimalistic. This is the future where all the frameworks work as one, and where frameworks don’t overwrite standardised APIs and expose important bits to the developers allowing us to modify and hack it to each project’s own needs.

The future is simple, vanilla JavaScript because simplicity always wins. 🚀

For more talking and less reading, feel free to watch my stream.

Creating an autogrowing textarea with React and Typescript

Niki — Thu, 28 Dec 2023 13:57:58 +0000

In my 6 years career I almost never had to make an autogrowing textarea field like the ones we have in Jira or Linear (i.e. description fields) 👇

But recently, I had to make one. While there are already some posts about this, e.g. THIS post by Owen, I thought I'd post my solution, which covers a slightly different scenario.

So basically, I create a hook

export const useInputHeight = (name: string, value: string | undefined) => {
  const setInputHeight = useCallback(() => {
    const textarea: HTMLTextAreaElement | null = document.querySelector(name);
    if (!textarea) return;
    textarea.style.height = textarea.scrollHeight + "px";
  }, [name]);

  useEffect(() => {
    setInputHeight();
  }, [value, setInputHeight]);

  return setInputHeight;
};

It returns a setInputHeight function that we call in our onChange function.

const setNameInputHeight = useInputHeight('textarea[name="email"]', emailValue);
// ...
const handleInputChange = (e: React.ChangeEvent<HTMLTextAreaElement>) => {
  setInputHeight();
  // ... other functionality
};

Do you need a value argument? No, you don't, but in my case, the value was being updated on the client, so I had to adjust the field height every time it updated without me triggering the onChange event.

If that's not the case, simplify it to be

export const useInputHeight = (name: string) => {
  const setInputHeight = () => {
    const textarea: HTMLTextAreaElement | null = document.querySelector(name);
    if (!textarea) return;
    textarea.style.height = textarea.scrollHeight + "px";
  };

  return setInputHeight;
};

That's all you'd need.

You may have also noticed that I'm not using useRef() and simply doing document.querySelector.

Would ref work? Yes, yes it should. The only reason I was using querySelector was because I was using a UI library and textarea there wasn't allowing a ref prop. So I didn't want to do all those workarounds, querySelector seemed like a great option.

Do feel free to use a ref if you'd like, after all, it IS a more 'React way' of doing things 😁👍

Storybook 7.0 + React.js + TailwindCSS + CSS modules + Typescript setup that #$%& works

Niki — Mon, 20 Feb 2023 22:48:18 +0000

UPDATE: when writing this I have found THIS article, that, coincidentally, was also updated around the same time.

<rant>

Setting up a storybook project should NOT be THAT hard. I mean, everyone uses Storybook, it’s the only viable option out there when working on a design system.

TailwindCSS is at the stage when it’s already gained the momentum. Even large companies are considering it. Practically EVERY front-end dev has already worked with it.

And CSS modules have beed out there for more that 6 years I believe. And even though in JavaScript terms it’s a dinosaur, a legacy, it’s very much not dead and still a top choice for many, including moi.

Not even going to say anything about Typescript and React. If you’re not using TS or never worked with TS today - you’re unemployable. And React is a standard.

Surely there should be an article somewhere on how to set all this up correctly. SURELY?!

</rant>

Well, after 4 hours of googling and trial and error, I finally was able to crack this “OH SO UNUSUAL” tech stack setup. Here is the repo, and let me highlight two points.

Point 1: Webpack 5 builder and framework

Webpack 4 is still the default choice for Storybook, but Storybook has already released support for Webpack 5, so I see no reason why we’d stick to v4. Important note here is that since we’re updating the core property, we should also update the framework

// main.ts
export default {
  framework: '@storybook/react-webpack5',
  core: {
    builder: '@storybook/builder-webpack5',
  },
}

Point 2: Don’t overwrite default Webpack rules, but add more instead

It (unfortunately!) became a habit for whatever reason, that if I need to add some custom loader, I exclude the default rule from the array and re-create it. We shouldn’t do that, because it messes up the Storybook config in a way that it becomes hard to unfuck it.

Because we need to add a PostCSS loader to our .css files, don’t try to re-create css rule with all the css-loader and style-loader etc., but just push that extra rule to the end of that array, and be done with it.

// main.ts
export default {
  ...
  webpackFinal: async config => {
    config.module.rules.push({
      test: /\.css$/,
      use: [
        {
          loader: 'postcss-loader',
          options: {
            postcssOptions: {
              plugins: { tailwindcss: {}, autoprefixer: {} },
            },
          },
        },
      ],
      include: path.resolve(__dirname, '../'),
    })
    return config
  },
  ...
}

That’s pretty much all I wanted to say. Those two points took me a while to understand, so hope your found my post within your first hour of searching. 😅

Understanding front-end data visualization tools ecosystem in 2021 📊📈

Niki — Fri, 05 Feb 2021 17:08:36 +0000

Data is the new oil, and it's still true in 2021. However, to turn data into insights, we need to analyze and visualize.

So, here's the question: how to pick the right tool? 🛠

In this post we're going to go through JavaScript frameworks and libraries that you can use to visualize your data. And I'd like to do a bit more than just list a few frameworks — I'm going to divide the list by the type of data or data visualization because "one size" doesn't fit all. There are different kinds of data, and each needs a specific visualization strategy.

We'll go through...

📈 general-purpose charting libraries
📉 low-level and complex charting libraries
🏁 tables and data grids
⏰ timeline charts & time-based tools
🗺 geospatial and mapping tools
⛅️ word clouds
🌎 3D visualization tools

Also, to help you choose the right tool for your project, I'm going to include a brief summary of each framework, i.e.

💵 whether it's paid or open-source
⭐️ number of stargazers on GitHub, if it's open source
📅 when it was last released (as of today)
🧱 the size of the bundle (unpacked size on npm), and
🔌 whether it's specific for a particular framework (e.g., React) or it can be used in any JavaScript-based project.

I decided to sort the frameworks and libraries by the number of stargazers because it roughly approximates their popularity and community size (but that's debatable).

Also note that you won't find here an extensive list of every data visualization library which can be found on the internet. However, I hope that this post will help you build your own understanding of the ecosystem.

📊 And the icing on the cake: I'll provide links to guides and tutorials on data visualization tools built by the Cube.js team. Cube.js helps to create an API over any database with ease, and it's often used as a very performant backend for analytical data visualizations.

1. General-purpose charting libraries

The first category is probably the most popular. Most data can be visualized with charts: either temporal (when you include time values to the plot, e.g., on the X axis), or non-temporal (when you have only numeric values or labels). Those include bar chart, pie chart, line graph, and similar. And because it's the most used type of charts, there are numerous options to choose from.

Chart.js

💵 OSS / ⭐️ 51.8K / 📅 19 Oct 2020 / 🧱 1.44 MB / 🔌 universal

Simple yet flexible JavaScript charting for designers & developers

The most popular open-source library for building responsive bar, pie, and line charts. I'd say this is the go-to library for most of the projects, as it fits most of the use cases.

📊 See Chart.js Example with Dynamic Dataset to learn how to modify the data being displayed with Chart.js on-the-fly.

Recharts

💵 OSS / ⭐️ 15.6K / 📅 13 Jan 2021 / 🧱 11.2 MB / 🔌 React

A composable charting library built on React components

As per description, "It was built on top of SVG elements with a lightweight dependency on D3 submodules." It's a good choice for React-based projects, because you can use it natively as a component, e.g.

<LineChart width={500} height={300} data={data}>
<XAxis dataKey="name" />
<YAxis />
<CartesianGrid stroke="#eee" strokeDasharray="5 5" />
<Line type="monotone" dataKey="uv" stroke="#8884d8" />
<Line type="monotone" dataKey="pv" stroke="#82ca9d" />
</LineChart>

📊 See React Dashboard: an Ultimate Guide to for a comprehensive all-in-one walkthrough exploring how to build a dashboard with Recharts and connect it to a backend.

Highcharts

💵 Paid & non-commercial licenses / ⭐️ 9.8K / 📅 22 Oct 2020 / 🧱 43.2 MB / 🔌 universal

Highcharts is a JavaScript charting library based on SVG, with fallbacks to VML and canvas for old browsers.

Highcharts is good for large companies whose products rely heavily on data visualization. You can see the code on GitHub, try and use it for non-commercial purposes. And then you can purchase Highcharts license just for Hightcharts or Highcharts plugin for Stocks, Maps, or Gantt if you'd like to use it for commercial purposes. We'll cover those later in this post as well.

📊 See React Highcharts Example with Cube.js for a practical tutorial on creating a dashboard with numerous Highcharts components.

Chartist.js

💵 OSS / ⭐️ 12.4K / 📅 11 Sep 2019 / 🧱 535 KB / 🔌 universal

Chartist.js is the product of a community that was disappointed about the abilities provided by other charting libraries.

This library is not as actively maintained as others, however, it still worths a mention because of its size with no dependencies. Less than a megabyte, wow!

Just like others, it uses SVGs, it's flexible and it has clear separation of concerns, i. e., CSS is in CSS and JS is in JS, which may not fit all projects, considering that a lot of projects are using CSS-in-JS approach, yet it still deserves our attention.

Victory

💵 OSS / ⭐️ 8.6K / 📅 1 Sep 2020 / 🧱 2.81 MB / 🔌 React

An ecosystem of composable React components for building interactive data visualizations.

Built by Formidable Labs, a company behind such tools as urqls and Spectacle. Provides an opinionated, but fully overridable React components to use both in web and mobile (victory-native).

React-vis

💵 OSS / ⭐️ 7.6K / 📅 19 Apr 2019 / 🧱 1.81 MB / 🔌 React

A collection of React components to render common data visualization charts, such as line/area/bar charts, heat maps, scatterplots, contour plots, hexagon heatmaps, pie and donut charts, sunbursts, radar charts, parallel coordinates, and tree maps.

This library is React-friendly, high-level and customisable, expressive and industry-strong, because it is backed by Uber, so chances are you'll get your answers in case you bump into an issue.

amCharts

💵 OSS / ⭐️ 864 / 📅 18 Dec 2020 / 🧱 22.6 MB / 🔌 universal

A go-to library for data visualization. When you don't have time to learn new technologies.

This is not as popular as the rest, however, it's actively maintained and claims to be easy to use. It could be a good choice if you'd like to combine it with other data viz library for geo and timeline data. I'll cover those in Geo and Timeline sections.

📊 See Slack Vibe, the Open Source Analytics for Slack for a story of an analytical tool that uses amCharts to visualize Slack data.

AnyCharts

💵 Paid & non-commercial licenses / ⭐️ 284 / 📅 29 Sep 2020 / 🧱 11.9 MB / 🔌 universal

Interactive JavaScript charts designed to be embedded and integrated into web, desktop, and mobile apps.

This is a paid library with non-commercial license, which could work well for a company who wants to save time and money on charts development, because a lot of charts pre-configured for you, just insert your data. Even such rear charts as Jump Line Chart, Sunburst Chart, or Circular Gauge.

2. Low-level and complex dataviz tools

Here go tools for a more complicated and more advanced way to visualize your data. The main reason to go with this approach is either because none of the simple charts can be used to visualize your data, or you need to have more advanced interactivity on your elements.

This approach requires a more advanced and specific knowledge in the area, e.g., SVG drawing or WebGL. Not everyone has access to such resource, so that's why there are libraries that expose a much simpler API for simple cases.

D3.js

💵 OSS / ⭐️ 95.4K / 📅 22 Jan 2021 / 🧱 1 MB / 🔌 universal

D3 (or D3.js) is a JavaScript library for visualizing data using web standards. D3 helps you bring data to life using SVG, Canvas, and HTML. D3 combines powerful visualization and interaction techniques with a data-driven approach to DOM manipulation, giving you the full capabilities of modern browsers and the freedom to design the right visual interface for your data.

This is probably the most popular low-level data visualization library on the internet. There's a few keys to its popularity: first, its flexibility (many other data visualization tools are based on D3.js, we'll discuss them below); second, it's massive examples gallery which contains literally every visual you can imagine.

📊 See D3 Dashboard Tutorial for a good jump-starting point to learn how to use D3.js with a backend.

<d3-based-tools>

And here are a few D3-based libraries:

Plotly.js

💵 OSS / ⭐️ 12.7K / 📅 21 Dec 2020 / 🧱 60.4 MB / 🔌 universal

Built on top of D3.js and stack.gl, Plotly.js is a high-level, declarative charting library. plotly.js ships with over 40 chart types, including 3D charts, statistical graphs, and SVG maps.

Plotly allows you to combine the best of two words: simple api and power of a D3.js. It's good for quick prototyping as well as complex projects that require complicated graphs and need to be done in a timely manner.

Plotly also has commercial offerings, but that's more in regard to its end-to-end development & deployment platform, Dash Enterprise.

C3.js

💵 OSS / ⭐️ 9K / 📅 8 Aug 2020 / 🧱 1.46 MB / 🔌 universal

D3-based reusable chart library.

Semiotic

💵 OSS / ⭐️ 2.1K / 📅 21 Jan 2021 / 🧱 2.77 MB / 🔌 React

Semiotic is a data visualization framework combining React & D3

Taucharts

💵 OSS / ⭐️ 1.9K / 📅 26 Feb 2020 / 🧱 1.54 MB / 🔌 universal

Taucharts is a data-focused JavaScript charting library based on D3 and designed with passion.

</d3-based-tools>

Apache ECharts

💵 OSS / ⭐️ 44.9K / 📅 16 Jan 2021 / 🧱 36.3 MB / 🔌 universal

A Declarative Framework for Rapid Construction of Web-based Visualizations

Another open source charting library that has enormous pre-defined charts ready to be used. The reason I put it in this category, is because not only it has simple charts, like line and bar graphs, but also more complicated ones, like 3D globe, 3D lines, Scatter GL and others. Checkout their example page and prepare to be amazed.

Raphaël

💵 OSS / ⭐️ 10.8K / 📅 14 Aug 2019 / 🧱 1.11 MB / 🔌 universal

Raphaël is a small JavaScript library that should simplify your work with vector graphics on the web

Raphael is similar in D3.js in a way that it also allows you to draw your own svg graphics in html. E.g.

// Creates canvas 320 × 200 at 10, 50
var paper = Raphael(10, 50, 320, 200);

// Creates circle at x = 50, y = 40, with radius 10
var circle = paper.circle(50, 40, 10);
// Sets the fill attribute of the circle to red (#f00)
circle.attr("fill", "#f00");

// Sets the stroke attribute of the circle to white
circle.attr("stroke", "#fff");

It hasn't been actively maintained and now most of the preference goes to D3.js. Yet it's still relevant and last release wasn't that long ago, so it does deserve a mention in the list.

3. Tables and data grids

Some data is tabular and thus belongs to a table. But tables are more framework-specific, so it's hard to collect data tables for every framework in one post. However, here are a few options.

ag-Grid

💵 OSS & paid / ⭐️ 6.9K / 📅 15 Jan 2021 / 🧱 n/a / 🔌 universal

Advanced Data Grid / Data Table supporting JavaScript / React / AngularJS / Web Components

Or, as it claims on its website, "The Best JavaScript Grid in the World." It's packed with features and has both OSS and Enterprise versions with bindings for vanilla JS, React, Angular, Vue, and even Polymer.

Material UI Data Grid

💵 OSS & paid / ⭐️ 272 / 📅 26 Jan 2021 / 🧱 n/a / 🔌 React

A fast and extendable data table and data grid for React.

It's a feature-rich component which is complementary to the whole Material UI set of React components. It's available in MIT and commercial versions, too.

There's also some competition here. For the sake of comparison, I should mention the data table component of Ant Design library, which is great to use if you need a complete set of UI components.

4. Timeline charts & time-based tools

Not all charting libraries include timelines and Gantt charts, they're quite unique in that sense. So if you have some time-based data to plot, then you may be interested in these libraries or plugins.

Highcharts Gantt

Similar to word clouds, you can have Highcharts Gantt plugin provided by the company. Check out out their page to learn more about it.

amCharts timeline

Similar approach: get the main amCharts library and use additional timeline plugin.

vis-timeline

💵 OSS / ⭐️ 3.3K / 📅 3 years ago / 🧱 n/a / 🔌 universal

Create a fully customisable, interactive timelines and 2d-graphs with items and ranges.

This is an open-source alternative to the above two libs. It's quite flexible, well-designed, although its last release was about 3 years ago.

5. Geospatial and mapping tools

Now we've arrived to geo data, the type of data that has a geographic component to it and should have map-based data visualizations.

Leaflet

💵 OSS / ⭐️ 30K / 📅 4 Sep 2020 / 🧱 5.96 MB / 🔌 universal

Leaflet is the leading open-source JavaScript library for mobile-friendly interactive maps. Weighing just about 39 KB of gzipped JavaScript plus 4 KB of gzipped CSS code, it has all the mapping features most developers ever need.

Leaflet is lightweight, simple, and flexible, and is probably the most popular open-source mapping library at the moment. Leaflet was developed by Vladimir Agafonkin, who is currently in Mapbox (see below), and OSS community.

There are numerous tutorials and guides on how to work with leaflet. So it's very cost and time efficient to start and keep working with Leaflet.

Mapbox

💵 Free-ish & paid / ⭐️ 7.2K / 📅 28 Jan 2021 / 🧱 34 MB / 🔌 universal

Mapbox is a mapping and location cloud platform for developers.

These guys provide SDKs and APIs to companies like Foursquare, Lonely Planet, and Facebook. You can do a lot with Mapbox, and their APIs are a pleasure to work with, well-documented, and well-supported. Check out their examples page.

Mapbox isn't completely free. It has a free tier for low volume apps. So it's free for up to 25,000 mobile users and 50,000 web loads. Beyond that you'd need to pay per additional requests.

📊 See JavaScript Map Data Visualization with Mapbox for a complete guide on Mapbox and different kinds of maps, from heatmaps to choropleths.

Google Maps

Google Maps can do a lot more than just show places on a map. You can map data across the world, create heatmaps, and even size circles.

Google has a CDN URL you'd need to include in your project or use a framework-specific wrapper, like @react-google-maps/api.

amCharts maps

If your project is already using amCharts, then you might be interested in using amCharts maps. There is no need to install anything extra, the main amCharts package already includes everything needed for creating a map visualization.

6. Word clouds

Not all data is quantifiable. Some data can only be illustrated with words. This is a perfect use case scenario for word clouds. A few libraries allow you to do those.

d3-cloud

💵 OSS / ⭐️ 3.3K / 📅 3 years ago / 🧱 n/a / 🔌 universal

Great library to use if you already have D3.js as a part of your code ecosystem.

amCharts word clouds

This is a plugin for amCharts. See more details about amCharts earlier in this post. To create word cloud you'd need the main library + the wordCloud plugin.

Highcharts word clouds

Similar to amCharts word clouds, if you want to make word clouds with Highcharts, you'd need modules/wordcloud.js module.

7. 3D visualization tools

While every tool we've observed above was focused on planar, two-dimensional data visualizations, there's one more dimension to it 😀 The following tools help create 3D visuals.

Three.js

💵 OSS / ⭐️ 66.6K / 📅 24 Dec 2020 / 🧱 24.4 MB / 🔌 universal

The aim of the project is to create an easy to use, lightweight, 3D library with a default WebGL renderer. The library also provides Canvas 2D, SVG and CSS3D renderers in the examples.

Three.js is a different take on visualizing data. It's used to create and display animated 3D computer graphics in a web browser using WebGL. Three.js can be used not only visualize data, but also create such pieces of art as Littlest Tokyo. The data can take ANY form your like. Literary. It's only limited by your creativity.

vis-graph3d

💵 OSS / ⭐️ 44.9K / 📅 16 Jan 2021 / 🧱 36.3 MB / 🔌 universal

Graph3d is an interactive visualization chart to draw data in a three dimensional graph. You can freely move and zoom in the graph by dragging and scrolling in the window.

This is a very interesting lightweight alternative to D3.js and Three.js.

Final remarks

Honestly, it's impossible to include everything in one list. But I hope this post helped you get a better idea about the "big players" and types of data visualizations.

It's worth mentioning that to communicate your data better to your user, it's always a good idea to mix and match different types of data visualizations. Moreover, you can also have a date formatting library (such as Moment.js) or number formatting library (such as numeral.js) that could accompany your graphs and highlight any special or outstanding number in your dataset.

Also, if you need an API to serve data to your charts or data visualization components, please consider to use Cube.js.

If you have any particular recommendation or personal experience with any of the listed libraries to share, please feel free to comment below! 🙌

Custom Commerce.js input field for Sanity.io

Niki — Wed, 06 Jan 2021 19:22:49 +0000

A headless CMS paired with headless eCommerce is a perfect match for marketing and content teams. The headless commerce provider manages the product, cart, and checkout logic, with the content provider managing assets, data, and copy for the rest of the site.

In this post I’ll show you how to connect your products from Commerce.js to your Sanity CMS. Doing this will allow content admins to add products into any page, blog, or app without leaving the Sanity CMS.

This post was inspired by the article how to make a custom input component. Following Thomas’ instructions, you’ll be able to create all sorts of input fields, and perhaps publish them later on npm and/or the Sanity plugin page.

Why this makes sense

Decoupling your commerce and content allows you to customize your marketing site and shop any way you like: custom landing pages, custom page layouts, custom checkout journeys, custom data to be displayed etc. With a headless CMS and commerce powering your business site, your team will have greater flexibility and freedom when it comes to personalizing content.

Like Commerce.js, Sanity.io is a headless provider. Sanity makes it easy to customise structured content, tailor it for a given format, and display it on any front-end. This includes custom input fields and different kinds of pages templates.

The ability to select products from inside the Sanity CMS allows content teams to create targeted campaign pages that reference only certain products, publish new category pages for newly arrived products, and design a fancy slider section with featured products. Custom inputs can be created for all of these by linking your Commerce.js products and publishing content around those products.

In this post we'll only cover how to get Commerce.js products into Sanity through a custom input field. The rest of the creative process I'll leave to you.

Set up Sanity locally

To set up a new project:

npm i -g @sanity/cli 
sanity init

When prompted, select “Blog schema”, and the rest could be defaults.

Now get in your project folder and start the local server on localhost:3333

cd <project-title>
yarn start

Create a schema

Let’s start from the end, and tell our post schema to display our field (that doesn’t exist yet). Go to schemas/post.js and insert our field inside the existing fields array:

fields: [
   …,
   {
     title: "Related products",
     name: "commercejsProducts",
     type: "commercejsProducts",
   },
 ]

We’ll call them “Related products”, because these could be the products that are related to the content in the blog post.

You may have noticed that we’ve used field type that doesn’t exist (see default field types). So we need to create it inside the separate schemas/commercejsProducts.js file.

import CommercejsProducts from "../components/CommercejsProducts";

export default {
 name: "commercejsProducts",
 title: "Commercejs Products",
 type: "array",
 of: [
   {
     type: "singleProduct",
     name: "singleProduct",
   },
 ],
 inputComponent: CommercejsProducts,
};

In this schema we will tell Sanity what component to use to display our data. Right now we’re importing a non-existent CommercejsProducts component from the components folder. We’ll get back to that later. But for now, we’re using the type singleProduct that also doesn’t exist.

We need to create a schema for every single one level deep Object, because Sanity GraphQL cannot read nested objects, unless they’re registered globally. So if we want to create more complex structures, ie objects that go multiple-levels in depth, then we need to create a schema for every object that we’d like to nest, give it a name and only then use that in an object (like we did here). Now let’s create schemas/singleProduct.js schema now.

export default {
 name: "singleProduct",
 type: "object",
 fields: [
   {
     name: "id",
     type: "string",
   },
   {
     name: "created",
     type: "number",
   },
   {
     name: "last_updated",
     type: "number",
   },
   {
     name: "active",
     type: "boolean",
   },
   {
     name: "permalink",
     type: "string",
   },
   {
     name: "name",
     type: "string",
   },
   {
     name: "description",
     type: "string",
   },
   {
     name: "price",
     type: "price",
   },
   {
     name: "quantity",
     type: "number",
   },
 ],
};

Technically, we can put all that inside our schemas/commercejsProducts.js schema, nest it, and we’ll be able to even see that working on localhost. But when you’ll try to deploy that to GraphQL, it will give you an error that would look like this:

Error: Encountered anonymous inline object "singleProduct" for field/type "commercejsProducts". To use this field with GraphQL you will need to create a top-level schema type for it. See https://docs.sanity.io/help/schema-lift-anonymous-object-type

So if we have a property in our Commerce.js product that is another object, we’ll create a separate schema for it, give it a name and reference it in the parent object. Like for the price we’ll have this:

export default {
 name: "price",
 type: "object",
 fields: [
   {
     name: "raw",
     type: "number",
   },
   {
     name: "formatted",
     type: "string",
   },
   {
     name: "formatted_with_symbol",
     type: "string",
   },
   {
     name: "formatted_with_code",
     type: "string",
   },
 ],
};

So go through the product object, see what properties you need and create schemas for them. In the end, we’ll need to import our custom schemas in schemas/schema.js file and register them with the createSchema function:

First, we must import the schema creator

import createSchema from "part:@sanity/base/schema-creator";
import schemaTypes from "all:part:@sanity/base/schema-type";

import commercejsProducts from "./commercejsProducts";
import singleProduct from "./singleProduct";
import price from "./price";

export default createSchema({
 …,
 types: schemaTypes.concat([
   …,
   // Commerce.js product schemas
   commercejsProducts,
   singleProduct,
   price,
 ]),
});

Schemas are now ready! 👏

Create the input component

Now go to your components folder and open your CommercejsProducts.js component that we left hanging while doing schemas.

Let’s make a dummy component and see how it looks.

import React from "react";

const CommercejsProducts = () => <div>Component goes here</div>;

export default CommercejsProducts;

And Voila! You can see our component at the bottom of all other fields in the Post type page.

Now let’s make it look like a Sanity field with the Fieldset component. We’re importing it from Sanity parts. You can read more about parts from the Sanity blog.

In addition to making it look like a Sanity field, let’s make it behave like a Sanity field. Let’s save some of our data that we receive from Commerce.js to Sanity by firing an onChange event onMount of our component. We’ll take the onChange event from PatchEvent. PatchEvent helps us synchronise all the events that are happening in Sanity across different browsers/users. So that means two users can be editing the same field of the same post and they’ll be aware of the changes.

So let’s install our Commerce.js SDK and make that happen:

yarn add @chec/commerce.js

import React, { useEffect } from "react";
import Fieldset from "part:@sanity/components/fieldsets/default";
import PatchEvent, { set, unset } from "part:@sanity/form-builder/patch-event";
import Commerce from "@chec/commerce.js";

const commerce = new Commerce(
 "pk_184625ed86f36703d7d233bcf6d519a4f9398f20048ec",
 true
);

const createPatchFrom = (value) =>
 PatchEvent.from(value === "" ? unset() : set(value));

const CommercejsProducts = ({ type, value, markers, level, onChange }) => {
 useEffect(() => {
   commerce.products
     .list()
     .then((res) => {
       console.log([{ id: res.data[0].id }, { id: res.data[1].id }]);
       onChange(createPatchFrom([res.data[0], res.data[1]]));
     })
     .catch((error) => {
       console.log("There was an error fetching the products", error);
     });
 }, []);
 const { title, description } = type;
 return (
   <Fieldset
     legend={title}
     description={description}
     markers={markers}
     level={level}
   >
     {JSON.stringify(value)}
   </Fieldset>
 );
};

export default CommercejsProducts;

If you open the changes sidebar, you’ll notice that onMount fired onChange event and we had unsaved changes to our blog post data.

Click “Publish” and let’s see that from the GraphQL end, shall we?

Run sanity graphql deploy to deploy your GraphQL. You’ll be asked if you’d like to deploy it, say ‘Y’.

That command will give us a URL where we can view the GraphQL schema, something like:

https://<sanity_id>.api.sanity.io/v1/graphql/production/default

Go to that URL and query posts with our products using the following query:

query {
  allPost {
    commercejsProducts {
      id
      name
      description
      quantity
      price {
        raw
      }
    }
  }
}

And you should see this data returned:

{
  "data": {
    "allPost": [
      {
        "commercejsProducts": [
          {
            "id": "prod_NqKE50BR4wdgBL",
            "name": "Kettle",
            "description": "<p>Black stove-top kettle</p>",
            "quantity": 0,
            "price": {
              "raw": 45.5
            }
          },
          {
            "id": "prod_kpnNwAMNZwmXB3",
            "name": "Book",
            "description": "<p>Book on grid systems</p>",
            "quantity": 0,
            "price": {
              "raw": 13.5
            }
          }
        ]
      }
    ]
  }
}

So now we’re getting the right data, let’s make it work with an input field so our content admins/managers can actually search and select the products they want 😁.

Create input field

We want to create a nice user experience, so let’s use async react-select field

yarn add react-select

import React from "react";
import Fieldset from "part:@sanity/components/fieldsets/default";
import PatchEvent, { set, unset } from "part:@sanity/form-builder/patch-event";
import Commerce from "@chec/commerce.js";
import AsyncSelect from "react-select/async";
import debounce from "lodash.debounce";

const commerce = new Commerce(
 "pk_184625ed86f36703d7d233bcf6d519a4f9398f20048ec",
 true
);

const createPatchFrom = (value) =>
 PatchEvent.from(value === "" ? unset() : set(value));

const CommercejsProducts = ({ type, value, markers, level, onChange }) => {
 const { title, description } = type;

 const loadOptions = debounce(async (inputValue, callback) => {
   const { data } = inputValue
     ? await commerce.products.list({ query: inputValue })
     : await commerce.products.list();

   const products = data.map((product) => ({
     ...product,
     label: product.name,
     value: product.id,
   }));

   callback(products);
 }, 500);

 const handleChange = (values) => {
   onChange(createPatchFrom(values));
 };

 return (
   <Fieldset
     legend={title}
     description={description}
     markers={markers}
     level={level}
   >
     <AsyncSelect
       value={value}
       cacheOptions
       isMulti
       defaultOptions
       loadOptions={loadOptions}
       onChange={handleChange}
     />
   </Fieldset>
 );
};

export default CommercejsProducts;

A few things are happening here.

Since all inputs are controlled in Sanity, we need to pass default value to our select component as a prop.
createPatchFrom function that handles the onChange event, that we have in the handleChange function. It fires when we select the item from the suggested list.
AsyncSelect component accepts loadOptions that we need to put into debounce so that we don’t send HTTP requests immediately on every keystroke.
The loadOptions has Commerce.js SDK package that is initialized at the top of our component, that gets the list of products, and depending whether this function is called by onMount or onChange, we’re displaying either full list of products or products that the user searched for.
Inside the loadOptions function we need to loop through the elements and create label and value properties, because our react-select component is looking for them. Don’t worry about it being passed higher, and it being found in GraphQL search, because Sanity takes out all the fields that are not declared in the schema.

NOTE: DO NOT store your Commerce.js public key in your project, this is done solely for demonstration purposes. Keep your secret in .env variables.

And there we go, we have a multi select input component that allows us to link Commerce.js products to our blog post.

Next steps

This is a very simple component that lists some of the properties from a Commerce.js product, you can enhance it any way you’d like, for example you can:

Add more (or less) properties for your products;
Change the dropdown input to a grid format with images, to make it easier for your content/marketing team to navigate through your products.

You can also create another input field that lists categories, if you want those. Commerce.js has an API for it as well.

If then you’d like to publish your sanity-commercejs-input component(s) to npm, have a look at Espen’s and Knut’s stream, Espen goes through some instructions and tips starting from 1:05:49.

You should now be able to see the power of using headless content with headless commerce. Integrating the two empowers content editors when it comes to creating and updating eCommerce related content.

GitHub repo 🔗