DEV Community: Seasoned

How to disable a link in React Router 7 / Remix

Felipe Freitag Vargas — Thu, 09 Jan 2025 18:53:04 +0000

Today, I joined a discussion on the Remix Discord about how to block a Link component when a certain condition is true.

A simple solution is to use a ternary to render either the Link or a disabled button styled to look identical. You can abstract it into a reusable component. I've used this pattern at Seasoned many times 😁

{disabled ? (
  <button
    className="bt bt-blue" // add the disabled appearance as needed
    disabled={disabled}
  >
    <CheckIcon /> Go!
  </button>
) : (
  <Link
    to={`....`}
    className="bt bt-blue"
    preventScrollReset
  >
    <CheckIcon /> Go!
  </Link>
)
}

Enjoy!

Create admin panels for Postgres in 3 short steps

Felipe Freitag Vargas — Tue, 19 Nov 2024 20:19:00 +0000

With Flashboard, you can create admin panels for your Postgres Databases in an instant.

Modern look
Great UX
No need to build the UI
Light and dark mode (it follows your OS settings 😉)

Let's go from scratch:

1. Create an account

Enter your email and choose a strong password.

The password will encrypt your DB connection strings, so make sure you'll remember it!

Complete your (very short) profile

2. Connect a database

Choose "connect my real database"

If you want to look around first, go with "play with a demo".

Find your connection string and paste it.

If needed, check out this helpful guide to connection URLs.

Optional: select namespace.

Most of the times, it will be "public". If there's only one namespace, you'll go directly to the next step.

Choose a panel name and slug.

You need to confirm the same password you used to sign in. It will encrypt the connection URL. Only you have access to your DB data.

You're connected and ready to build!

3. Build your first tab

Let's create our tab. All your relations are already available, pick one from the selector.
For this example, let's go with "coupons".

Almost there. Let's choose some fields!

You can choose what fields to list, reorder the columns with drag-and-drop, pick a default column to order records by.

Looking good! We already have a read-only list of coupons, complete with search, filters and pagination.

Let's add some CRUD operations to it. Click on "Build" to see the options.

Table settings: what appears on the list. We already configured it when creating the tab, but you can change it when needed.
Detail settings: enable it if you want users to see the details of a row. Details can show data from columns and relations.
New item settings: enable it if users should be able to create new records. You can choose what fields to show on the form.
Edit item settings: enable it if users should be able to edit records. You can choose what fields to show on the form.
Allow deleting: toggle it if users should be able to delete records.

You don't need to configure everything at once. Each feature is disabled by default to prevent mistakes like "wooops, I forgot to disable XYZ".

From here on, you can use it as-is, create more tabs, or share panels with team members.

That's all you need to have an up-and-running Postgres admin panel.

Please let me know what you think!

Google Analytics (GA4) implementation with React - Remix example

Felipe Freitag Vargas — Fri, 01 Nov 2024 19:28:47 +0000

If you want to configure GA4 with code instead of using Tag Manager, here's how I did it. The example uses Remix, but it should be very similar with any React framework.

I've spent quite a few hours configuring GA4 with React, plus a cookie banner and consent mode. I hope it'll be faster next time thanks to these notes. I'll separate the consent mode stuff into another post to keep things simple.

Disclaimer: there might still be issues here, I'll update the post as I find them. But the tag is being recognized and there are events firing.

The gtag code

After creating your Google Analytics account, property and stream, at some point you'll see this code:

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-C33KHSZBKZ"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-.........');
</script>

It has two parts:

Loading the gtag.js script: the async one
Configuring the datalayer array and gtag function

They are NOT the same thing! If you don't need to add a cookie banner to get the user consent, you don't need to worry about it. But if you need to comply with the GDPR or with Brazil's LGPD, you will need to understand a bit more. That will be the theme of a future post.

GA hook

Let's go with the simple implementation, a custom hook.

This hook can be called multiple times if needed, and it will ensure the initialization runs only once. It has a convenient return to let you know if it is ok to use GA.

const useGoogleAnalytics = (
  gaMeasurementId: string | undefined,
) => {
  const [isInitialized, setIsInitialized] = useState(false)
  useEffect(() => {
    const loadScript = () => {
      // gaMeasurementId is optional so not all devs need it to run the app
      if (!window.gtag && gaMeasurementId) {
        // Create the script element
        const script = document.createElement('script')
        script.src = `https://www.googletagmanager.com/gtag/js?id=${gaMeasurementId}`
        script.async = true
        // Append the script to the document
        document.head.appendChild(script)
        // Initialize gtag when the script is loaded - this could be done before
        script.onload = () => {
          window.dataLayer = window.dataLayer || []
          function gtag() {
            window.dataLayer.push(arguments)
          }
          window.gtag = gtag
          window.gtag('js', new Date())
          window.gtag('config', gaMeasurementId, {
            debug_mode: false, // I keep this here to remember where to toggle debug
          })
          // Mark as initialized
          setIsInitialized(true)
        }
      } else {
        // gtag is already available, mark as initialized
        setIsInitialized(true)
      }
    }
    loadScript()
  }, [gaMeasurementId, analyticsAnonymousId])
  return isInitialized
}

Caveat

This code creates a single script that loads GA immediately; if you need to comply with some privacy laws, you can't do it this way! The external script can only be loaded after getting the user's consent. I'll show how I did it in a future post.

Usage

Here's an example of how to track page views:

// root.tsx
export async function loader({ request, params }: LoaderFunctionArgs) {
  return json(
    {  
      gaMeasurementId: process.env.GA_MEASUREMENT_ID, // or however you manage and protect your env vars. Not strictly necessary, but I prefer to manage all of them from the server
    },
  )
}

function GoogleAnalytics() {
  const location = useLocation()
  const { gaMeasurementId } =
    useLoaderData<typeof loader>()

  const isGaInitialized = useGoogleAnalytics(
    gaMeasurementId,
    analyticsAnonymousId
  )

  useEffect(() => {
    if (isGaInitialized && gaMeasurementId) {
      window.gtag('config', gaMeasurementId, {
        page_path: location.pathname,
      })
    }
  }, [isGaInitialized, location, gaMeasurementId])
  return null
}

export default function Component() {
  return (
    <>
      <GoogleAnalytics />
      <Outlet />
    </>

Function to track events

You can use similar code to register any client-side events or user properties you might need. just call window.gtag('event', ...) following Google's API.

Here's a reusable example:

// analytics.client.ts

import type { SnakeCase } from 'string-ts'

function trackClientAnalyticsEvent<T extends string>(
  eventName: T & SnakeCase<T>, // GA only supports snake_case event names. Let's enforce it at type-level to make life easier
  properties?: Record<string, unknown>
) {
  return window.gtag && window.gtag('event', eventName, properties)
}

export { trackClientAnalyticsEvent }

In my case, I'm only using that function to register a few clicks, since most events will be registered server-side.

...  
<Link
  to={`...`}
  onClick={() =>
    trackClientAnalyticsEvent('user_clicked_this_link')
  }
>
  Call To Action!
</Link>
...

This should be enough to get you started. Now you can go on to figure out consent mode and server-side events with the measurement api. Good luck!

Navigating Careers

Angelo Dias — Tue, 17 Sep 2024 15:00:00 +0000

I was invited by Seasoned to work towards the growth of a new enterprise, and it's been a challenging experience.

Writing, per se, has never been something I had a hard time with (you'll understand why in a few paragraphs), but describing how it is to work with something I'm not quite experienced in makes me shiver.

It's not the first time I’ve moved careers — and it won't be the last — and I want to share a bit of how things are going, and how I moved from journalism to graphic design, then to coding, then to tech-leading, then to growth marketing.

First, some context.

A proud generalist

My professional life can be summarized as filling the gaps.

I started studying journalism in 2009 — I loved writing and taking pictures — but soon noticed every journalism student could write (better than me, even), but not one of them could put the text + photos on a pretty page. I saw a gap, I studied it, and I filled it. I finished college as a graphic journalist, a position that didn't exist and that I made for myself. This landed me a job at Latin America's biggest newspaper, Folha de S.Paulo.

Then, as a full-time graphic designer — doing layout, infographics, and the occasional journalistic writing — I realized everyone had a great taste for print, but they had a terrible understanding of the internet and how things could be displayed there. I started studying simple HTML and CSS, then moved to JavaScript, and before I knew it, I was, again, filling a gap. My new job had a simple description (and a fairly complicated execution): to build tools and ways of moving print material to the internet in a beautiful, usable, and even interactive way.

The designers couldn't code. I could. Soon I was not only moving stuff from print to the web but doing stuff web first — damn, I fought to do stuff mobile first! People liked working with me because I knew journalism, I knew design, and I knew the internet and how to work around it.

Then, after moving on from Folha, I started working with heavy-duty programmers and, guess what? Found a gap. They were great coders, way better than I ever was, but terrible communicators. They could make any computer do their bidding, but trembled and sweated in a client meeting. They had conflicts while talking to product people, and a real struggle understanding how the design process worked.

They needed someone that had the technical knowledge, understood how designers work, and also had a love for communication. Well, I could absolutely fill this gap. So I did it.

Since then, this has been my (very hard to advertise) job description — a proud generalist that links developers, designers, and non-technical people. A kind of tech lead that's not just tech. I would code, of course, but mainly get the team processes oiled up so they could do what they knew best, and everyone could be on the same page. I put this on the first part of my website, so that every recruiter could see it.

Movin' on up

After my last project ended, Daniel Weinmann (Seasoned's CEO) called me and invited me to a new — and novel — position. I was coding for the last, hmm, 8 or 9 years, but he wanted something more. When I worked for him as a coder some years ago, he always said stuff like, "I think you're more than just a programmer, but right now we don't have any way of testing that — because the job requires a coder and you are a coder." This time, he had a great team of coders — like, really, people with amazing skills. What he didn't have was someone with the knack for tackling new things, studying stuff from scratch, and doing their best to communicate all that.

For him, I was the guy. He insisted, more than once, that I should try to face this new challenge.

If there's one person I deem persuasive, it's Daniel. I accepted this role and here I am, now, learning a bunch of stuff, going from zero to hero, and doing my best to share all of that. My new position? Head of Growth, someone to tackle all obstacles in growing a new product they are working hard on.

This is not a publicity post, so I won't talk much about what we're building — if you want to check it out, you can visit Flashboard's website — but this is an introduction to whatever will come next. This is the first of (hopefully) a series of articles on how things have been going and what I've been learning.

I hope that, if you find yourself in the same career-moving journey, you find this at least interesting. Let me know if my path has resonated with you below, in the comments. I would love to hear about it.

5 Common Pain Points in PostgreSQL

Angelo Dias — Tue, 10 Sep 2024 18:30:00 +0000

Before building Flashboard (our PostgreSQL admin app), our development team had struggled with a lot of stuff that you might've encountered in your PostgreSQL journey.

I'm not just talking about tracking foreign keys or building extra-complex SQL queries, but also finding a way to make data editable for non-technical folks without needing to build an entire new software to support the main thing — after all, the main thing is where the core of the work should be, right, Project Owners?

Well, here are the most common pain points in PostgreSQL (and, being honest, a bit about how Flashboard solves them at the end of the article).

1. Time-Consuming Query Creation

Building SQL queries is fun — until it isn't. It's like RegEx — you get that big, broad smile when it works, but after the 10th time you just hit ChatGPT and ask it to build it for you. It becomes tiresome, error-prone, and, mainly, time-consuming. The f-in-fun becomes f-in-frustration when you have to redo it all because you got a new client.

2. Navigating Foreign Keys

A good PostgreSQL database probably has a lot of foreign keys — and that's a green flag in architecture design... or at least that's what the architects say. When the developers need to navigate the schema, jumping from one related table to the other, things get confusing — you gain database-performance in exchange for developer-speed.

3. Handling JSON Data

I know the feeling of working with JSON in PostgreSQL. Saving data this way saves time and space, but it's waaaay too difficult to query it. You need special operators and functions, and when you’re working with nested structures, it’s easy to mess something up.

4. Creating Secure Interfaces for Non-Tech Teams

You might need to give access to the database to non-technical users — sometimes there's no time to build a feature in the main app or there's no proper admin panel setup for them. This is hard work — it’s not just about making sure they don’t break anything, but also ensuring sensitive data stays locked down. Building a secure admin interface means juggling encryption, access control, and usability — when you notice it, you are building a secondary software as hard to maintain as the primary one.

5. Scaling Custom Admin Solutions

Continuing from the last topic: what starts as a simple admin panel for a small team can quickly balloon into a mess as your user base or data grows. Suddenly, you’re dealing with performance issues, broken queries, and features that no longer work as expected. Scaling a custom solution is a beast of a task, and unless you planned for it from day one, you’ll probably need to rebuild a good chunk of it down the road.

It would be awesome if a tool existed to solve all of these problems, right?

(read the next sentence as if a TV host from the 80s was saying it)

Well, I have some good news! Flashboard to the rescue!

(ok, serious now)

We got tired of sidetracking our main things to build complicated admin panels, so we made admin panels our main thing. I know this next paragraph might sound a little sale-y, but I promise we're just devs recommending good software for other devs. Yeah, we believe in what we're building — and you know this feeling.

Flashboard instantly generates admin panels, so no more hand-coding complex queries. It simplifies foreign key navigation and JSON querying, so you can breathe easy. Security? Encrypted credentials and tailored user access are built in. And it’s scalable, so whether you're a startup or scaling up, it’ll grow with you.

(now, back with the TV host's voice)

Say goodbye to PostgreSQL admin pain points and focus on what you do best — building awesome stuff.

Comment below what other pain points you find in PostgreSQL! We're totally not going to add that to our backlog 😉

Introducing Flashboard: Instant Admin Panels for PostgreSQL

Daniel Weinmann — Mon, 02 Sep 2024 18:05:27 +0000

Have you noticed that building admin panels and internal tools is often neglected in favor of user-facing features? There's always too much to build and too little dev time, so it's understandable.

But at Seasoned, we hate offering a subpar experience to our clients' internal team while providing an amazing UX to the final users. Yet, we also refuse to make our clients pay for a custom admin panel when the end-user is the priority.

That's how Flashboard was born. We made building admin panels instantaneous so we don't have to choose between internal teams and the end user. And now that we have it, we decided to share it with you all!

Flashboard is available today for anyone to use. Connect to your PostgreSQL database, select the tables and fields you want to manage, and that's it! You're up and running within seconds.

Check out this quick demo:

I like what I see, but is it safe?

Yes! Your database credentials are encrypted with a key only you own. Even our team can't access them, let alone potential attackers.

OK, but can I test it without connecting to my real database?

Yes, you can. There's an option to "Create a demo panel" to play around with a demo database.

Nice, how much does it cost?

It's free! 🎁

And we plan to maintain the free plan in the long run. We'll explore charging for advanced features soon, but right now everything is free.

Play around with it at getflashboard.com

Molecules of business logic from tiny atoms

Daniel Weinmann — Tue, 25 Jun 2024 17:32:07 +0000

Some people asked me how to design their business logic after reading my article on keeping your business code separate from the rest. Here's an example of how we do it.

Imagine we have an online shop with a page for our Magical T-Shirt. On that page, we want to show all the product variants (small, medium, large) plus product information, like name. Your customer has applied a coupon code to their cart, so we must also show the discounted price.

Functions with a verb in their name

At Seasoned, we prefer functions with verbs in their name to classes and objects. So the first thing we'll do is create a function called getProductPageData that gathers all the information we need.

It will look completely different by the end of this article, but this is how it starts:

function getProductPageData(productId: string, couponCode: string) {
  // This would come from your database
  const product = { id: productId, name: 'Magical T-Shirt' }

  // This would come from your database
  const variants = [
    { productId, sku: 'small', name: 'Small', price: 8.99 },
    { productId, sku: 'medium', name: 'Medium', price: 10.99 },
    { productId, sku: 'large', name: 'Large', price: 12.99 },
  ]

  // This would come from your database
  const coupon = { code: couponCode, discount: 10 }

  return {
    product,
    coupon,
    variants: variants.map((variant) => ({
      ...variant,
      priceWithDiscount: variant.price * (1 - coupon.discount / 100),
    })),
  }
}

A folder dedicated to business logic

This code lives in a business folder and it should not have any knowledge about the framework you're using. Ideally, it should work as well for a mobile app as it does for a website. All the code dealing with platform-specific APIs or framework-specific implementation should live elsewhere.

Dealing with errors

Our getProductPageData function could fail. For instance, every query we make to our database can throw an error. So far, our code does nothing to deal with that.

Instead of adding multiple try/catch statements, we'll establish a pattern to deal with exceptions. For that, let me introduce you to Composable Functions, a library we created to make function composition easy and safe.

Composable functions do much more, but they help us deal with errors by doing the try/catch for us and returning the result in a type-safe way. Imagine this silly function call:

const getLength = (text: any) => text.length

getLength(null)
// TypeError: Cannot read properties of null (reading 'length')

If you wrap it with composable, it will never throw an error. Instead, it will return the result with the exception, like:

const getLength = composable((text: any) => text.length)

const result = await getLength(null)
// result equals
// {
//   success: false,
//   errors: [<Error object>]
// }

If it succeeds, it will return the result of the function inside data:

const getLength = composable((text: any) => text.length)

const result = await getLength('abc')
// result equals
// {
//   success: true,
//   data: 3,
//   errors: []
// }

This pattern forces us to remember to deal with errors. To access result.data, we must first check if result.success is true. Otherwise, TypeScript will give us an error.

This is how our getProductPageData function looks like when wrapped with composable:

const getProductPageData = composable(
  (productId: string, couponCode: string) => {
    // This would come from your database
    const product = { id: productId, name: 'Magical T-Shirt' }

    // This would come from your database
    const variants = [
      { productId, sku: 'small', name: 'Small', price: 8.99 },
      { productId, sku: 'medium', name: 'Medium', price: 10.99 },
      { productId, sku: 'large', name: 'Large', price: 12.99 },
    ]

    // This would come from your database
    const coupon = { code: couponCode, discount: 10 }

    return {
      product,
      coupon,
      variants: variants.map((variant) => ({
        ...variant,
        priceWithDiscount: variant.price * (1 - coupon.discount / 100),
      })),
    }
  },
)

Extracting smaller functions

Over time, as we get to know our needs for reusing specific parts of code, we start to extract smaller functions. However, be careful not to extract them too early, as the wrong abstraction is worse than code duplication. In other words, avoid hasty abstractions and only extract smaller functions when the right abstraction emerges.

In our example, let's imagine we have to get product info in multiple places of our codebase. We also need to list a product's variants, get coupon info, and apply a discount to a list of variants on several occasions for different business purposes.

With that, the following tiny atoms of business logic emerged:

const getProduct = composable(({ productId }: { productId: string }) => {
  // This would come from your database
  return { id: productId, name: 'Magical T-Shirt' }
})

const getVariants = composable(({ productId }: { productId: string }) => {
  // This would come from your database
  return [
    { productId, sku: 'small', name: 'Small', price: 8.99 },
    { productId, sku: 'medium', name: 'Medium', price: 10.99 },
    { productId, sku: 'large', name: 'Large', price: 12.99 },
  ]
})

// Usually, this type would come from your database lib
// You don't need to understand it now, but it's the type for
// an individual variant.
type Variant = UnpackData<typeof getVariants>[number]

const getCoupon = composable(({ couponCode }: { couponCode: string }) => {
  // This would come from your database
  return { code: couponCode, discount: 10 }
})

const applyDiscountToVariants = composable(
  ({ variants, discount }: { variants: Variant[]; discount: number }) =>
    variants.map((variant) => ({
      ...variant,
      priceWithDiscount: variant.price * (1 - discount / 100),
    })),
)

Aside

— Why are we using a single object as the argument for our small functions? Why is it { productId }: { productId: string } instead of simply productId: string?

— Thank you for noticing! We'll get to that soon :)

Using our atoms

Now let's rewrite getProductPageData to use these atomic functions instead of duplicating their code. An initial version looks like this:

const getProductPageData = composable(
  async (productId: string, couponCode: string) => {
    // Notice that composable functions are always async
    const productResult = await getProduct({ productId })

    if (!productResult.success) {
      throw new Error('Could not find product')
    }

    const product = productResult.data

    const variantsResult = await getVariants({ productId })

    if (!variantsResult.success) {
      throw new Error('Could not find variants')
    }

    const variants = variantsResult.data

    const couponResult = await getCoupon({ couponCode })

    if (!couponResult.success) {
      throw new Error('Could not find coupon')
    }

    const coupon = couponResult.data

    return { product, coupon, variants }
  },
)

Well, it's not looking that good yet. The good part is that composable functions force us to deal with error cases, so we had to make all the checks above. But there is a better way. If we rewrite the function to use fromSuccess, it looks much cleaner:

const getProductPageData = composable(
  async (productId: string, couponCode: string) => {
    const product = await fromSuccess(getProduct)({ productId })
    const variants = await fromSuccess(getVariants)({ productId })
    const coupon = await fromSuccess(getCoupon)({ couponCode })

    return { product, coupon, variants }
  },
)

It's starting to look better! fromSuccess does the check and throws the error for us when a function fails.

Going molecular

We could consider our work done with the code we have so far. It is doing what it is supposed to do, it's broken down into tiny atoms of business logic, and it's dealing with errors properly.

But we believe there's an even better way to bond our atoms. Right now, they're not truly bonded. They are being used separately, one at a time, and we're manually piecing together their results. If we use function composition, we can bond our atoms to create molecular functions.

Before we get back to our online shop, let's go over the basics of composition with our silly getLength example from the beginning of the article.

Imagine you want to get the length of a string but return it as a string. This is the result we're expecting:

const result = await getLengthAsString('abc')
// result equals
// {
//   success: true,
//   data: '3', ⬅️ Notice this is a string 👀
//   errors: []
// }

Our initial implementation of getLengthAsString could be:

const getLengthAsString = 
  composable((text: string) => String(text.length))

But we already have a numberToString composable function that converts a number to a string, so we want to use it:

const numberToString = composable((number: number) => String(number))

const getLengthAsString = composable((text: string) =>
  fromSuccess(numberToString)(text.length),
)

Now it's time to add composition. For composing functions, we need combinators. Combinators are functions that receive composable functions as input and return another composable function.

We're going to talk about a few combinators in this article, and the first one is pipe. pipe creates a chain of composable functions that will be called in sequence, always passing the result of the last function called as the input to the next.

Here's our getLenghAsString using pipe:

const getLength = composable((text: string) => text.length)
const numberToString = composable((number: number) => String(number))
const getLengthAsString = pipe(getLength, numberToString)

const result = await getLengthAsString('abc')
// result equals
// {
//   success: true,
//   data: '3', ⬅️ It is a string 🎉
//   errors: []
// }

Why is it better this way?

There are a few reasons why the version with pipe is better than the one with fromSuccess:

First, it's easier to change. Want to return both the numeric and the string versions of the result? Just add a map to the composition:

const getLengthAsStringAndNumber = pipe(
  getLength,
  map(numberToString, (result, input) => ({
    asNumber: input,
    asString: result,
  })),
)

const result = await getLengthAsStringAndNumber('abc')
// result equals
// {
//   success: true,
//   data: { asNumber: 3, asString: '3' },
//   errors: []
// }

Notice how we didn't have to change anything in our atomic functions. They remained the same. Only the composition (our molecule) changed.

Second, it's easier to test. You can write one set of tests for getLength, another one for numberToString, and just enough tests on getLengthAsString to make sure the composition worked.

Lastly, all compositions are type-safe from end to end. For example, if we try to pipe a function that returns a string into a function that expects a number, the composition will fail.

Back to our online store

Now it's time to create our getProductPageData with compositions. Here's one way of doing it:

const getRawData = collect({
  product: getProduct,
  variants: getVariants,
  coupon: getCoupon,
})

const getRawDataWithDiscount = map(getRawData, (data) => ({
  ...data,
  discount: data.coupon.discount,
}))

const getRawDataWithDiscountedVariants = sequence(
  getRawDataWithDiscount,
  applyDiscountToVariants,
)

const getProductPageData = map(
  getRawDataWithDiscountedVariants,
  ([{ product, coupon }, variants]) => ({ product, coupon, variants }),
)

It looks daunting, I know. But let's walk through it together, one step at a time.

First, we collect all the raw data we need on getRawData. This function receives { productId: string; couponCode: string } and returns an object with product, variants, and coupon.

Then we map the raw data on getRawDataWithDiscount. This function receives the same { productId: string; couponCode: string } input and returns an object with product, variants, coupon, and discount.

The reason we add the discount to the root of our object is because our applyDiscountToVariants takes a list of variants and the discount as input, not the coupon. In the real world, it's very common to have an atomic function that does what you need but require you to "massage your input" a little in before you can call it.

Next, we sequence getting the raw data with discount and applying the discount to our variants on getRawDataWithDiscountedVariants. It also receives { productId: string; couponCode: string }. Then, it returns a tuple with the result of getRawDataWithDiscount as the first element, and the result of applyDiscountToVariants as the second.

Finally, we map the result of getRawDataWithDiscountedVariants to get rid of the tuple and return an object with the final data structure we want on getProductPageData.

Calling our function

Now you can call your business function from the outside world. This usually means calling it from inside a controller, a loader, or any other method for gathering data.

const result = await getProductPageData({
  productId: '123',
  couponCode: '10OFF',
})

if (!result.success) {
  // 🚨 Any errors thrown in any of the composed functions
  // will be on result.errors
  result.errors.forEach(error => console.log(error))

  return
}

console.log(result.data)

// {
//   product: { id: '123', name: 'Magical T-Shirt' },
//   coupon: { code: '10OFF', discount: 10 },
//   variants: [
//     {
//       productId: '123',
//       sku: 'small',
//       name: 'Small',
//       price: 8.99,
//       priceWithDiscount: 8.091000000000001
//     },
//     {
//       productId: '123',
//       sku: 'medium',
//       name: 'Medium',
//       price: 10.99,
//       priceWithDiscount: 9.891
//     },
//     {
//       productId: '123',
//       sku: 'large',
//       name: 'Large',
//       price: 12.99,
//       priceWithDiscount: 11.691
//     }
//   ]
// }

As you can see, this version of getProductPageData receives an object with the product id and the coupon code instead of two arguments like we had on our initial version.

We commonly do that because it makes it easier to compose the functions. That's why our atomic functions also receive an object. For example, on getRawDataWithDiscountedVariants we can get the result of getRawDataWithDiscount and pass it to applyDiscountToVariants without transforming it, even if returns an object with more keys than what applyDiscountToVariants needs.

If our atomic functions expected multiple arguments instead of an object, we could transform our data at every stage to be exactly what the next function needs. But I think this is a good pattern that leads to more readable compositions.

Thinking in composition

It takes a while to adjust our thought process to think of compositions instead of a sequence of function calls and if statements. To be honest, I'm not totally there yet. But the more I use composition, the more I write code that's maintainable and easy to test.

It will take you and your team some time and learning curve but once you start thinking in compositions, you can skip the intermediate functions above and write your compositions inline:

const getProductPageData = map(
  sequence(
    map(
      collect({
        product: getProduct,
        variants: getVariants,
        coupon: getCoupon,
      }),
      (data) => ({
        ...data,
        discount: data.coupon.discount,
      }),
    ),
    applyDiscountToVariants,
  ),
  ([{ product, coupon }, variants]) => ({ product, coupon, variants }),
)

That's it. I hope this method of writing business code helps you give business logic the priority it deserves and create more resilient codebases 🤓

Let me know how it works for you!

Type-Safe Env Vars With Vite - A Modern Approach

Gustavo (Guga) Guichard — Fri, 14 Jun 2024 12:49:46 +0000

This post is a revamp of my previous one where I showed you how to use Zod and TS to create a type-safe environment variable system that works on both the client and server.

If you haven't read it yet, go check it out. It provides context for this post.

It's been over 18 months, and things move fast in JS land. I decided to revisit the code, update Remix itself, leverage Vite's Environment Variables, and use my new friend - ArkType - to parse the environment variables this time.

If you only want to see the code, check out the updates' diff here.

The Gist of Changes

By updating Remix from 1.7 to 2.9 and using Vite we can now use import.meta.env so we don't need to manually load the environment variables and expose them to the window anymore. That update reduces a lot of shenanigans from the previous approach.

I'm also switching from Zod to ArkType, introducing a makeTypedEnvironment helper to streamline handling environment variables in both server and client environments. Additionally, there are a few optimizations I'll be pointing out through the post.

The New `makeTypedEnvironment` Helper

This helper is designed to work seamlessly in both server and client environments, making it a versatile tool. It can handle different parsers, avoid mutating the original objects, and transform environment variable keys to camelCase.

Let's first start by making it work in multiple environments.

// lib/index.ts
// This function creates a typed environment by accepting a Zod schema parser.
function makeTypedEnvironment<T>(schema: { parse: (v: unknown) => T }) {
  // The returned function applies the schema parser to the provided environment variables.
  return (args: Record<string, unknown>): T => schema(args)
}

We can use it in both server or client:

import { z } from 'zod'
import { makeTypedEnvironment } from '~/lib'

// Define the environment Zod schema.
const envSchema = z.object({
  MODE: z.enum(['development', 'test', 'production']).default('development'),
})
// Create the environment parser using the makeTypedEnvironment helper.
const getEnv = makeTypedEnvironment(envSchema)

// Server usage: parse environment variables from process.env
const env = getEnv(process.env)
//    ^? { MODE: 'development' }

// Vite client-side env vars usage: parse environment variables from import.meta.env
const env = getEnv(import.meta.env)
//    ^? { MODE: 'development' }

You could also use getEnv(window.ENV) if you are not using Vite, just follow the instructions on the previous post.

Accepting Different Parsers and Preventing Mutations

To use it with ArkType, I'll make it accept a more generic parser as an argument.

// Function to create a typed environment that accepts a generic parser.
function makeTypedEnvironment<T>(schema: (v: unknown) => T) {
  // Spread the arguments to clone them, avoiding mutations to the original object.
  return (args: Record<string, unknown>): T => schema({ ...args })
}

The args was cloned above to avoid mutations. Some parsers, like ArkType, mutate the object (🥲) passed to them. This way, we ensure the original object is not changed.

Now we can use that function with both Zod and ArkType.

import { z } from 'zod'
import { type } from 'arktype'
import { makeTypedEnvironment } from '~/lib'

// Define the environment schema using Zod.
const envZodSchema = z.object({
  MODE: z.enum(['development', 'test', 'production']).default('development'),
})
// Create the environment parser for Zod.
const getZodEnv = makeTypedEnvironment(envZodSchema.parse)

// Define the environment schema using ArkType.
const envArkSchema = type({
  MODE: ['"development"|"test"|"production"', '=', 'development'],
})
// Create the environment parser for ArkType.
const getArkEnv = makeTypedEnvironment((d) => envArkSchema.assert(d))

Perfect!

Transforming the Env Vars to `camelCase`

For convenience, I'll use string-ts to transform the env vars to camelCase, making the usage feel more like JS code..

import { camelKeys } from 'string-ts'

// Function to create a typed environment with camelCase transformation.
function makeTypedEnvironment<T>(schema: (v: unknown) => T) {
  // Apply camelCase transformation to the parsed environment variables.
  return (args: Record<string, unknown>) => camelKeys(schema({ ...args }))
}

Now let's use the original public schema from the previous post and see how it looks like:

// environment.server.ts
import { type } from 'arktype'
import { makeTypedEnvironment } from '~/lib'

// Define the environment schema using ArkType.
const publicEnvSchema = type({
  // We prefix the keys with VITE_ to expose them in the client bundle.
  VITE_GOOGLE_MAPS_API_KEY: 'string',
  VITE_STRIPE_PUBLIC_KEY: 'string',
})
// Create the environment parser with camelCase transformation.
const getEnv = makeTypedEnvironment((d) => envSchema.assert(d))
// Parse environment variables from process.env
const env = getEnv(process.env)
//    ^? { viteGoogleMapsApiKey: string, viteStripePublicKey: string }

By leveraging string-ts, I’ve transformed the environment variable keys to camelCase, making them more intuitive to use in JavaScript code. This transformation is applied at both type and runtime levels.

Getting rid of the `VITE_` prefix

You may have noticed we are adding the VITE_ prefix to those variables that we want to be exposed to the client bundle through Vite's import.meta.env object. That comes from the Vite API and you can change the prefix if you want.

We can go further and remove that prefix as follows:

import { camelKeys, replaceKeys } from 'string-ts'

function makeTypedEnvironment<T>(schema: (v: unknown) => T) {
  // Apply replaceKeys before camelCase transformation to the parsed environment variables.
  return (args: Record<string, unknown>) =>
    camelKeys(replaceKeys(schema({ ...args }), 'VITE_', ''))
}

Check out the result:

// environment.server.ts
import { type } from 'arktype'
import { makeTypedEnvironment } from '~/lib'

// Define the environment schema using ArkType.
const publicEnvSchema = type({
  VITE_GOOGLE_MAPS_API_KEY: 'string',
  VITE_STRIPE_PUBLIC_KEY: 'string',
})
// Create the environment parser with camelCase transformation.
const getEnv = makeTypedEnvironment((d) => envSchema.assert(d))
// Parse environment variables from process.env
const env = getEnv(process.env)
//    ^? { googleMapsApiKey: string, stripePublicKey: string }

Much better!

Last Optimization: Caching

To enhance performance, I’ve implemented caching in the makeTypedEnvironment function. This prevents the schema from being reparsed every time the environment variables are accessed, resulting in faster and more efficient code execution.

This change was inspired by a comment from the first post.

import type { CamelKeys, ReplaceKeys } from 'string-ts'
import { camelKeys, replaceKeys } from 'string-ts'

// Function to create a typed environment with caching.
function makeTypedEnvironment<T>(schema: (v: unknown) => T) {
  // Instantiate a cache to store parsed environment variables.
  let cache: CamelKeys<ReplaceKeys<T, 'VITE_', ''>>

  return (args: Record<string, unknown>) => {
    // If the environment variables are already cached, return the cached value.
    if (cache) return cache

    // Otherwise, parse the environment variables and transform the keys
    const withoutPrefix = replaceKeys(schema({ ...args }), 'VITE_', '')
    const camelCased = camelKeys(withoutPrefix)
    cache = camelCased
    return cache
  }
}

You can add console.log around to see the cache in action.

Extending Schemas

We can leverage ArkType’s ability to extend schemas, simplifying the process of creating a superset of the public schema.

// environment.ts
import { type } from 'arktype'

// Define the public environment schema.
const publicEnvSchema = type({
  VITE_GOOGLE_MAPS_API_KEY: 'string',
  VITE_STRIPE_PUBLIC_KEY: 'string',
})
// Extend the public schema to create the full environment schema.
const envSchema = type(publicEnvSchema, '&', {
  MODE: ["'development'|'production'|'test'", '=', 'development'],
  SESSION_SECRET: 'string',
  STRIPE_SECRET_KEY: 'string',
})
// Create the environment parsers for public and full schemas.
const getPublicEnv = makeTypedEnvironment((d) =>
  publicEnvSchema.onUndeclaredKey('delete').assert(d)
)
const getEnv = makeTypedEnvironment((d) => envSchema.assert(d))

This approach can also be done using Zod's .extend method for comparison.

import { z } from 'zod'

// Define the public environment schema.
const publicEnvSchema = z.object({
  VITE_GOOGLE_MAPS_API_KEY: z.string(),
  VITE_STRIPE_PUBLIC_KEY: z.string(),
})
// Extend the public schema to create the full environment schema.
const envSchema = publicEnvSchema.extend({
  MODE: z.enum(['development', 'production', 'test']).default('development'),
  SESSION_SECRET: z.string(),
  STRIPE_SECRET_KEY: z.string(),
})
// Create the environment parsers for public and full schemas.
const getPublicEnv = makeTypedEnvironment(
  publicEnvSchema.onUndeclaredKey('delete').parse,
)
const getEnv = makeTypedEnvironment(envSchema.parse)

We are using ArkType's .onUndeclaredKey('delete') to remove undeclared keys from the object so we avoid exposing secrets to the client.

ArkType's default strategy is called Loose Assertion while Zod will omit undeclared keys by default - Safe Parsing.

Et Voilà

Thanks to Vite, we can go ahead and remove a bunch of code from the previous post.

Now, anywhere in your code, you can access the public environment variables in a type-safe way:

// app/routes/index.tsx
import { getPublicEnv } from '~/environment'

export default function Index() {
  function showStripeKey() {
    alert(
      `Stripe key on the client: ${
        getPublicEnv(import.meta.env).stripePublicKey
      }`,
    )
  }

  return (
    <div>
      <h1>
        GMAPS key on the server and client:{' '}
        {getPublicEnv(import.meta.env).googleMapsApiKey}
      </h1>
      <p>
        <button onClick={showStripeKey}>Alert Stripe key</button>
      </p>
    </div>
  )
}

That's It

Now we have a faster, solid, type-safe environment variable system that works on both the client and server environments. And with a great DX:

Another benefit of this approach is that you don't need to keep an .env.sample file as you can always check the environment.ts file to know what environment variables are required.

We also learned how to create functions that accept different parsers, which is a good practice, especially for library authors.

I'd love to hear your thoughts on this. If you have any questions or suggestions, please leave a comment below.

Update: `make-typed-env` on npm

Since writing this article, I've extracted the makeTypedEnvironment pattern into a standalone library: make-typed-env.

It builds on the same ideas but with a few improvements:

Works with any schema library via Standard Schema — Zod, ArkType, Valibot, and more
Key transformation is a parameter — pass camelKeys, replaceKeys, or any function instead of hardcoding the behavior - Zero runtime dependencies — just 0.5 KB

npm install make-typed-env

import { makeTypedEnv } from "make-typed-env"
import { camelKeys, replaceKeys } from "string-ts"
import { z } from "zod"

const getEnv = makeTypedEnv(
  z.object({
    VITE_STRIPE_PUBLIC_KEY: z.string(),
    VITE_SENTRY_DSN: z.string().optional(),
  }),
  (parsed) => camelKeys(replaceKeys(parsed, "VITE_", "")),
)

const env = getEnv(import.meta.env)
// env.stripePublicKey → string
// env.sentryDsn       → string | undefined

Check it out on GitHub.

A feature needs a strong reason to exist

Daniel Weinmann — Wed, 12 Jun 2024 19:33:22 +0000

We're working on a product with an amazing UI for managing projects. Think Trello but different 🙃

It offers drag and drop, in-place editing, keyboard navigation, etc, all with optimistic UI. The code is well-written and fairly organized, but it is inherently complex.

Recently, we wanted to add a "select multiple tasks and drag them all together" functionality. Before jumping into the code, we did some shaping to devise a solution that would not conflict with all the other user interactions we have.

Then it was time to do a spike to understand how hard it would be to build it. Before I even started coding the prototype, I knew it would make our codebase much more complex. We already have a lot of state management for the drag and drop, in-place editing, and optimistic UI. Adding another layer of state on the same UI would make it exponentially harder to grasp.

There is nothing inherently wrong with adding complexity. If the benefits outweigh the costs by a good margin, we're all for it. The problem in this case is that there is not yet a strong reason for this feature to exist.

The idea came up when we realized we had some time on our hands and wanted to use it to build something. And we feel this feature will be very useful in some cases. But if we're being honest, we still don't know how much so.

There is no user feedback indicating they're losing time dragging multiple tasks one by one. We only have our own experience with the app and a hunch. Nothing wrong with that either. Many of the best features out there were based on hunches and zero user feedback.

Still, something felt off while spiking. It doesn't feel like this hunch is worth the added complexity at this point. Maybe as we frame the problem better, it will.

That's the beauty of a method like Shape Up. It provides great checkpoints where we can decide whether to go ahead with a project or not.

If the stages of development (framing, shaping, building) were not that clear, we might have moved forward with this feature and ended up with a much more complex codebase without a strong reason for it.

Using Arktype in Place of Zod - How to Adapt Parsers

Gustavo (Guga) Guichard — Wed, 12 Jun 2024 16:37:14 +0000

Ever since I started using Zod, a TypeScript-first schema declaration and validation library, I've been a big fan and started using it in all my projects. Zod allows you to ensure the safety of your data at runtime, extending TypeScript’s type-checking capabilities beyond compile-time. Whenever I need to validate data from an outside source, such as an API, FormData, or URL, Zod has been my go-to tool.

I created, co-created, and worked on entire OSS libraries that are based on the principle of having strong type checking at both type and runtime levels.

A newfound love

Arktype has been on my radar for a while now, it offers similar validation capabilities but with some unique features that caught my eye, like the way it lets you define validators using the same syntax you use to define types.

I finally got the chance to use it in a project, and it was delightful.

The deal is that I'm using those Zod based libraries in the project, and I wanted to see how I could adapt them to use Arktype where they expect a schema.

I never wanted to have a tight coupling between the libraries and Zod, so instead of having Zod as a dependency, I'd expect a subset of a Zod schema.

// instead of:
function validate<T>(schema: ZodSchema<T>): T {
  // ...
}

// I'd expect something like:
function validate<T>(schema: { parse: (val: unknown) => T }): T {
  // ...
}

The validate function now accepts a generic schema that only requires a parse method. This decouples our code from Zod, allowing us to use other libraries with minimal changes.

It turns out this has just proven to be a great idea.

The libraries I'm adapting for

In this project, I'm using two Zod-based libraries, which are:

make-service

This lib uses Zod to validate an API response - among other nice features -, which is useful to ensure the data expectations are correct.

Check out a code sample without the library:

const response = await fetch('https://example.com/api/users', {
  headers: {
    Authorization: 'Bearer 123',
  },
})
const users = await response.json()
//    ^? any

And with it:

const service = makeService('https://example.com/api', {
  headers: {
    Authorization: 'Bearer 123',
  },
})

const response = await service.get('/users')
const users = await response.json(usersSchema)
//    ^? User[]

composable-functions

This is a library to allow function composability and monadic error handling. If you don't know it yet, think about a smaller/simpler Effect which has runtime type checking backed in by Zod.

Here follows a didactic example of how to define a function that doubles a number and does runtime type-checking:

import { withSchema } from 'composable-functions'
const safeDouble = withSchema(z.number())((n) => n * 2)

The difference between the libraries

When going into the libs source we can see that they use different subsets of Zod. The first one expects the already mentioned:

type Schema<T> = { parse: (d: unknown) => T }

While the second one expects the following code which is a subset of Zod's SafeParseError | SafeParseSuccess:

type ParserSchema<T = unknown> = {
  safeParse: (a: unknown) =>
    | {
        success: true
        data: T
      }
    | {
        success: false
        error: {
          issues: ReadonlyArray<{
            path: PropertyKey[]
            message: string
          }>
        }
      }
}

Which is a bit more complex, but still, it's just a subset of Zod.

TDD: Type Driven Development 😄

When investigating on how to extract the type out of an Arktype schema, I found out you can do:

import { Type } from 'arktype'

type Example = Type<{ name: string }>
type Result = Example['infer']
//   ^? { name: string }

Therefore, I could go on and create one adaptor for each library but this is a case where I can join both expectations in the same function. In fact, what I need is a function that conforms to this return type:

import { Type } from 'arktype'
import { ParserSchema } from 'composable-functions'
import { Schema } from 'make-service'

declare function ark2zod<T extends Type>(
  schema: T,
): Schema<T['infer']> & ParserSchema<T['infer']>

The implementation

Having started from the types above, the solution was quite straightforward.
I hope the code with comments below speaks for itself:

import { type, Type } from 'arktype'
import { ParserSchema } from 'composable-functions'
import { Schema } from 'make-service'

function ark2zod<T extends Type>(
  schema: T,
): Schema<T['infer']> & ParserSchema<T['infer']> {
  return {
    // For `make-service` lib:
    parse: (val) => schema.assert(val),
    // For `composable-functions` lib:
    safeParse: (val: unknown) => {
      // First, we parse the value with arktype
      const data = schema(val)
      // If the parsing fails, we only need what ParserSchema expects
      if (data instanceof type.errors) {
        // The ArkErrors will have a shape similar to Zod's issues
        return { success: false, error: { issues: data } }
      }
      // If the parsing succeeds, we return the successful side of ParserSchema
      return { success: true, data }
    },
  }
}

export { ark2zod }

Special thanks to David Blass - ArkType's creator - who reviewed and suggested a leaner version of this adapter.

Usage

Using the function above I was able to create my composable functions with make-service's service using Arktype schemas seamlessly:

import { type } from 'arktype'
import { withSchema } from 'composable-functions'
import { ark2zod } from '~/framework/common'
import { blogService } from '~/services'

const paramsSchema = type({
  slug: 'string',
  username: 'string',
})

const postSchema = type({
  title: 'string',
  body: 'string',
  // ...
})

const getPost = withSchema(ark2zod(paramsSchema))(
  async ({ slug, username }) => {
    const response = await blogService.get('articles/:username/:slug', {
      params: { slug, username },
    })
    const json = await response.json(ark2zod(postSchema))
    return json
  },
)

export { getPost }

When using the getPost function, my result will be strongly typed at both type and runtime levels or it will be a Failure:

export function loader({ params }: LoaderFunctionArgs) {
  const result = await getPost(params)
  if (!result.success) {
    console.error(result.errors)
    throw notFound()
  }
  return result.data
  //            ^? { title: string, body: string, ... }
}

Final thoughts

I hope this post was helpful to you, not only to understand how to adapt Zod-based libraries but also to understand how we at Seasoned approach problems. If you have any questions or have gone through a similar migration, I’d love to hear about your experiences and any tips you might have.

One thing I can assure you is that we love TS and we like to be certain about our data, be it at compile time or runtime.

Enforcing 'noImplicitAny' on callbacks to generic functions

Gustavo (Guga) Guichard — Mon, 10 Jun 2024 20:38:24 +0000

One of the first errors every TypeScript developer encounters is the famous noImplicitAny, which happens when you don't specify a type for a variable. For example:

function fn(s) {
  //        ^? Parameter 's' implicitly has an 'any' type.
  console.log(s.subtr(3));
}

This is a great thing because it forces you to think about the types of your variables and functions, helping you avoid bugs.

The problem

When developing your own functions that receive a callback, you might lose that error checking if you specify the type of the callback as (...args: any[]) => any. This type indicates that the function can receive any number of arguments of any type.

// @ts-expect-error
function fn(a) {}
const wrapper = (f: (...args: any[]) => any) => f
const test = wrapper((a) => {})
//                    ^? any
// TS won't complain

If you don't know, (...args: any[]) => any is one of the most popular ways to type a function. The Function primitive is not recommended because it can accept anything that is callable, such as a constructor, a callable object, or even a non-callable class such as Map.
But this use case creates a bad developer experience because you're losing one of the basic benefits of the type system. An any can easily go unnoticed and cause bugs further down the line.

The quest

Last week, I started a Twitter thread about this and asked for help from some friends and TS experts.
I was working on our library composable-functions on an issue by @danielweinmann that was experiencing this problem.

The problem seemed impossible and the solutions would require some trade-offs.

Forbidding the use of any in the callback's arguments was reasonable since the library I was working on is for strict TypeScript projects and any is probably out of the question. However, it would be a breaking change for the users and quite strict.
Swapping (...args: any[]) => any for (...args: never[]) => unknown. This was suggested by our contributor @jly36963 which is a thread on the TS repo itself. It seems nice because if you don't declare the types, the arguments are gonna be never, so you can't use them within the function. There was one concern though, this solutions causes problems with default arguments - as you can read in the last comment on that thread.

This is when I decided to go bold and try that Function primitive!

The solution

The solution was to use it in the function parameter but restrict it anywhere else down the line. We only need to enforce noImplicitAny in the declaration of the callback, but we have other ways to enforce a narrower type, such as (...args: any[]) => any, elsewhere.

The diff was quite simple:

-function composable<T extends (...args: any[]) => any>(fn: T): Composable<T> {
+function composable<T extends Function>(
+  fn: T,
+): Composable<T extends (...args: any[]) => any ? T : never> {

And it worked! The error was back and the user would have to specify the types of the arguments of the callback.

If the user tried to use something which isn't an actual function, they would get a Composable<never> which is impossible to work with.

You can check the final PR here

Conclusion

There were two motivations to write this post:

I couldn't find any information about this on the internet.
I love simple solutions that require you to think outside the box and break some rule as long as you cover up for them.

I hope this post can help someone else who is struggling with the same problem.

Keep your business code separate from the rest

Daniel Weinmann — Mon, 10 Jun 2024 18:28:10 +0000

One of the best things you can do for a codebase is to keep the business logic separate from everything else.

Imagine you have an app from 20 years ago, written in an old framework no one uses anymore. Thousands of people rely on it for their jobs, because it is the only app that deeply understands how this particular industry works.

The user experience could be so much better but the app works and no competitor beat them yet. Now you're tasked with bringing this giant to the modern days by adopting current technologies to improve the overall experience.

You take a quick look at the code, and being a seasoned dev with a sharp sword, you prepare for war. You know it's going to take your team a long time and it's going to be messy. Why?

Because most of your time will be spent untangling the logic that needs to stay from the parts that need to go. And what needs to stay is the business logic. The rest is old framework code no one cares about.

Now, while you untangle this mess, are you going to leave another one for future generations? Of course not. Because you know the current framework you're using now will undoubtedly be replaced by something else in a decade or so, you will do your best to keep the business code separate from everything else.

To do so, ask yourself the following question at all times:

If I were to migrate to a completely different framework tomorrow, would I be able to take the business logic with me?

If the answer is "yes", you're writing code that lasts. If not, you're borrowing from the future and some refactoring is in order.

DEV Community: Seasoned

How to disable a link in React Router 7 / Remix

Create admin panels for Postgres in 3 short steps

1. Create an account

2. Connect a database

3. Build your first tab

Google Analytics (GA4) implementation with React - Remix example

The gtag code

GA hook

Caveat

Usage

Function to track events

Navigating Careers

A proud generalist

Movin' on up

5 Common Pain Points in PostgreSQL

1. Time-Consuming Query Creation

2. Navigating Foreign Keys

3. Handling JSON Data

4. Creating Secure Interfaces for Non-Tech Teams

5. Scaling Custom Admin Solutions

It would be awesome if a tool existed to solve all of these problems, right?

Introducing Flashboard: Instant Admin Panels for PostgreSQL

Check out this quick demo:

I like what I see, but is it safe?

OK, but can I test it without connecting to my real database?

Nice, how much does it cost?

Molecules of business logic from tiny atoms

Functions with a verb in their name

A folder dedicated to business logic

Dealing with errors

Extracting smaller functions

Using our atoms

Going molecular

Why is it better this way?

Back to our online store

Calling our function

Thinking in composition

Type-Safe Env Vars With Vite - A Modern Approach

The Gist of Changes

The New makeTypedEnvironment Helper

Accepting Different Parsers and Preventing Mutations

Transforming the Env Vars to camelCase

Getting rid of the VITE_ prefix

Last Optimization: Caching

Extending Schemas

Et Voilà

That's It

Update: make-typed-env on npm

A feature needs a strong reason to exist

Using Arktype in Place of Zod - How to Adapt Parsers

A newfound love

The libraries I'm adapting for

make-service

composable-functions

The difference between the libraries

TDD: Type Driven Development 😄

The implementation

Usage

Final thoughts

Enforcing 'noImplicitAny' on callbacks to generic functions

The problem

The quest

The solution

Conclusion

Keep your business code separate from the rest

If I were to migrate to a completely different framework tomorrow, would I be able to take the business logic with me?

The New `makeTypedEnvironment` Helper

Transforming the Env Vars to `camelCase`

Getting rid of the `VITE_` prefix

Update: `make-typed-env` on npm