DEV Community: Victoria

Beyond Next.js: TanStack Start and the Future of Full-Stack React Development

Victoria — Sun, 14 Dec 2025 22:08:17 +0000

For the last five years, Next.js was the "safe" default. Whether you were building a personal blog or a complex SaaS, the advice was always: Just use Next. But lately, that conversation has changed. As Next.js evolved from a simple tool into a massive, "magic-heavy" ecosystem, the developer experience changed with it. Between complex caching rules and rigid server-client boundaries, we’ve reached a point where we often feel less like architects and more like we’re just troubleshooting the framework's assumptions.

We aren’t looking for another framework just for the sake of it; we’re looking for a return to clarity. We want to enjoy the build again without fighting the tool we chose to help us. That’s where TanStack Start enters the arena — it feels like the "reset button" the ecosystem needs.

The "Complexity Tax" of the Modern Web

Starting with Next.js 13, things became less stable. React Server Components (RSC) were introduced alongside the App Router, and the framework began changing its foundational assumptions frequently.

Suddenly, everything became "server-side by default." We entered a world of 'use client', 'use server', and the 'use cache' directive. The paradigm flipped entirely, bringing frequent hydration problems.

We adapted to the idea that everything was cached by default in Next.js 14. Then Next.js 15 arrived with Turbopack and a completely inverted mental model: nothing is cached by default. You now have to explicitly opt-in to caching behavior.

// Next.js 15 - Explicit caching with 'use cache' directive
'use cache'

export async function getData() {
  const data = await fetch('/api/data')
  return data
}

Next.js 15 made Turbopack the default (or at least heavily promoted) build tool, moving away from Webpack. The Rust-based bundler promised 10x performance improvements, but developers report variable experiences — excelling at hot refresh but struggling with broken imports, high resources consumption, and cold starts.

The fact that Vercel published an official guide titled "Ten Common Mistakes with the Next.js App Router" speaks for itself.

TanStack Start Enters the Arena

TanStack has serious credibility. They've been shipping battle-tested tools that developers actually use for years:

Out of curiosity, I built an app while it was still a beta, and now it is v1 already, and everything works without friction.

Solid foundation is simple, TanStack Start is built on two key technologies:

TanStack Router (the entire routing layer with type safety)
Vite (an industry-standard build tool)

Core Philosophical Difference: Client-First vs Server-First

Next.js 15: Server-First Architecture

Every component is a React Server Component by default. You start on the server and explicitly opt into client-side interactivity with 'use client'. This excels for content-heavy websites and SEO-critical catalogs.

TanStack Start: Client-First with Selective SSR

TanStack Start assumes you are building an interactive app. You have fine-grained control over the rendering mode via the ssr property on each route:

// Pure client-side rendering (like a traditional SPA)
export const Route = createFileRoute('/dashboard')({
  ssr: false,
  component: DashboardComponent,
})

// Full SSR for SEO-critical pages
export const Route = createFileRoute('/products')({
  ssr: true,
  loader: async () => fetchProducts(),
  component: ProductsComponent,
})

Feature-by-Feature Comparison

1. Routing with Type Safety

The framework generates a routeTree.gen.ts file. If you change a route parameter, every link using that route fails at build time — not at runtime.

Next.js 15 Example

// app/products/[slug]/page.tsx
export default async function ProductPage({params}: { params: Promise<{ slug: string }> }) {
  const {slug} = await params
  return <div>Product: {slug}</div>
}

// In a component - just strings, no type checking
<Link href={`/products/${productId}`}>
  View Product
</Link>

TanStack Start Example

// routes/products.$id.tsx
export const Route = createFileRoute('/products/$id')({
  loader: async ({params}) => {
    // params.id is fully typed automatically
    return getProduct(params.id)
  },
  component: ProductComponent,
})

// Navigation with compile-time safety
navigate({
  to: '/products/$id',
  params: {id: productId} 
})

Learn more in the TanStack Router Type Safety guide.

2. Data Fetching: Isomorphic Loaders vs Async Server Components

Next.js 15 Approach

Next.js uses Async Server Components that run exclusively on the server. If you need this data on the client for subsequent interactions, the framework has to re-fetch or stream from the server.

// app/page.tsx - Async Server Component
export default async function Page() {
  const res = await fetch('[https://api.example.com/data](https://api.example.com/data)')
  const data = await res.json()

  return (
    <main>
      <h1>{data.title}</h1>
    </main>
  )
}

TanStack Start Approach

TanStack uses isomorphic loaders — the same code runs on the server during the initial load (for SEO/speed) and on the client during subsequent navigations. This avoids the "waterfall" and server round-trips for every UI transition.

export const Route = createFileRoute('/products/$id')({
  loader: async ({params}) => {
    const product = await getProduct(params.id)
    return {product}
  },
  component: ({useLoaderData}) => {
    const {product} = useLoaderData()
    return <div>{product.name}</div>
  }
})

Learn about the execution model.

3. Server Functions: Flexibility vs Convention

Next.js 15 Server Actions

Primarily designed for forms and mutations, Server Actions are POST-only and can feel tightly coupled to the render cycle.

TanStack Start Server Functions

Support any HTTP method, built-in validation with Zod, and composable middleware for things like auth.

export const createUser = createServerFn({method: 'POST'})
  .validator(z.object({
    name: z.string().min(1),
    email: z.string().email()
  }))
  .middleware([authMiddleware])
  .handler(async ({data}) => {
    return db.users.create(data)
  })

Learn more in the TanStack Start Server Functions guide.

4. SEO: Static Metadata vs Dynamic Head Management

Next.js uses generateMetadata. TanStack Start uses a head function that receives fully-typed loaderData. Child routes can override parent route meta tags intelligently without re-fetching data.

Next.js 15 Metadata

export async function generateMetadata({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
  const product = await getProduct(id) // Often fetched again if not cached
  return { title: product.name }
}

TanStack Start Head

export const Route = createFileRoute('/products/$id')({
  loader: ({ params }) => getProduct(params.id),
  head: ({ loaderData }) => ({
    meta: [
      { title: loaderData?.name },
      { name: 'description', content: loaderData?.description }
    ],
  }),
})

5. Build Tooling: Vite vs Turbopack

Next.js 15 is pushing Turbopack, which is still maturing. TanStack Start uses Vite, which has been battle-tested for years with a massive plugin ecosystem and predictable performance.

6. Deployment: Vendor Lock-in vs True Flexibility

Next.js is heavily optimized for Vercel. TanStack Start doesn't care where you deploy. Deploy to Cloudflare Workers, Netlify, or any Node.js server.
Deploy TanStack Start in less than a minute.

7. Developer Experience: Next.js 15 vs TanStack Start

The configuration and debugging experience is a fundamental difference. TanStack provides deep state-inspection tools, rich configuration options to choose from, and many other things that Next.js lacks to sweeten our developer's life.

TanStack Start UI/Console:

Next.js 15 Console:

When to Choose Each Framework

Choose Next.js 15 if: Building content-heavy sites (blogs, e-commerce) where SEO is mission-critical and you are deploying to Vercel.
Choose TanStack Start if: Building highly interactive applications (dashboards, SaaS), you need deployment flexibility, and type safety is non-negotiable.

View the full comparison table here.

Final Thoughts

The React ecosystem has been a bit of a monopoly lately, and let's be honest — nobody actually likes a monopoly unless they're playing a board game.

The arrival of TanStack Start is just healthy competition. It’s not about "killing" Next.js; it's about having a choice again. We finally have an alternative that prioritizes explicitness over magic and stability over constant reinvention. Healthy competition keeps the ecosystem sharp and gives us the freedom to pick the tool that actually fits the job. It’s time to stop fighting the defaults and start enjoying the build again.

Additional Resources

Next.js 15

TanStack Start

New and Most Interesting in Web UI from Google I/O 2025 (with demos)

Victoria — Tue, 03 Jun 2025 17:35:25 +0000

Introduction

Every web developer has struggled with dropdown menus, carousels, and UI components that seem deceptively simple. But what if these patterns could be built natively with ease? At Google I/O 2025, Una Kravets showed us exactly how the latest updates in HTML and CSS are redefining what’s possible. Web UI has undergone a significant transformation, with new technologies making interfaces more powerful and accessible. This article explores three key innovations: the evolution of the dialog vs. popover that enables us to build a customizable select menu from scratch, the introduction of a native scroll component, and a new hover card feature that is closely related to the new world of popovers.

1. New Dialog vs. Popover

Let’s start with something surprisingly powerful: dialogs and popovers without a single line of JavaScript. Thanks to the new command attribute pattern, you can control dialog and popover visibility declaratively:

<button command="show-modal" commandfor="demo">Show Side Dialog</button>

<dialog id="demo" class="slide-out">
  <section>
    <header>
      <button title="Close" command="close" commandfor="demo" class="material-symbols-outlined">close</button>
    </header>
  </section> 
</dialog>

Now, both <dialog> and <popover> elements have evolved to offer different interaction models. Popovers support light dismiss (i.e., clicking outside closes them), anchor positioning, and declarative usage, while dialogs now support closedby="any" to allow more flexible closing behavior, making them act a bit more like popovers while keeping their modal essence.

You can control the 'light-dismiss' option and specify which element triggers the dialog to close by using this [closeby] attribute, and no JavaScript required:

You can check out a working example here: Zero JavaScript Dialog Demo

We’ll revisit popovers again when we get to hover cards, since there's even more to cover.

2. Native Select Component

Customizing a <select> element has always been a pain — either you accepted the default browser styling or ended up rebuilding it from scratch with divs and JS. But that’s changing. With the new popover-based <select> and anchor positioning, you can now fully style and control the component while preserving accessibility and form behavior.

New pseudo-elements, HTML elements, and built-in styling for options and checkmarks let you build something custom without hacks.

Here’s a breakdown of the new anatomy:

Play with the full demo here: Customizable Select Demo

You’ll also get a feel for how anchoring works—a feature introduced at the same time.

To better visualize this anchoring logic, check out this Anchor tool.

A word of caution

As noted in this MDN article, the new <selectedcontent> may cause issues if you're dynamically updating <option> elements using JavaScript — those changes won’t automatically reflect inside <selectedcontent>.

And yes, support is still limited right now, so use it wisely in production apps.

To see a real-time walkthrough from the conference, here’s the timestamped demo.

3. Building a New Native Scroll Component

Creating smooth, accessible sliders or carousels has always meant reaching for external libraries or building your own logic. But now, CSS is making native scroll components a reality. You get:

scroll-button pseudo-elements (for navigation controls)
scroll-marker (for quick jump-to-points)
Scroll-driven animations (yes, native!)

Here’s the anatomy of this new "slider":

This opens up a lot — tabs, carousels, progress steppers, multi-step forms, you name it. And small details like scroll shadows (that used to require JS or weird hacks) are now a breeze:

There’s a lot more to explore when it comes to scroll-state, so I recommend diving into Google’s official carousel demos. All the examples are editable, and the source code is available — great for learning or adapting for your own use.

Want something more interactive? Play with the Carousel Configurator. You can toggle options and see how the styles and behaviors change.

Beyond saving time, this new CSS-driven approach reduces JS payload and improves maintainability.

If there's no code — there's nothing to maintain.

4. Hover Card

Hover cards take the popover magic even further. Alongside popover, we now have attributes like interesttarget and popovertarget, unlocking more nuanced interactions.

Basically, there are now three types of popovers:

Let’s say you want to show extra context when the user hovers over something — no click required. Combine interesttarget with a popover and voilà:

Here’s a simplified hover card using just a popover:

You can fully customize it too:

Important to note: this animation behavior differs from a typical :hover effect — it’s more dynamic, controllable, and has delay/interest thresholds built-in.

Watch the live example here.

Feeling confused by all these new attributes? Don’t worry — it takes a bit of hands-on play to internalize it. You can dig deeper via the Interest Invokers explainer and the Popover documentation.

The short version:

interesttarget = hover for a moment, show something
popovertarget = click or focus, show something
You can mix and match for rich interactions

Conclusion

The future of Web UI is more declarative, accessible, and efficient. As these features roll out more widely, we can ditch a lot of the boilerplate and focus on creativity instead.

Yes, it can feel overwhelming, especially for newer devs. But you don’t need to memorize every detail. Just knowing these features exist is half the battle. When a problem arises later, you’ll remember, “Oh yeah, I saw a demo about that,” and you’ll know where to look.

It’s not about memorizing — it’s about exposure.

With these updates, we’re entering a golden era of UI development. Less JavaScript. More clarity. Better accessibility. And honestly? A lot more fun.

Resources

Understanding Checksums in Ethereum: Why They Matter for Web3 Developers

Victoria — Sun, 09 Feb 2025 15:40:04 +0000

Many Web3 and blockchain developers have encountered an issue where their specified address fails due to a checksum error. But what exactly is a checksum, and why is it so important?

In this article, we'll break it down in simple terms, explore how checksums are used in Ethereum, and provide practical tips for Web3 developers on working with them. Let’s dive in!

What Is a Checksum?

A checksum is a small piece of data derived from other data to detect errors during transmission or user input. In blockchains, checksums are often calculated for addresses and appended in some way to ensure integrity. This prevents sending funds to invalid addresses due to typos or data corruption.

For example, when sending funds to an Ethereum address, wallets and blockchain clients use checksums to verify whether the address is correctly formatted before proceeding with the transaction. This simple mechanism helps prevent costly mistakes.

Checksum in Ethereum

Ethereum introduced the checksum standard in EIP-55 back in 2016. The idea is simple:

Convert the address to lowercase hex.
Hash the lowercase address using Keccak-256.
If a character in the original address is a letter (a-f), make it uppercase if the corresponding hash bit is 1; otherwise, keep it lowercase.
This approach has several benefits:
It remains backward-compatible with hex parsers that accept mixed case.
It keeps the length at 40 characters.
It significantly reduces the probability of mistyped addresses being accepted as valid (~0.0247%).

Here’s an example implementation in JavaScript:

const createKeccakHash = require('keccak');

function toChecksumAddress(address) {
  address = address.toLowerCase().replace('0x', '');
  var hash = createKeccakHash('keccak256').update(address).digest('hex');
  var ret = '0x';

  for (var i = 0; i < address.length; i++) {
    ret += parseInt(hash[i], 16) >= 8 ? address[i].toUpperCase() : address[i];
  }

  return ret;
}

If you prefer a simpler implementation, you can use Viem:

import { getAddress } from 'viem';

console.log(getAddress('0xa5cc3c03994db5b0d9a5eEdD10Cabab0813678ac'));
// Output: '0xa5cc3c03994DB5b0d9A5eEdD10CabaB0813678AC'

Viem simplifies the process, ensuring you always get a checksummed address with minimal effort.

The EIP-1191 Extension: Adding Chain IDs to Checksums

EIP-1191 extends EIP-55 by incorporating chain IDs into the checksum calculation. The goal is to prevent users from mistakenly sending funds to an address on a different network, such as Ethereum Mainnet vs. Ethereum Testnet.

How It Works:

The address is converted using the same EIP-55 rules.
If a registered chain ID is provided, it is added to the hash input.
The resulting checksum-encoded address helps differentiate addresses across networks.

However, there is a tradeoff:

EIP-1191 addresses are not backward-compatible with standard EIP-55 checksummed addresses.
Some tools and applications relying on EIP-55 might not recognize them.

Many major tools, including Trezor, Ledger, MEW, MyCrypto, and Web3.js, have adopted EIP-1191. However, MetaMask defaults to EIP-55 and will flag invalid checksums when manually modifying an address.

Example:
If you paste an Ethereum address without a checksum into Etherscan, it will automatically show you the checksummed version, helping you avoid errors.

Best Practices for Web3 Developers

Always use checksummed addresses to prevent user errors and ensure compatibility with major tools.
Use libraries like Viem to handle checksums effortlessly.
Be aware of EIP-1191 limitations and ensure your app supports the appropriate checksum format based on network requirements.
Validate addresses before sending transactions to prevent costly mistakes.

By following these practices, you can make your dApp safer and improve the user experience.

Final Thoughts

Checksums play a crucial role in blockchain security, preventing address-related mistakes that could lead to lost funds. Understanding EIP-55 and EIP-1191 helps developers write more robust and secure Web3 applications. Whether you're manually validating addresses or using a library like Viem, always ensure you're working with the correct checksummed format.

Even though a deep understanding of checksums is not strictly required, having at least a brief knowledge of this concept will enhance your general expertise in the field. It can help you avoid unnecessary debugging, prevent certain bugs, and demonstrate a higher level of proficiency as a Web3 developer.

For further reading, check out these resources:

Happy coding!

Rendering Strategies in Next.js

Victoria — Wed, 30 Oct 2024 12:48:14 +0000

Hello, long time no see! How’s everyone doing?

Recently, I’ve been diving deep into Next.js 15, brushing up on some fundamental concepts and exploring a new favorite topic: rendering strategies. This one’s for anyone curious about the ins and outs of SSR (Server-Side Rendering) and all its sibling strategies in Next.js. Whether you’re just starting or need a refresher, consider this your go-to memo on rendering strategies!

SSR (Server-Side Rendering) in Next.js vs. CSR (Client-Side Rendering)

How SSR Works

In SSR, Next.js pre-renders the page on the server at each request. If you’ve ever added a fetch request at the top of a functional component in Next, then hit refresh to update the data, you’re already using SSR.

One game-changer with the latest updates is the serverComponentsHmrCache feature. This allows us to cache fetch responses in server components across HMR (hot module replacement) refreshes in development mode. So, every refresh becomes a faster, cheaper, and more efficient experience, especially when billed API calls are involved.

Benefits of SSR:

Improved Initial Load Time: Faster than CSR, especially for first-time visitors.
SEO-Friendly: Search engines love SSR since content is ready when they crawl.
Reduced FCP (First Contentful Paint): Faster perceived loading experience for users.
Direct Database Calls: With SSR, data fetching logic can stay server-side, making direct database calls possible without needing to build API endpoints.
Automatic Request Deduplication: A lesser-known perk—when the same data is requested multiple times, only one request is sent.
Enhanced Security: Keeps sensitive data server-side, never exposing API keys on the client.
Reduced Network Waterfall: SSR fetches data in parallel, avoiding sequential delays.
JS Optional: Users can still access content if their browser has JavaScript disabled.

CSR (Client-Side Rendering)

In CSR, you start by declaring an empty state and conduct a fetch request within useEffect. Once the data arrives, you update the state and UI.

Trade-Offs:

Empty Page at First: Users see an empty shell until data is loaded, which can impact user experience and SEO.
Full Control Over State: Great for interactive pages where user actions trigger updates.

Rendering Strategies Overview

Let’s review each of these rendering methods, highlighting when and why you’d choose one over the other.

SSG (Static Site Generation)

SSG generates HTML at build time, which can be served lightning-fast from a CDN. However, it’s not suitable for websites with frequently updated content. It’s also Next.js’s default rendering strategy.

ISR (Incremental Static Regeneration)

ISR is SSG’s flexible sibling. It allows content to be updated even after the initial build, making it perfect for websites that change occasionally but don’t require real-time data. Just add export const revalidate = <value> to configure it per page, or use revalidatePath and revalidateTag for more targeted revalidation.

SSR (Server-Side Rendering)

SSR renders pages on the server for each user request, meaning content is always fresh. It’s ideal for highly dynamic content, though it can be slower than SSG since pages are generated on-demand. SSR shines in scenarios where up-to-date content matters but client-side interactivity isn’t crucial.

PPR (Progressive Page Rendering)

PPR introduces a hybrid approach. It operates on the component level instead of the page level, making it unique. A static SSR shell serves initially, while dynamic content streams in as components wrapped in Suspense load asynchronously. This lets you mix and match SSR and CSR on the same page, serving a static shell immediately and gradually populating it with interactive content.

Conclusion

And that’s the roundup! Each rendering strategy offers distinct advantages depending on your application’s requirements. Play around, experiment, and find the best fit for your use case!
Happy coding!

Credits: Done based on the JS Mastery resources and with a touch of AI formatting

New in WebDev 2024 - Interactive Experiences

Victoria — Fri, 09 Aug 2024 09:32:50 +0000

Recently we had a chance to witness an amazing Google I/O conference which surprised devs with a bunch of so-needed updates in web development. Today we will briefly go through some juiciest features that you can already use in your apps or that will be available in the near future.

New Interactice Experiences you should know about

1. Scroll-driven animations

WebPlatform status - Limited Availability.
Safari and Firefox still do not support this feature yet, but they are pretty close to it.

No more GSAP and Framer motion, no heavy client-side javascript, on top of all, these animations have great tooling and documentation.

Even though this is a relatively new feature, we have a set of nice dev tools to debug scroll-driven animations, and all animations in general. I think this is one of the biggest advantages of this new feature.

You can integrate it using polyfill: from this repo

2. Same-document view transitions for single-page applications

WebPlatform status - Limited Availability.
Safari and Firefox do not support it well.

Already well-known young solution for SPA transitions, a huge field to experiment and explore. Comes with a dedicated dev tool as well.

When a view transition runs on a single document it is called a same-document view transition. This is typically the case in single-page applications (SPAs) where JavaScript is used to update the DOM. Same-document view transitions are supported in Chrome as of Chrome 111.

How it works

When invoked, the browser automatically captures snapshots of all elements that have a view-transition-name CSS property declared on them.

It then executes the passed in callback that updates the DOM, after which it takes snapshots of the new state.

These snapshots are then arranged in a tree of pseudo-elements and animated using the power of CSS animations. Pairs of snapshots from the old and new state smoothly transition from their old position and size to their new location, while their content crossfades. If you want, you can use CSS to customize the animations.

You can read more: in this article

3. View Transition CSS classes

Up until now, when animating multiple snapshots in the same way, you needed to target each and every snapshot individually by repeating its pseudo-selector for every element that has a unique view-transition-name.
With view-transition-class you can now add a shared name to all snapshots. Use this shared name in the pseudo selectors to target all snapshots that match. This results in far simpler selectors, which automatically scale from one to many elements.

#cards-wrapper > div {
  view-transition-class: card;
}
html::view-transition-group(.card) {
  animation-timing-function: var(--bounce);
}

4. View Transition types

Before active types, you could add classes to the DOM and respond to those classes in your CSS. However, you'd also have to cleanup after the transitions were complete.
With view transition types you can achieve the same result, with the added benefit of these types automatically getting cleaned up once the view transition has finished. Types only apply when capturing or performing the transition.
For same-document view transitions, pass the types into the startViewTransition method which now accepts an object. update is the callback function that updates the DOM, and types is a sequence of strings.

For example, you can animate your pagination like this:

const direction = determineBackwardsOrForwards();

const t = document.startViewTransition({
  update: updateTheDOMSomehow,
  types: ['slide', direction],
}););

To play around and explore more: here.

5. Cross-document view transitions

Last but not least, it is a multi-page application of view transitions! This was the most exciting update in my opinion.

TL;DR:

What's different when compared with same-document view transitions, is that with cross-document view transitions you don't need to call document.startViewTransition to start a view transition. Instead, the trigger for a cross-document view transition is a same-origin navigation from one page to another, an action that is typically performed by the user of your website clicking a link.
In other words, there is no API to call in order to start a view transition between two documents. However, there are two conditions that need to be fulfilled:

Both documents need to exist on the same origin.
Both pages need to opt-in to allow the view transition.

If you want to dive deeper into it, I highly recommend watching this 15-minute video from the conference.

Demo:

The code:

// OLD PAGE LOGIC
window.addEventListener('pageswap', async (e) => {
  if (e.viewTransition) {
    const targetUrl = new URL(e.activation.entry.url);

    // Navigating to a profile page
    if (isProfilePage(targetUrl)) {
      const profile = extractProfileNameFromUrl(targetUrl);

      // Set view-transition-name values on the clicked row
      document.querySelector(`#${profile} span`).style.viewTransitionName = 'name';
      document.querySelector(`#${profile} img`).style.viewTransitionName = 'avatar';

      // Remove view-transition-names after snapshots have been taken
      // (this to deal with BFCache)
      await e.viewTransition.finished;
      document.querySelector(`#${profile} span`).style.viewTransitionName = 'none';
      document.querySelector(`#${profile} img`).style.viewTransitionName = 'none';
    }
  }
});

// NEW PAGE LOGIC
window.addEventListener('pagereveal', async (e) => {
  if (e.viewTransition) {
    const fromURL = new URL(navigation.activation.from.url);
    const currentURL = new URL(navigation.activation.entry.url);

    // Navigating from a profile page back to the homepage
    if (isProfilePage(fromURL) && isHomePage(currentURL)) {
      const profile = extractProfileNameFromUrl(currentURL);

      // Set view-transition-name values on the elements in the list
      document.querySelector(`#${profile} span`).style.viewTransitionName = 'name';
      document.querySelector(`#${profile} img`).style.viewTransitionName = 'avatar';

      // Remove names after snapshots have been taken
      // so that we're ready for the next navigation
      await e.viewTransition.ready;
      document.querySelector(`#${profile} span`).style.viewTransitionName = 'none';
      document.querySelector(`#${profile} img`).style.viewTransitionName = 'none';
    }
  }
});

And, as usual, here are the docs to learn more: Chrome docs.

Conclusion

That covers everything I wanted to share with you. Of course, there are many more smaller updates that enhance the overall user experience, but I'm confident that the five mentioned above will soon become the standard.

So explore, experiment, and adopt!

Happy coding, everyone!

BaseLine - a reliable source of truth for a Web developer

Victoria — Tue, 11 Jun 2024 13:12:02 +0000

Browsing MDN docs you might encountered this widget:

But what does it actually mean and why should you trust it?
Let's figure that out.

Background

With the web platform constantly evolving and browsers undergoing rapid innovation, developers find it challenging to keep pace with the changes. Moreover, there's a lack of a shared vocabulary for discussing commonly available web features.

One of the solutions to address this issue became BaseLine.

Definition

Official definition is the following:

Baseline identifies web platform features that work across browsers. Baseline helps you decide when to use a feature by telling you when it is less likely to cause compatibility problems for your site's visitors.

A Baseline feature, whether it's an API, a group of CSS properties, or a JavaScript syntax, functions reliably across numerous popular desktop and mobile browsers like Chrome, Edge, Firefox, and Safari.

These features are characterized as either newly accessible in the latest stable browsers or as widely available with ongoing support across different versions.

Badges Concept

Basically, BaseLine is presented as a set of widgets where each of them has a specific meaning:

If you see a widely available Baseline badge, then you can trust that the feature has a consistent history of support in each of the Baseline browsers. A widely available feature has been in multiple browsers for years. It works with many browsers and devices, even ones that aren't yet up to date with the latest browser releases.

If you see a newly available Baseline badge, then you can trust that the feature works in at least the latest stable version of each of the Baseline browsers and often more. A newly available feature works in the latest browsers, but may not work with older browsers and devices. Consider your site's audience carefully before using a newly available feature.

If you see a limited availability badge, then that feature is not Baseline. Do more research and testing with your site's users before relying on that feature, or wait for it to become Baseline.

Browser support

According to the documentation at the time of publishing this article, Baseline tracks availability with the following browsers:

Apple Safari (iOS)
Apple Safari (macOS)
Google Chrome (Android)
Google Chrome (desktop)
Microsoft Edge (desktop)
Mozilla Firefox (Android)
Mozilla Firefox (desktop)

What About CanIUse?

We do have a great tool such as CanIUse and of course, BaseLine is not going to replace it.

Baseline serves as a general reference for support and may not address every scenario. If your website must function with older devices or browser versions not included in the Baseline status, you might need to conduct your own research or testing.

If Baseline doesn't fit your needs, you must consult with CanIUse before using a feature.

Conclusion

I am excited about how the community is becoming more and more united and we have so many different tools to get rid of the confusion and make as less mistakes as possible. BaseLine is a trustworthy source and I believe that it is only going to improve.

I hope now you understand a little bit more about it and might find it practical in your daily work.

Happy coding!

References

React Compiler - New Hero?

Victoria — Thu, 16 May 2024 14:35:49 +0000

Have you seen the first day of React Conf 2024? Were you as excited as I am about new changes? I personally liked that they made ref as a component prop and we finally can get rid of forwardRef!

But the true GEM, that was shining the most, definitely was a React Compiler!

Let's dive a bit deeper into it!

For those who want a short overview, here it is:

TL;DR

React Compiler provides memoization under the hood
It's Opensource!
No need to use hooks like useMemo and useCallback
Not stable yet, you can experiment but do not use it in production. Give it some time.

And for those who want to know the details, I am here to spill the tea!

How React Compiler works under the hood

Here is a short chart of what happens initially:

That's how we get our optimization and we do not need useMemo or useCallback anymore

But when our memoCache is ready, what happens? Here is another chart to demonstrate the process, which is quite simple:

But it is important to remember, that React Compiler is not part of React 19! It is a separate open-source project. And there is one little caveat here...

So we should expect a small headache soon when React Compiler gains mass adoption.

One interesting thing I have found - under the hood there is lots and lots of typescript! What does it mean to us? Less bugs, better support, and documentation. I believe TS is a must in modern web development and was happy to see it.

Compatability and fallback

React Compiler has a fallback for the bad-written code. Besides that additional linter comes along with the Compiler. If the compilation is going to damage the component, the Compiler falls back on the original transpiler and everything still works. But if you follow the main React Rules, you will not have any bad side effects.

What about useEffect?

Unfortunately, the dependencies array for useEffect is still necessary, but React Compiler helps to stabilize the non-primitive references in your dependencies array. And again, it is just better to follow React Rules so you do not need this stabilization at all.

Conclusion

Since this tool is still in its yearly age, you can freely experiment with it, but be careful or better not use it in production, give it some time to be more stable and resolve current issues.

There is a public React Compiler PR, if you are interested, go check it out, and maybe leave a supportive comment to the community and devs. It feels like a historical moment, one small step forward!

That's all for now, thank you for your time, and happy coding!

Materials and references:

Integrate Gnosis Safe into your React Web3 App

Victoria — Tue, 23 Apr 2024 17:19:36 +0000

Recently, I had a chance to work on an interesting task where I needed to integrate the Gnosis Safe multi-signature wallet into the existing application.

I will walk you through a short tutorial, and I hope it will help you save a few hours of development. Let's begin.

First of all, we should start with the official documentation for their API SDK.
You can also explore what Gnosis Safe provides for developers, but in the context of our tutorial, we are going to keep it simple.

You need to have already created a Gnosis Safe wallet with several addresses added as signers. The process is quite simple, so we also won't focus on this.

According to the documentation, the first step is to install an SDK. I will use yarn, but feel free to use any other package manager.

yarn add @safe-global/api-kit

Next, we need to create an EthAdapter based on the library you are using in your app. I will use ethers.js 6.12

Depending on the library used by the dapp, there are two options:

Once the instance of EthersAdapter or Web3Adapter is created, it can be used in the initialization of the API Kit.

Here is the trick. The documentation tells you to use a private key to instantiate a wallet, but you can just use a signer from the provider.

I created a TS file in a 'gnosis' folder, called it 'adapters.ts':

let signer = null;

let provider;

if (window.ethereum == null) {
    // If MetaMask is not installed, we use the default provider,
    // which is backed by a variety of third-party services (such
    // as INFURA). They do not have private keys installed,
    // so they only have read-only access
    console.log("MetaMask not installed; using read-only defaults");
    provider = ethers.getDefaultProvider();
} else {
    // Connect to the MetaMask EIP-1193 object. This is a standard
    // protocol that allows Ethers access to make all read-only
    // requests through MetaMask.
    provider = new ethers.BrowserProvider(window.ethereum);

    // It also provides an opportunity to request access to write
    // operations, which will be performed by the private key
    // that MetaMask manages for the user.
    signer = await provider.getSigner();
}

export const ethAdapter = new EthersAdapter({
    ethers,
    signerOrProvider: signer || provider,
});

Here you might encounter an error from Webpack about global await, just enable this experimental feature in your webpack config. You can use react-app-rewired to adjust your webpack configuration.

After we have created ethAdapter, we can proceed and create the apiKit instance, which is literally a few lines of code:

export const apiKit = new SafeApiKit({
    chainId: ethers.toBigInt(process.env.REACT_APP_CHAIN_ID as string),
});

Full file for this:

import { EthersAdapter } from "@safe-global/protocol-kit";
import SafeApiKit from "@safe-global/api-kit";
import { ethers } from "ethers";

let signer = null;

let provider;

if (window.ethereum == null) {
    // If MetaMask is not installed, we use the default provider,
    // which is backed by a variety of third-party services (such
    // as INFURA). They do not have private keys installed,
    // so they only have read-only access
    console.log("MetaMask not installed; using read-only defaults");
    provider = ethers.getDefaultProvider();
} else {
    // Connect to the MetaMask EIP-1193 object. This is a standard
    // protocol that allows Ethers access to make all read-only
    // requests through MetaMask.
    provider = new ethers.BrowserProvider(window.ethereum);

    // It also provides an opportunity to request access to write
    // operations, which will be performed by the private key
    // that MetaMask manages for the user.
    signer = await provider.getSigner();
}

export const ethAdapter = new EthersAdapter({
    ethers,
    signerOrProvider: signer || provider,
});

export const apiKit = new SafeApiKit({
    chainId: ethers.toBigInt(process.env.REACT_APP_CHAIN_ID as string),
});

And now we can start building our transaction factory. I created a separate file called 'transactions.ts':

We need to propose a transaction to service and need to start from instantiating a protocolKit:

const protocolKit = await Safe.create({
    ethAdapter,
    safeAddress: process.env.REACT_APP_GNOSIS_SAFE_ADDRESS as string,
});

Then we create a reusable function to prepare a transaction:

function createSafeTransaction(to: string, value: string, data: string) {
    return protocolKit.createTransaction({
        transactions: [
            {
                to,
                value,
                data,
            },
        ],
    });
}

UPD: If you are facing an issue with a conflicting nonce, try to add the following by utilizing API Kit:

const nextNonce = await apiKit.getNextNonce(process.env.REACT_APP_GNOSIS_SAFE_ADDRESS)

Then include it as an option:

    return protocolKit.createTransaction({
        transactions: [
            {
                to,
                value,
                data,
            },
        ],
        options: {
            nonce: nextNonce,
        },
    });

Next step we create a function for a proposal:

async function proposeTransaction(safeTransaction: SafeTransaction, signer: ethers.Signer) {
    console.log("Proposing transaction");
    const senderAddress = await signer.getAddress();
    const safeTxHash = await protocolKit.getTransactionHash(safeTransaction);
    const signature = await protocolKit.signHash(safeTxHash);

    return await apiKit.proposeTransaction({
        safeAddress: await protocolKit.getAddress(),
        safeTransactionData: safeTransaction.data,
        safeTxHash,
        senderAddress,
        senderSignature: signature.data,
    });
}

And finally, the transaction itself. Pay attention here, that we need to encode a transaction function call with the right params. If you use ethers.js, you can check out documentation explaining how it works:

async function safeBorrowRegionalPool(amount: string, signer: ethers.Signer, poolId: string, decimals: number = 6) {
    const CONTRACT_POOL_FACTORY = process.env.REACT_APP_CONTRACT_POOL_FACTORY!;
    const poolFactory = new ethers.Contract(CONTRACT_POOL_FACTORY, abiPoolFactory, signer);
    let poolAddress = await poolFactory.pools(poolId);
    const abi_interface = new ethers.Interface(abiRegionalPool);
    const parsedAmount = ethers.parseUnits(amount, decimals);
    const signerAddress = await signer.getAddress();

    const encodedFunctionCall = abi_interface.encodeFunctionData("borrow", [signerAddress, parsedAmount]);

    const safeTransaction = await createSafeTransaction(poolAddress, "0", encodedFunctionCall);
    return await proposeTransaction(safeTransaction, signer);
}

Now we can finally call the function!

const signer = provider?.getSigner();
 safeBorrowRegionalPool(drawdownAmount.toString(), signer, 
 poolId as string, decimals).then((res) => {
  console.log("Gnosis Safe Transaction created successfully!");
});

So what is happening when we call it? Let's see...

Metamask asks to confirm the transaction (our proposal):

Now we can see that the transaction appeared in the wallet's queue:

You can go even further and retrieve pending transactions from SDK, and confirm it:

const safeTxHash = transaction.transactionHash
const signature = await protocolKit.signHash(safeTxHash)

// Confirm the Safe transaction
const signatureResponse = await apiKit.confirmTransaction(safeTxHash, signature.data)

You can explore full references for all available methods here.

That's all.
Now your web3 application is type-safe and protected by a multi-signature wallet.

Happy coding!

Bug of the month: Cannot convert a BigInt value to a number

Victoria — Tue, 02 Apr 2024 14:17:57 +0000

Hello Everyone,

I encountered a puzzling bug while deploying my web3 application to production. If you're familiar with web3 frontend libraries and browser plugins like MetaMask, you might find this interesting.

The Problem:

Upon deployment, I faced an unexpected error:

Problem

Uncaught TypeError: Cannot convert a BigInt value to a number

It functioned perfectly on my local machine but caused a crash in the live environment.

Let's troubleshoot:

Could it be a configuration problem during deployment?
No, the local build works smoothly.
Perhaps there's an issue with the configuration settings?
No, they're all set correctly.

After a thorough investigation, I discovered the real culprit: browser support!

The error arises because the production build of React doesn't specify browser versions. Instead, it uses default configurations, leading to the error.

The Solution:

Simply update your package.json file as follows:

"browserslist": {
    "production": [
      "supports bigint",
      "not dead"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
}

With this adjustment, your app should run smoothly in production.

Feel free to reach out if you have any questions.

Happy coding!

Bring your TypeScript to the next level

Victoria — Mon, 18 Mar 2024 07:38:29 +0000

With all my love for TypeScript, it has some annoying parts that you have to work around with custom solutions, type-checks, and functions. Which eventually can become very tedious and unmaintainable, and I did not know about any other solution to avoid it.

As a big fan of TypeScript, I am following Matt Pococ, the best TS dev I know, he worked at XState and Vercel and now creates lots of educational content about TS for a living. By exploring his free articles I discovered that he is the creator of a useful library called TS Reset.

It is not an Ad or any sort of promotion. I genuinely like his content and this library specifically.

What the description says:

Without ts-reset:
🚨 .json (in fetch) and JSON.parse both return any
🤦 .filter(Boolean) doesn't behave how you expect
😡 array.includes often breaks on readonly arrays
ts-reset smooths over these hard edges, just like a CSS reset does in the browser.

With ts-reset:
👍 .json (in fetch) and JSON.parse both return unknown
✅ .filter(Boolean) behaves EXACTLY how you expect
🥹 array.includes is widened to be more ergonomic
🚀 And several more changes!

And this is one of the examples how to use it and what it does:

// Import in a single file, then across your whole project...
import '@total-typescript/ts-reset'
// .filter just got smarter!
const filteredArray = [1, 2, undefined].filter(Boolean) // number[]
// Get rid of the any's in JSON.parse and fetch
const result = JSON.parse('{}') // unknown
fetch('/')
  .then((res) => res.json())
  .then((json) => {
    console.log(json) // unknown
  })

Check out official documentation to learn more.
I am going to use this in my future projects by default for sure, it looks awesome and can save lots of time with guaranteed type safety. Try it out and decide if it suits you as well!

Happy coding!

The difference between framework and library in JavaScript

Victoria — Thu, 21 Dec 2023 13:50:36 +0000

In the ever-evolving world of web development, the terms "framework" and "library" are frequently used, but often misunderstood. Grasping the difference is vital for making informed choices in project development. This article aims to demystify these concepts, using React and Next.js as prime examples.

Why bother with understanding?

Understanding whether to use a library or a framework affects how a project is structured, maintained, and scales over time. It influences the level of control developers have over their code and impacts the learning curve for new team members.

Libraries: A Peek into React

What’s a Library?

Think of a library like React as your toolkit. It's a collection of code snippets and components you can use to build your user interface. It doesn't tell you how to build your entire app, just gives you the tools you need.

React’s Role

React is fantastic for creating dynamic, high-performance user interfaces. It's like having a versatile tool that can be adapted to various tasks.

Pros and Cons

Pros: Great flexibility, a strong community, and a wealth of resources.
Cons: It’s just a part of the puzzle. You’ll need other tools for things like state management and routing, etc.

Frameworks: Exploring Next.js

What’s a Framework?

A framework like Next.js is more encompassing. It not only gives you tools but also tells you how to use them. It’s like having a guidebook along with your toolkit.

Next.js’ Superpowers

Built on React, Next.js adds features like server-side rendering and static site generation, which are super helpful for SEO and performance.

Pros and Cons

Pros: Offers a structured approach, built-in features for performance optimization, and is great for SEO.
Cons: Less flexible than using a standalone library. You have to adhere to the framework's rules

I want to quote one interesting thought with a small change from my side:

A note on being “opinionated”
You’ll often hear frameworks and libraries described as “opinionated” or “un-opinionated.” These terms are subjective. They attempt to define the level of freedom a developer has when structuring their code.

Frameworks are more opinionated than not since — by definition — the inversion of control requires a concession of application-design freedom.

Again, the degree to which something is opinionated is subjective. For example, I personally would consider Angular a highly opinionated framework, and NextJS a less-opinionated framework.

Blending React and Next.js

Combining React and Next.js harnesses the flexibility of React with the structured power of Next.js. It’s like having the freedom to experiment with your style while also having a go-to set of perfectly coordinated outfits.

Conclusion

Whether you go for a library like React, or framework like Next.js, or a combination of both depends on your project needs and personal coding style. The library offers flexibility and freedom, perfect for when you want to experiment and create something unique. The Framework, on the other hand, is like having a roadmap, guiding you to build efficient, high-performance web applications with ease.

So, keep exploring, and remember, the best tool is the one that fits your project's needs and your style as a developer. Stay updated and keep learning – the tech world is your oyster! 🌐👩‍💻

References

Anchor scroll at the bottom of the container with dynamic content

Victoria — Fri, 17 Nov 2023 09:14:59 +0000

This article serves as a short tutorial where I'll show you how to easily implement a somewhat tricky functionality.

The case in question is a basic message box, where the latest content should appear at the bottom of the container, with the scroll anchored there.

Here is our problem:

Approach 1 - CSS only

The simplest solution is to use a reversed flex column, which will cause the scroll to stick to the bottom:

Implementation in CSS:

Set the display of the container to flex.
Use flex-direction: column-reverse; to start filling content from the bottom.
Ensure your container has a set height and overflow: auto; to enable scrolling.

Approach 2 - Adding some JavaScript

For automatic scrolling upon the addition of new content, you can tweak the smoothness to create the best user experience:

Implementation in React:

Use the useRef hook to maintain a reference to the container.
Use the useEffect hook to detect changes in the content of the container.
When new content is added, use the scrollIntoView method or adjust the scrollTop property to scroll to the bottom of the container.

Add the following code:

const containerRef = useRef(null);

useEffect(() => {
  const element = containerRef.current;
  if (element) {
    element.scrollTop = element.scrollHeight;
  }
}, [messages]); // assuming 'messages' is the state holding the chat content

Conclusion:

Now you know two of the simplest ways to achieve a bottom-anchored scroll with dynamic content. If you have other methods or suggestions, please feel free to share them with me!

You can also combine the two approaches mentioned and experiment with the smoothness of the scroll. You can find an example app here.

Happy coding and see you soon!