Forem: Thomas Collardeau

Building BiasDetector: My Journey into AI Text Analysis with n8n and LLMs

Thomas Collardeau — Mon, 07 Jul 2025 13:51:04 +0000

The way text frames information can profoundly shape our understanding of events and ideas. As AI and Large Language Models (LLMs) become more prevalent, exploring how these tools can help us identify and understand linguistic nuances presents a fascinating challenge. This curiosity, combined with a passion for automation, led me to create BiasDetector — a project focused on using AI to analyze text for potential bias.

This post shares the journey, technical approach, and lessons learned while building this tool using n8n and LLMs.

Tech meets text: AI analyzes bias in the written word.

The Core Challenge: Focusing AI on Language, Not Just Entities

My interest in this area stemmed from exploring how LLMs could move beyond simple text generation or summarization to tackle more subtle analytical tasks. Early on, a key challenge emerged: LLMs possess vast knowledge from their training data. When analyzing text mentioning specific politicians or organizations, their pre-existing associations with these entities can inadvertently influence or distract from assessing linguistic bias.

This challenge led to BiasDetector’s central architectural decision: a multi-stage LLM chain designed to isolate and analyze linguistic patterns. The core concept involves a sequential process:

Redactor LLM: “Neutralizes” the text by identifying specific entities — people, organizations, locations — and replacing them with generic placeholders. For example, “John Smith visited London” becomes “[PERSON_1] visited [CITY_1]”. This helps focus subsequent analysis while standardizing varied entity references for more consistent outcomes.
Bias Analyzer LLM: Scrutinizes the anonymized text. Freed from specific entity knowledge, it can better focus on the language itself — phrasing, sentiment, and structure — to identify and analyze bias patterns.
Descrambler LLM: Takes the placeholder-based analysis and original entity mappings (the “legend”) to intelligently reconstruct a fully human-readable report.

This chained approach enables more targeted and reliable analysis of how text frames its subject matter, providing greater consistency in outputs.

Orchestrating with n8n: From Web Form to Emailed Report

n8n served as the engine for this entire operation, providing the perfect platform to connect sequential LLM calls and manage data flow.

The BiasDetector n8n workflow: chaining LLMs for nuanced text analysis.

User Input via JotForm

For the public demo, I created a simple JotForm (try it here: https://form.jotform.com/251364670893061). Users can paste text (up to 4,000 characters for the demo) and provide an email address. I focused on clear instructions and mandatory fields to ensure a smooth user experience.

The n8n Workflow in Action

The workflow follows a clean sequence:

Form Submission: JotForm submission triggers the n8n workflow
Redaction: Text goes to the Redactor LLM node, which returns anonymized text and a “legend” mapping placeholders back to original terms
Analysis: Anonymized text passes to the Bias Analysis LLM node, prompted to identify bias patterns and output structured, four-part analysis in JSON format using placeholders
Descrambling: The Bias Analyzer output and legend go to the Descrambler LLM node, which weaves original entity names back into the analysis
Email Delivery: n8n’s data transformation assembles all components into an HTML email sent via Gmail

n8n’s visual interface, robust LLM integration nodes, and data handling features made managing this sequence and iterating on the logic incredibly efficient.

What BiasDetector Delivers

Users receive a detailed email report offering a multi-faceted look at their submitted text:

Original text
Clear explanation of the anonymization step (showing anonymized text snippet and sample legend)
Comprehensive four-part bias analysis with original terms restored
Bias Analysis Summary
Potential Impact of Bias
Alternative Framing Strategies

This report helps users understand not just how language can convey bias, but how to discern the likely intended impact or persuasive goal of a piece of text. For example, it might highlight not just overtly critical language toward a person, but reveal patterns like consistently associating an organization with negative outcomes — even subtly — that collectively work to frame that organization unfavorably.

By analyzing these linguistic patterns in isolation from our existing knowledge about the entities involved, BiasDetector can help users recognize when an article might be attempting to shift public opinion, build support for a particular viewpoint, or prime readers to view certain actors favorably or unfavorably. This makes it easier to identify the underlying persuasive intent that might not be immediately obvious when reading the text normally.

Lessons from the Redactor: Iterating Towards Intelligent Anonymization

A significant part of this journey involved iteratively refining the Redactor LLM’s prompt — the instructions guiding its anonymization task. This wasn’t simple find-and-replace; it was an exercise in guiding an LLM to understand nuanced requirements.

Early on, I grappled with optimal redaction levels. Too little redaction leaves the Bias Analyzer potentially influenced by prior entity knowledge. Too aggressive redaction strips away crucial contextual clues or linguistic patterns that indicate bias. Removing descriptive common nouns associated with entities, for instance, might make text too abstract for meaningful analysis.

The real challenge lay in ensuring redaction was thorough and semantically intelligent. If text mentioned “Rome” and later referred to it as “the Eternal City,” how could the system recognize these as the same entity? The goal was for the Bias Analyzer to understand that bias expressed toward “the Eternal City” was actually bias related to “Rome.”

This required the Redactor to do more than assign [CITY_1] to “Rome” — it needed to link related terms.

The Power of LLMs for Semantic Understanding

Through cycles of prompt testing and adjustment, I experimented with different ways to instruct the Redactor to identify not just primary entities but also their aliases, acronyms, or descriptive references. Success came through careful prompt engineering that guided the LLM to generate linked placeholders. The refined Redactor could identify “Rome” as [CITY_1] and recognize “the Eternal City” as [CITY_1_NICKNAME], with explicit linking in the placeholder nomenclature itself.

This is precisely where LLMs shine for such tasks. Their inherent understanding of semantic meaning and context allows them to identify relationships — like linking a city to its well-known nickname — that would be extraordinarily complex and brittle to achieve with traditional rule-based programming, and impossibly laborious to do manually at scale. The LLM’s ability to grasp these nuances was fundamental to developing a Redactor that could intelligently prepare text for analysis.

This iterative dialogue with the Redactor LLM — defining problems with increasing precision, crafting nuanced instructions, observing outputs across diverse texts, and continually refining prompts — was where much of the project’s learning occurred. It highlighted that effective AI application often lies in this detailed, persistent conversation with the model.

The Road Ahead

While BiasDetector’s V1 demo is now functional and represents a significant milestone, the potential for further development is substantial. Future possibilities include:

Refining analytical depth
Exploring applications to different content types (government press releases, children’s literature, academic papers)
Expanding into related areas like logical fallacy detection

The core architecture built with n8n provides a solid foundation for these future explorations, demonstrating how modern no-code platforms can orchestrate sophisticated AI workflows to tackle complex analytical challenges.

Conclusion

BiasDetector has been an incredibly rewarding project. It pushed me to combine thoughtful prompt engineering, workflow automation with n8n, and a critical approach to AI-driven text analysis. Building it involved not just connecting APIs, but truly designing an intelligent process to navigate the complexities of LLM behavior and natural language. It’s a clear demonstration of how these modern tools can be orchestrated to create applications that offer genuine insight. The journey from initial concept to a functioning, user-facing demo has been a significant and fulfilling experience in applied AI.

From Data to Delight: Using n8n and LLMs to Automate Insightful Weather Updates

Thomas Collardeau — Thu, 19 Jun 2025 13:49:12 +0000

The Kairos automation: From data nodes to a sunny forecast, powered by n8n and LLMs.

Throughout my exploration of automation’s vast potential, I’ve documented various experiences—from grappling with conditional JSON challenges in Make.com to uncovering more streamlined solutions with n8n’s Code Node during a Luma API integration.

Each project provided valuable insights, but my latest venture stands apart. Building Kairos, an AI-powered weather scout, has vividly demonstrated how integrating robust automation tools with the advanced reasoning capabilities of Large Language Models (LLMs) can effectively address complex, real-world problems with remarkable efficiency.

The initial idea was simple: find the best weather in Europe and tweet about it. But “best” is subjective, and sifting through forecasts for dozens of cities, each with multiple data points (temperature, conditions, precipitation probability over several days), to make a human-like judgment and then craft an engaging tweet? That’s not a trivial coding task. Traditionally, this would mean complex conditional logic, weighting systems, and perhaps even sentiment analysis libraries to get the tone right for a tweet.

This is where the synergy of n8n and LLMs truly shines.

The Challenge: Drowning in Data, Dreaming of Simplicity

My n8n workflow diligently fetches detailed 5-day forecasts for 30 European cities from OpenWeatherMap. Using n8n’s Split Out and HTTP Request nodes, this part is fairly standard. Then, a Code Node steps in to transform and clean this data, stripping unnecessary fields, formatting values, and crucially, adding city names to each forecast. The result is a single, clean JSON object — an array where each element represents a city’s detailed weather report, all under a top-level fetch_date.

Here’s a conceptual glimpse of what that data structure looks like before it heads to the AI:

{
  "fetch_date": "May 16, 2025",
  "weather_reports": [
    {
      "city_name": "Paris, FR",
      "daily_forecast": [
        { "day": 1, "temp_max": 22, "condition": "Sunny", "precip_prob": 10 },
        { "day": 2, "temp_max": 23, "condition": "Clear", "precip_prob": 5 }
        // ... more days
      ]
    },
    {
      "city_name": "Oslo, NO",
      "daily_forecast": [
        { "day": 1, "temp_max": 18, "condition": "Partly Cloudy", "precip_prob": 20 },
        // ... more days and data points
      ]
    }
    // ... 28 more cities
  ]
}

Now, imagine writing the code to:

Parse this for 30 cities.
Define what “best weather” means. Is it just warmest? What about “sunny but not too hot”? Or “surprisingly good for this time of year”?
Compare all 30 cities based on these nuanced criteria.
Select a single winner.
Compose a tweet that sounds natural, engaging, and includes relevant details like temperature ranges and emojis.

The logic would be extensive and brittle.

The LLM Breakthrough: Outsourcing Complex Logic and Creativity

Instead of coding that mountain of logic, I turned to an LLM (Gemini 2.5 Pro, accessed via n8n’s OpenAI node configured for OpenRouter). I fed it the entire JSON object of weather reports and, through careful prompt engineering, asked it to do the heavy lifting.

My prompt instructed the LLM to:

Act as Kairos, whose mission is to find appealing weather for spontaneous trips.
Analyze all provided city forecasts.
Identify the city with the overall “best weather in Europe,” considering factors like pleasant temperatures (e.g., 18–28°C), sunshine, and low precipitation.
Crucially, give preference to cities experiencing “unusually pleasant” weather for their location/season (this was a key refinement for more interesting picks).
Return its findings in a structured JSON format, including the chosen city, reasoning, and, importantly, a suggested_tweet.

The result? The LLM not only intelligently analyzed the data — weighing multiple factors across numerous cities in a way that mimics human intuition — but it also drafted a ready-to-post tweet, complete with relevant emojis and a call to action.

This ability to hand off complex data analysis and creative content generation to an LLM, simply by providing structured data and clear instructions, felt like a superpower. The hundreds, if not thousands, of lines of conventional code I might have written were replaced by a well-crafted prompt.

n8n: The Indispensable Orchestrator

The LLM, powerful as it is, needs a robust platform to manage the overall workflow. Here’s how n8n played that crucial role:

Data Ingestion & Iteration: Efficiently fetching data from OpenWeatherMap for each city using HTTP Request and Split Out nodes. Data Preparation: The Code Node ensured the LLM received clean, well-structured JSON tailored for analysis.
AI Integration: The OpenAI node seamlessly handled the LLM call, abstracting the API complexities.
Action & Communication: The X (Twitter) node took the LLM’s suggested_tweet and posted it, while the Gmail node sends me a confirmation.
Reliability & Scheduling: n8n also handles scheduling the workflow to run twice a week and incorporates a separate error-handling workflow that emails me if anything goes amiss, ensuring robust operation.

The platform’s visual interface allowed me to design the overall flow, while specific nodes like the Code Node and OpenAI node provided the power needed for the more intricate parts.

Key Learnings for an AI & Automation Toolkit:

LLMs as Data Analysts: LLMs can ingest large, structured datasets and extract nuanced insights based on natural language instructions, saving vast amounts of custom coding.
LLMs as Content Generators: Beyond analysis, they can generate contextually relevant and stylistically appropriate content (like tweets) based on that analysis.
Prompt Engineering is Key: The quality of the LLM’s output is directly proportional to the clarity, specificity, and iterative refinement of the prompt. This is a skill in itself. n8n + LLMs = A Power Duo: n8n provides the robust framework for data flow, service integration, scheduling, and error handling, while the LLM provides the “brain” for complex decision-making and generation.
The Future is Orchestration: My role increasingly feels like an orchestrator of these powerful tools, designing the interaction points and guiding the AI, rather than coding every single logical step from scratch.

This Kairos project has been incredibly rewarding, not just for the functional automation it produced, but for the deeper understanding it gave me of how AI can be practically integrated into workflows to solve real-world problems in surprisingly elegant ways.

You can see the results of this automation live on the @kairos_sun X (Twitter) account, which is now autonomously tweeting its weather picks. It’s a small demonstration, but for me, it represents a big step forward in leveraging AI within automation.

Leveling Up My Automation Game: When Visual Builders Led Me to n8n’s Code

Thomas Collardeau — Thu, 05 Jun 2025 13:49:17 +0000

A little while ago, I shared my journey building an automated workflow to generate AI videos with Luma Labs directly from a Google Sheet using Make.com. It was a success, but one piece of the puzzle — handling optional API inputs requiring specific JSON structures — necessitated a slightly cumbersome workaround involving Make.com’s Router module and duplicate steps.

While functional, that Router-based solution felt like using a visual sledgehammer for a logic nut that needed cracking. It worked, but the repetition highlighted a limitation: sometimes, intricate conditional logic, especially when dealing with nested data structures for APIs, can become awkward in a purely visual builder. This itch — the feeling that there must be a cleaner way — prompted me to look at other automation tools.

Simplifying visual workflows: Sometimes, a little code is the best eraser.

Exploring n8n: The Promise of Integrated Code

n8n often came up in discussions about flexible automation, particularly its “Code Node” which allows running custom JavaScript directly within a workflow. Could this be the answer to the JSON construction challenge? I decided to find out by replicating my exact Luma API automation in n8n.

Setting up the basic flow in n8n was straightforward. The real test came when it was time to dynamically create that tricky JSON payload for the Luma API — the part that had required the Router detour in Make.com. This time, I dropped in n8n’s Code Node.

The Breakthrough: Solving Logic with Logic

The difference was immediate. Instead of visual branching, I wrote a small JavaScript snippet. Using simple if statements, the code checked which input fields (like start or end image URLs) were present and built the exact JSON payload required by the Luma API for that specific combination, adding or omitting keys and nested objects as needed.

This single Code Node, containing just a handful of logical JavaScript lines, cleanly replaced the Router and multiple duplicated HTTP modules I’d used in Make.com. It directly addressed the core challenge — conditional data structure generation — in a way that felt much more direct and maintainable.

Visual vs. Code-Enhanced: Finding the Balance

This experience was illuminating. Make.com’s visual approach is brilliant for connecting services and mapping data in many scenarios. But for that specific task, the rigid structure of the API’s conditional requirements was simply easier to express programmatically.

n8n’s ability to seamlessly integrate these small code snippets within the visual flow provided the flexibility I needed. It wasn’t about abandoning visual building entirely, but about having the right tool — sometimes code — available for specific, tricky parts of the process. It felt like unlocking a new level in automation, combining the ease of visual flow design with the precision of code when necessary.

This discovery has definitely shifted my perspective. Having experienced the power of code-enhanced automation, I’m eager to tackle more complex projects with n8n, knowing I have that extra layer of flexibility available when the drag-and-drop approach meets its limits. Sometimes, the path to a more elegant solution involves embracing a little bit of code.

Hands-Free AI Video: How I Connected Google Sheets and Luma via Make.com

Thomas Collardeau — Mon, 02 Jun 2025 11:34:17 +0000

The rise of AI video generation tools like Luma Labs is incredibly exciting, opening up new possibilities for creators. However, manually generating clips, especially for ongoing projects, can quickly become time-consuming. As part of refining my automated workflows, I set out to build a system that could trigger Luma video generations directly from a simple Google Sheet, using Make.com as the automation platform. The goal? A truly "hands-free" video pipeline.

The Dream Workflow

The plan seemed straightforward enough:

Add details for a new video job (like prompts, image URLs, settings) to a row in a Google Sheet and mark its status as "Ready".
Have Make.com detect this "Ready" row.
Make.com calls the Luma Labs API with the details from the sheet.
Luma does its magic and generates the video.
Luma sends a notification (webhook) back to Make.com when the job is complete.
Make.com receives this notification, grabs the video URL, and updates the original Google Sheet row with the URL and a "Completed" status. (Optionally, it could also save the video file to cloud storage like Dropbox).

This setup would allow me to queue up multiple video jobs just by filling out a spreadsheet – pretty neat!

The API Curveball: Handling Optional Inputs

Connecting Google Sheets and setting up the basic Make.com scenarios (one to "Call" Luma, one to "Receive" the callback) went smoothly. However, I soon hit an unexpected hurdle when constructing the actual API request to Luma.

The Luma API allows for generating video from a text prompt, a starting image (frame0), an ending image (frame1), or both images. These image inputs are nested within a keyframes object in the JSON payload sent to the API.

The challenge? If you only provide one image (or none), the API doesn't just want an empty string for the missing image URL. It requires the entire key for the missing frame (e.g., "frame1": {...}) or potentially even the parent keyframes object itself to be completely omitted from the JSON request. Sending incorrect structures, like frame1: {} or frame1: { "url": "" }, results in an error. This kind of strictness is fairly common with APIs, requiring careful payload construction.

Navigating Make.com's Visual Logic

My first instinct was to use Make.com's built-in functions. Functions like ifempty(variable, ignore) worked perfectly for top-level optional fields, like the main text prompt. If the prompt cell in my Google Sheet was empty, ignore would correctly remove the prompt key from the final JSON.

However, applying this logic to nested objects like frame0 or frame1 within keyframes proved trickier within the visual interface. Trying to ignore just the url inside frame0 would leave an empty frame0: {} object, which the API rejected. I needed a way to conditionally remove the entire frame0 or frame1 object, or the keyframes object altogether, based on the input data from the Google Sheet.

The Router Workaround

After some experimentation, the most reliable solution within Make.com's visual builder involved using the Router module. Here’s how it works in my "Luma Caller" scenario:

The scenario triggers and finds "Ready" rows in Google Sheets.
It iterates through each job.
Initial Validation: A first router checks if essential data (like model, aspect ratio) is present.
Status Update: The Google Sheet row is updated to "Processing".
The Core Logic (Router): A second Router module checks the input columns for the First Frame (C) and Last Frame (D) image URLs from the Google Sheet.

Path 1: If only First Frame (C) has a URL, it proceeds down a path with an HTTP module configured only with the JSON structure for frame0.
Path 2: If only Last Frame (D) has a URL, it uses a different HTTP module configured only for frame1.
Path 3 (Fallback): If both C and D have URLs, it uses a third HTTP module configured for both frame0 and frame1.
API Call & Update: The appropriate HTTP module calls the Luma API. On success, another Google Sheets module updates the row to "Generating" and stores the Luma Job ID.

Here's a look at that part of the Make.com scenario:

The Make.com 'Luma Caller' scenario flow. The crucial Router module branches the process based on input data (presence of first/last image frames), sending the job to one of three dedicated HTTP modules configured with the correct Luma API payload structure.

A separate "Luma Receiver" scenario listens for the webhook callback from Luma, filters for the "completed" status message, finds the matching row in the Google Sheet using the Job ID, and updates the status to "Completed", pasting in the final video URL.

Reflections and What's Next

This Router-based solution works reliably and achieves the goal: I can now trigger Luma video generations simply by adding rows to a Google Sheet. It's a functional hands-free pipeline!

From a Make.com perspective, the solution feels a bit repetitive, requiring separate, almost identical HTTP modules for each conditional path. I was genuinely surprised I couldn't find a more direct visual method to dynamically build or omit those nested JSON structures based on input variables. It works well, though I do wonder if the Make.com community has found more streamlined visual methods for handling such conditional nested structures.

This project was a valuable practical exercise, deepening my understanding of Make.com's capabilities, the practicalities of API integration, and the importance of carefully handling API requirements. It also highlighted the trade-offs between visual builders and code. For future projects involving more complex conditional logic, exploring platforms like n8n, which often integrate code modules more directly, might be worth comparing.

For now, I have a working automation that saves significant time and effort, demonstrating the practical power of tools like Make.com for streamlining creative and technical workflows.

Lazy Loading Images in Svelte

Thomas Collardeau — Wed, 20 Nov 2019 13:34:38 +0000

Let's imagine we have ourselves a little web app that displays a column of images (of kittens, of course).

We open the code and see that we have 3 friendly Svelte components greeting us. Let's take a look at each one in turn:

App.svelte sets some basic styles and renders a List component. We won't be editing this file but here it is for clarity:

<script>
  import List from "./List.svelte";
</script>

<style>
  main {
    width: 300px;
    margin: 0 auto;
    text-align: center;
  }
</style>

<main>
  <h1>Kittens</h1>
  <List />
</main>

List.svelte generates a list of images (such as https://placekitten.com/g/300/500?image=01) and renders a ListItem component for each of them:

<script>
  import ListItem from "./ListItem.svelte";

  // generate image data:
  const prefix = "https://placekitten.com/g/300/500?image=";
  const items = ["01", "02", "03", "04", "05"].map(num => prefix + num);
</script>

{#each items as item}
  <ListItem {item} />
{/each}

ListItem.svelte is in charge of rendering an individual image inside an article tag:

<script>
  export let item;
  let src = item;
</script>

<style>
  article {
    width: 300px;
    height: 500px;
    margin-bottom: 0.5rem;
  }
</style>

<article>
  <img {src} alt='kitten'/>
</article>

So we're loading and rendering a few images that are 300 pixels wide and 500 pixels tall from placekitten.com. Nice and easy.

The Issue At Hand

Most of the images (each being 500px tall) are naturally off screen when the user lands on the page. They might never scroll down to see all our awesome content below the fold. So they're downloading data for nothing on initial load, and slowing down their experience.

Even if they do scroll all the way down, it would be nice to load the images only when they are about to enter the viewport and lighten the initial load. We can improve the user's experience and serve fewer images on our end. Win-win.

When Lazy is Good

So let's lazy load our images! But not the first 2, we want to fetch those right away, and then load the rest as we scroll down.

First, let's have our List component pass down a lazy prop to ListItem, which will be true starting from the third image. When it's true, ListItem will set src to an empty string so that no image is requested at first.

In List.svelte, we pass down a new lazy prop:

{#each items as item, i}
  <ListItem {item} lazy={i > 1} />
{/each}

In ListItem.svelte, we set the image src:

export let item;
export let lazy;

let src = lazy ? '' : item;

So, at this stage, we're loading the first two images but the rest is never loading. How shall we trigger this effect?

Intersection Observer

The Intersection Observer is a web API that allows us to know when an element is intersecting (or about to intersect) with the viewport. It's got solid browser support (it's just not available in IE11).

How does it work? We create an observer using IntersectionObserver and give it a function that will run when a DOM node that we've registered is intersecting with the viewport.

const observer = new IntersectionObserver(onIntersect);

function onIntersect(entries){
  // todo: update relevant img src
}

We can observe (and unobserve) a node using a Svelte action:

<script>
  function lazyLoad(node) {
    observer.observe(node);
    return {
      destroy() {
         observer.unobserve(node)
      }
    }
  }
</script>

<article use:lazyLoad>
  <!-- img -->
</article>

Putting it together our ListItem.svelte looks like this (minus the styles which haven't changed):

<script>
  export let item;
  export let lazy = false;

  let src = item;
  let observer = null;

  if (lazy) {
    src = "";
    observer = new IntersectionObserver(onIntersect, {rootMargin: '200px'});
  }

  function onIntersect(entries) {
    if (!src && entries[0].isIntersecting) {
      src = item;
    }
  }

  function lazyLoad(node) {
    observer && observer.observe(node);
    return {
      destroy() {
        observer && observer.unobserve(node)
      }
    }
  }
</script>

<article use:lazyLoad>
  <img {src} alt='kitten'/>
</article>

When the lazy prop is passed in as true, we immediately set the src to empty string and create an observer. We add a rootMargin option so that the onIntersect function is triggered 200 pixels before the element comes into view. In lazyLoad, we register the article node that we want to watch.

Effectively, we are creating an observer with a single node for each ListItem, so we can check if that node (entries[0]) is in fact intersecting in our OnIntersect function and set src = item which will request the image.

And just like that, we're lazy loading our images! We can see in the devtools that we are not requesting all images upfront, as illustrated in this GIF:

Last thing, Let's make sure our app doesn't blow up if intersectionObserver isn't available (IE11) by adding a hasAPI check in List.svelte

<script>
import ListItem from "./ListItem.svelte";

const prefix = "https://placekitten.com/g/300/500?image=";
const items = ["01", "02", "03", "04", "05"].map(img => prefix + img);
const hasAPI = "IntersectionObserver" in window; // new
</script>


{#each items as item, i}
  <ListItem {item} lazy={hasAPI && i > 1} />
{/each}

Here is the updated sandbox shall you want to tinker with this code:

This is a technique I recently implemented for a painter's portfolio website that I built using Sapper. You can see it at https://john-hong-studio.com.

Thanks for reading! Don't hesitate to leave a comment or connect with me on twitter!

Props up with Svelte

Thomas Collardeau — Mon, 07 Oct 2019 17:19:06 +0000

Passing props down (React)

Let's present the paradigm by creating a small Counter component in React first:

export default function Counter() {
  const [count, setCount] = useState(0);
  const incr = () => setCount(c => c + 1);
  return (
    <div>
      <div>{count}</div>
      <button onClick={incr}>+1</button>
    </div>
  );
}

And let's use it an App component:

import './Counter';

function App() {
  return ( 
    <Counter />
  )
}

Now, let us imagine that we need to know if the count is more than 1 in our App component (maybe we need to pluralize a string if that's the case).

Mmh... we don't have access to count from App. We have to lift the state up and pass it back down as a prop to <Counter />. As a result, we also need to pass down the increment function to update said count. Here is an implementation:


// App.js

import Counter from './Counter';

function App() {
  // state is now in the parent
  const [count, setCount] = useState(0);
  const incr = () => setCount(c => c + 1);
  return <Counter count={count} incr={incr} />;
}


// Counter.js

export default function Counter(props) {
  // the child uses props
  const { count, incr } = props;
  return (
    <div>
      <div>{count}</div>
      <button onClick={incr}>+1</button>
    </div>
  );
}

Nice, it works (sandbox). Yet it's slightly odd to me that our Countercomponent has become a shell of itself (it seems). It doesn't do any counting anymore. It wires in a click handler. Maybe we'd have to rename it? But I digress.

Component Bindings (Svelte)

Let's try to handle the same issue in Svelte. Here is our Counter:

<script>
  let count = 0;
  const incr = () => (count = count + 1);
</script>

<div>{count}</div>
<button on:click={incr}>+1</button>

And a parent component, App:

<script>
   import Counter from './Counter.svelte';
</script>

<Counter />

So we're back in the same situation: we want to use count from Counter in the App component. We could lift state up again as before. But this time, we can actually pass props up without having to re-wire any state. We need to:

1/ export the variable in the Counter (child) component:

export let count = 0

2/ bind to the component value in the App (parent) component

<script>
  let count;
</script>
< Counter bind:count />

We declare the variable in the script tag, and we grab it via component bindings (bind:count). So, we have access to the count in the parent component! Let's actually solve the problem in full, using reactive declarations as well.

App.svelte:

<script>
  import Counter from './Counter.svelte';
  let count;
  $: isMoreThan1 = count > 1;
</script>

<Counter bind:count />
<span>is More than 1: {isMoreThan1} </span>

Counter.svelte:

<script>
  export let count = 0;
  const incr = () => (count = count + 1);
</script>

<div>{count}</div>

<button on:click={incr}>
  +1
</button>

View it in the REPL.

I'm interested in your thoughts. What do you think are the repercussion for componentization in Svelte coming from React? Is there a similar mechanism in Vue or Angular?

Give me a follow on Twitter for more explorations with Svelte :)

Building a Headroom-Style Header in Svelte

Thomas Collardeau — Wed, 02 Oct 2019 19:51:13 +0000

Let us build a headroom-style header in Svelte! Our objective in this blog post is to create a header that slides up (and out-of-view) when the user scrolls down, and re-appears when they scroll up (no matter how far down the page they are).

This is a technique used to save room on the screen while sparing the user from having to scroll all the way back up the page to get to the header and navigation.

We won't use the popular headroom.js but roll up a our own simple solution while honing our Svelte skills along the way. Are you ready?

The Layout

We'll begin with a component that has a fixed header as if it was already "pinned". Let's give our header a height and background-color so we can actually see it. Our Svelte component sees the light of day:

<style>
 header {
    background-color: darkgrey;
    height: 80px;
    position: fixed;
    width: 100%;
  }
  main {
    min-height: 150vh;
    padding-top: 80px;
  }
</style>

<header />
<main>Lorem ipsum</main>

You can see that we're giving our main tag a padding-top equal to the height of the header otherwise the header (being fixed) would cover the top of main. We're also giving main some min-height so we can be sure that we're able to scroll up and down and test our component manually.

As it stands, we've created a fixed header that stays put as you scroll down. Not great, not terrible. Here is our starting point in a code sandbox:

The Plan: Pin or Unpin

In order to hide or show the header, we shall target it with a conditional class so that we can joyfully control its CSS. One class will serve to pin the header by setting the top property to 0, and the other will bravely unpin it by setting top to -80px, which will hide it out of view (based on its own height of 80px).

Let's add a transition on header while we're dealing with the CSS so any change will occur over 0.3 second instead of being instantaneous and jarring and, quite frankly, unusable. I dutifully propose this extra bit of CSS:

 header {
    /* ... existing properties */
    transition: all 0.3s linear;
  }
 .pin {
    top: 0;
  }
  .unpin {
    top: -80px;
  }

It will be up to us to add and remove the appropriate class in response to the user actively scrolling. Fingers crossed, everybody.

Using Svelte State

Let's create some state to hold the value of a headerClass that we can then refer to in the HTML. Well, state is simply a JavaScript assignment in Svelte! Let's give our header a starting class of pin.

<script>
  let headerClass = 'pin';
</script>

<header class={headerClass} />

Gotta love it. A simple re-assignment like headerClass = "whatever" will update our view. We'll do that in just a moment. But let's get our bearings and take stock of our entire component as it stands:

<script>
  let headerClass = 'pin';
</script>

<style>
 header {
    background-color: darkgrey;
    height: 80px;
    position: fixed;
    width: 100%;
    transition: all 0.3s linear;
  }
  main {
    height: 150vh;
    padding-top: 80px;
  }
 .pin {
    top: 0;
  }
  .unpin {
    top: -80px;
  }
</style>

<header class={headerClass} />
<main>Lorem ipsum</main>

Our code is taking shape but everything is the same visually: still a boring old fixed header. Clearly, we have to react in some way to the user actively scrolling (and eventually update headerClass)!

Scrolling Detection

How do we detect vertical scrolling in the first place?

Well... there is a scroll event listener on window and we can read the vertical scroll position at any time from window.scrollY. So we could wire up something like this:

// meh
window.addEventListener('scroll', function() {
  scroll_position = window.scrollY;
  // figure out class name
}

We would have to do this when the component mounts and remember to remove the listener when the component is destroyed. Certainly, it's a possibility.

However, we can do less typing in Svelte: we can use the <svelte:window> element and even bind to the window.scrollY position so it's available to us as it's changing. In code, it looks like this:

<script>
   let y;
</script>

<svelte:window bind:scrollY={y}/>

<span>{ y }</span>

The above code is a valid component. The value of y in the span will change as you scroll up and down the page (try it in a sandbox). Furthermore, we don't have to worry about removing the listener when using svelte:window, nor worry about checking if window even exists (shall the code be ran server-side). Well, that's pretty cool!

Reactive Declarations

So we have our scroll position y over time. From this stream of data, we can derive our class name. But how shall we even store a new value every time y changes? Svelte offers reactive declarations with the $: syntax. Check out this introductory example:

<script>
  let count = 1;
  $: double = count * 2;
  count = 2;
</script>

<span>
  { double }
</span>

The span will hold a value of 4 as soon as we've re-assigned count to 2.

In our case, we want headerClass to be reactive to the y position. We'll move our logic in a function of its own, much like this:

<script>
   let y = 0;
   let headerClass = 'pin'
   function changeClass(y) {
      // do stuff
   }
   $: headerClass = changeClass(y);
</script>

In short, we can update the class of the header whenever the scroll position y changes. Well, it seems we are getting closer to our objective!

What Class Name?

So we must focus on this newly introduced changeClass function which is in fact the last bit of implementation. It should return a string,'"pin"' or '"unpin"', and then our CSS can swing (actually, slide) into action.

Base Case

If the scroll direction doesn't change, for example if the user was scrolling down and is still scrolling down, we don't need to do anything at all but return the class name as it was. Let's make that our default case:

   let headerClass = 'pin';
   function changeClass(y) {
      let result = headerClass;
      // todo: change result as needed
      return result;
   }

So that's our base case taken care of. But the function should return 'pin' if the user starts scrolling up, and 'unpin' if they start scrolling down. We're jumping a bit ahead of ourselves because right now we don't even know which way the user is scrolling; we only have a stream of y positions, so let's figure that out.

Scroll Direction

We need to compare the last y position to the one we're currently holding to know the distance that was scrolled in pixels. So we need to store some lastY at the end of each scroll cycle, then the next scroll event can use it.

   let headerClass = 'pin';
   let lastY = 0;

   function changeClass(y) {
      let result = headerClass;
      // do stuff, then
      // just before returning the result:
      lastY = y; 
      return result;
   }

Now we have a lastY to work with so let's get our scroll direction with it. If lastY - y is positive the user is scrolling down, else they're scrolling up.

   let headerClass = 'pin';
   let y = 0;
   let lastY = 0;

   function changeClass(y) {
      let result = headerClass;
      // new:
      const scrolledPxs = lastY - y;
      const scrollDirection = scrolledPxs < 0 ? "down" : "up"
      // todo: did the direction change?
      lastY = y;
      return result;
   }

To determine if the scrolling direction changed, we can compare it to the last scroll direction, much like we did for lastY in fact. We'll initialize it to "up" so we can trigger our effect (hiding the header) on the initial scroll down.

   let headerClass = 'pin';
   let y = 0;
   let lastY = 0;
   let lastDirection = 'up'; // new

   function changeClass(y) {
      let result = headerClass
      const scrollPxs = lastY - y;
      const scrollDirection = scrolledPxs < 0 ? "down" : "up"
      // new:
      const changedDirection = scrollDirection !== lastDirection;
      // todo: change result if the direction has changed
      lastDirection = scrollDirection;
      lastY = y;
      return result;
   }

The Right Class

If my calculations are correct, there is only one step left: to re-assign result when the scrolling has actually changed direction, which we now know.

   let headerClass = 'pin';
   let y = 0;
   let lastY = 0;
   let lastDirection = 'up';

   function changeClass(y) {
      let result = headerClass
      const scrollPxs = lastY - y;
      const scrollDirection = scrolledPxs < 0 ? "down" : "up"
      const changedDirection = scrollDirection !== lastDirection;
      if(changedDirection) { // new
        result = scrollDirection === 'down' ? 'pin' : 'unpin';
        lastDirection = scrollDirection;
      }
      lastY = y
      return result;
   }

And that does trick! Thanks to our conditional class on header and our CSS, we find ourselves with a headroom-style header!

The Whole Thing

Let's see the whole Svelte component, shall we? Let's treat ourselves to a CSS Variable so we don't have that hard-coded 80px header height in multiple places.

<script>
  let headerClass = "pin";
  let y = 0;
  let lastY = 0;
  let lastDirection = "up";

  function changeClass(y) {
    let result = headerClass;
    const scrolledPxs = lastY - y;
    const scrollDirection = scrolledPxs < 0 ? "down" : "up";
    const changedDirection = scrollDirection !== lastDirection;
    if (changedDirection) {
      result = scrollDirection === "down" ? "unpin" : "pin";
      lastDirection = scrollDirection;
    }
    lastY = y;
    return result;
  }

  $: headerClass = changeClass(y);
</script>

<svelte:window bind:scrollY={y}/>

<style>
  :root {
    --header-height: 80px;
  }
  header {
    background-color: darkgrey;
    height: var(--header-height);
    position: fixed;
    width: 100%;
    transition: all 0.3s linear;
  }
  main {
    height: 150vh;
    padding-top: var(--header-height);
  }
  .pin {
    top: 0;
  }
  .unpin {
    top: calc(var(--header-height) * -1);
  }
</style>

<header class={headerClass} />
<main>Lorem ipsum</main>

Here is a sandbox with this code for your enjoyment:

Thanks for reading and happy coding! Please feel free to leave a comment or connect with me on twitter.

Two Simple Tips For Debugging In the Console

Thomas Collardeau — Tue, 20 Aug 2019 22:00:40 +0000

For my first post, I thought I would share 2 simple tips that I use when debugging Javascript in the console. You might very well know these already!

Reigning in the console

Not necessarily saying it's ideal, but if you're in the midst of an epic debugging sesh, you might end up in a situation with loads of console.log sprinkled all over your beautiful code like this:

console.log(isLoggedIn);
// sometime later:
console.log(user);
// in another file:
console.log(likes);
// more logs all over the place...
console.log(followers);

The flurry of logs in the console can quickly become a burden of confusion. What data belongs to what value, assuming we don't know what order they're even ran amidst the flow of our code?

One solution is that we can console.log('data: ', data), but we can also accomplish the same in fewer characters. What we can do instead is wrap our value in an object as such: console.log({ data }) and the console will print out the name of the variable before the data:

We're basically using ES6 shorthand syntax to log out an object that we create on the fly.

Refactoring Functions

Talk about ES6, another situation is that you might be writing your functions using more shorthand syntax like this:
const exclaim = txt => text + "!"
but then, some time later, you want to log txt, so you have to refactor the code to something like this:


const exclaim = txt => txt + "!"

// needs to become:

const exclaim = txt => {
  console.log(txt)
  return text + "!"
}

Almost makes you want to skip the whole task. Well, you can also do the following and still log the parameter:


const exclaim = txt => console.log(txt) || txt + "!";

What happens here is that the console.log runs as normal and evaluates to false, so the parser evaluates the second expression of the OR clause txt + "!" and returns it as they are no more expressions to check. We sneaked in that log along the way and threw it away essentially. As such we can keep our functions as one-liners and still inspect them without jumping around in the editor.

Until Next Time!

Looking forward to being part of this community and learning along with everybody!