Why I Built Yet Another Grocery List App (And Why I'm Not Sorry)

Jan — Sat, 26 Apr 2025 18:42:29 +0000

Let’s be honest:

There are already 500 grocery list apps out there.

And yet — I still built LoopList.

Why? Because every week, I found myself typing out the same boring list and going slowly insane.
I'm a structured person.

I love organization — but I hate shopping.

And I absolutely refuse to keep typing "milk," "eggs," "oats" every single week.
So: I built my own app.

Problem solved.

What Makes LoopList Different

LoopList isn't just another “type it in and check it off” app.
LoopList actually thinks with you:

Personal Product Archive Everything you buy is saved. Next week, just reactivate items instead of retyping them.
Pantry Stock Management You can track how much you have left (e.g., eggs medium in stock). When you're running low, LoopList suggests restocking automatically.
Smart Intervals Set how long your supplies usually last (e.g., "eggs last 7 days"). BUT: LoopList adjusts those intervals dynamically if it notices you're running out sooner. (Tiny AI, big impact.)
Minimalistic and Efficient No ads. No bloated features. Just you, your pantry, and your smarter shopping loop.

Who LoopList Is For

People who buy pretty much the same things every week.
Structured folks who want to shop efficiently without retyping.
Anyone who wants to manage pantry stock smartly, not just manage lists.

Why I’m Asking for Feedback

I know LoopList won’t change the world.

But it solved a real problem for me. And maybe it can help you too.

LoopList was born out of pure real-life frustration — not some startup pitch deck.

You can try it here: https://looplist.netlify.app/

I'm genuinely looking for honest feedback:

What works?
What’s missing?
What would you change?

Thanks for checking it out — and maybe for giving it a shot!

Jan

Using Astro Image Optimization Benefits with Tina CMS Cloud in Production build

Jan — Sun, 16 Jun 2024 17:15:30 +0000

Problem Statement

In production, the benefits of image optimization using Astro's Image/Picture component are lost when integrating with Tina CMS and Tina Cloud. However, I have found a workaround to resolve this issue. Whether this workaround is the best or a good fit for client websites remains uncertain, but here are the details. For further context, you can read the github discussion here.

Preface

Typically, you have a markdown file with an image path pointing to a locally based image, like so:

imgSrc: /src/assets/img/logo.png
...

To leverage the image optimization benefits of the Astro Image component, such as generating multiple versions of an image based on device density, you would use dynamic image imports as described in astro docs. Everything works perfectly in development mode when you run npm run "tinacms dev -c \"astro dev\"",. Tina CLI commands But for clarity here an example of importing images dynamically.

---
import type { ImageMetadata } from "astro";
import { Image } from "astro:assets";

interface Props {
  imgSrc: string;
}

const { imgSrc } = Astro.props;

const images = import.meta.glob<{ default: ImageMetadata }>("/src/assets/img/*.{jpeg,jpg,png,gif}");

if (!images[imgSrc]) {
  throw new Error(`"${imgSrc}" does not exist in glob: "src/assets/img/*.{jpeg,jpg,png,gif}"`);
}

---

<Image
  width="70"
  height="70"
  src={images[imgSrc]()}
  alt="test image"
  densities={[1.5, 2]}
  loading="lazy"
/>

The Production Issue

In production, Tina CMS typically retrieves its media from its own CDN server (e.g., https://assets.tina.io/image). This setup conflicts with Astro's automatic image optimization and the associated glob pattern.

The function tries to search for the image in the local path. This works in development mode, but in production, the imgSrc returned from the markdown file is no longer a local string. Instead, it returns a URL like https://assets.tina.io/image, causing the search function aka glob function to fail and resulting in a build error.

For more information, refer to the github discussion here.

Workaround for Using Image Optimization

To still leverage Astro's image optimization in production, you need to adapt the build script:

Modified Build Script

The build script must be updated to:

"scripts": {
  "build": "tinacms build --local -c \"astro build\""
}

However, be aware that dynamically fetching data will no longer work as expected. For example, querying dynamic data using Tina's client in for example a Date component will not working properly.

Example script of my dynamically data fetches

<script>
        import { formatMarkdownUrl, formatDateString } from "../utils/format";

        document.addEventListener("DOMContentLoaded", async () => {
            try {
                const { client } = await import(
                    "../../tina/__generated__/client"
                );

                async function getLiveDatesResponse() {
                    try {
                        const response =
                            await client.queries.live_dateConnection({
                                sort: "date",
                            });
                        return response;
                    } catch (error) {
                        console.error(
                            error,
                        );
                        return null;
                    }
                }

            }
        })
</script>

Conclusion

This workaround allows you to leverage Astro's image optimization benefits in production while using Tina CMS and Tina Cloud. However, it introduces limitations in dynamically fetching data, which may not be suitable for all use cases. Evaluate whether this approach fits your project's requirements and constraints.

For further reading and to join the discussion, check out the GitHub discussion.

DEV Community: Jan