Johan Ronsse

  • Home
  • Projects
  • Blog
  • 3 things about Storybook’s CSF3 that were not that clear immediately

    March 11, 2023 - Posted in development storybook ui webdev

    I recently started switching a Storybook that was based on the MDX format to the Component Story Format 3.0 format, skipping the 2.0 entirely… so some things were not that clear to me. I’m documenting them here for the reference of myself and others. Thse examples work in Storybook 6.5, and I believe also in 7.0 since the team worked on full backwards compatibility.

    You can pass storyName below an exported story to give it another name:

    export const HeadingWithSpacingExamples = () => (
      <>
        <Heading variant="h1" spacing>
          h1
        </Heading>
        <Heading variant="h2" spacing>
          h2
        </Heading>
        <Heading variant="h3" spacing>
          h3
        </Heading>
        <Heading variant="h4" spacing>
          h4
        </Heading>
      </>
    );
    
    HeadingWithSpacingExamples.storyName = 'With spacing';

    You can add a description to a component using parameters.docs.description.story :

    export const HeadingExamples = () => (
      <>
        <Heading variant="h1">h1</Heading>
        <Heading variant="h2">h2</Heading>
        <Heading variant="h3">h3</Heading>
        <Heading variant="h4">h4</Heading>
      </>
    );
    
    HeadingExamples.parameters = {
      docs: {
        description: {
          story: 'The component doesn’t have built-in spacing by default.',
        },
      },
    };

    You can add a description to a (top level) component itself by passing parameters.docs.description.component:

    export default {
      title: 'Typography/Heading',
      component: Heading,
    
      args: {
        variant: 'h1',
        children: 'Heading',
      },
      parameters: {
        docs: {
          description: {
            component: 'The header component.',
          },
        },
      },
    };
    

    This is a bit wieldy, so in the newest Storybook, 7.0, you apparently you can do that with JSDoc:

    /**
     * @description My description
     */

    I’ve yet to test that.

  • Mexico (2)

    March 8, 2023 - Posted in lifelog mexico persoonlijk reflectie

    Een update na 2,5 maand. Zoals ik in mijn vorige post rapporteerde wordt ik het hier wel wat gewoon.

    Het appartment krijgt meubel-gewijs vorm. Het opstaan op een ontieglijk uur lukt wonderwel – en dat voor een avondmens.

    Qua werk neigt het meer naar front-end dezer dagen. Uit eigen keus – ik wil graag software écht naar een hoger niveau krijgen niet blijven steken in concept designs.

    We gebruiken wel niet echt mijn favo technologie (React…) maar ik leer wel het een en ander bij over software engineering.

    Na jaren nooit echt de switch te maken naar een “echte” IDE heb ik nu écht de switch gemaakt naar IntelliJ.

    Ik moet wat meer tijd steken in Spaans leren, maar heb eigenlijk wel vrij veel werk. Ik denk dat het echte taalniveau er pas van gaat komen als ik a) ofwel een dedicated cursus volg of b) in een Mexicaanse context zou werken. Het eerste zou er nog van kunnen komen, voor het 2e is de kans vrij klein. Europese of Amerikaanse klanten betalen nu eenmaal beter ;)

    Qua games heb ik na een lange gameloze-periode (met uitzondering van Tunic als tussendoortje in de kerstvakantie) eindelijk tijd kunnen maken voor 2 games: Age of Empires 4 en Elden Ring.

    AoE4 neemt de bovenhand met ondertussen al een kleine 30 uur op de teller. De verschillende civs zijn leuk om mee te leren spelen, en ook al draait het vrij brak op mijn oude MBP15, het blijft leuk.

    Elden Ring moet nog een beetje openbloeien, voorlopig vind ik het alvast vrij enjoyable. Ik zit een paar uur in de game en hoor dat het pas na een acht of tiental uur echt begint.

    Daarnaast, niet om de Belgen jaloers te maken, maar hier is het lekker 28 graden. Iets te warms zelfs.

    Qua vrienden is het een beetje zoeken. Ik moet nog een beetje socialer worden denk ik. Misschien iets van sport oppikken. Heb alvast mijn fiets ietwat beter laten afstellen.

    Qua reizen heb ik een ticket voor CSS day geboekt, in juni – en in augustus ga ik ook nog een keer richting Europa. Er zijn wel wat reizen gepland. En mijn familie komt eens een kijkje nemen in Mexico stad! Hoera.

    Over en uit!

  • Mexico

    February 7, 2023 - Posted in lifelog mexico persoonlijk reflectie

    Ik word het wel wat gewoon hier na een dikke 1,5 maand. We hebben nu een appartementje. Ik heb een visum voor een jaar. Ik weet waar ik mijn inkopen moet doen. Heb een fiets gekocht en een computerscherm.

    En donderdag komt er een nieuwe bureau aan. De IKEA hier was precies door al zijn voorraad, maar op een dag was ik nog eens aan het checken en – aha! – mijn bureaustoel en voorkeursbureau was terug op voorraad. Er moet een boot van Zweden zijn gekomen, ofzo.

    Ik probeer op te staan om 5u30 om de Europese middag mee te pakken – om 6u aan mijn bureau, dan is het 13u in België. Voorlopig gaat dat goed, vind ik. Ik zou het eens aan mijn collega’s moeten vragen wat zij vinden. Maar één stiekem voordeel is dat ik in de namiddag nooit meetings heb, en dus lekker geconcentreerd kan doorwerken.

    Het thema van de voorbije maand is een nieuw project waar ik bijzonder weinig over kan zeggen. Daarnaast probeer ik de front-end implementatie van ons design systeem op een nieuwe niveau te brengen. Na een tweetal maanden mobile design verwelkom ik terug een beetje front-end.

    Mijn werkdag stopt dan typisch rond 15u30-16u afhankelijk van hoeveel pauzes. En dan zou je denken: dan heb je nog een hele dag om dingen te doen… maar de realiteit is, een mens heeft maar zoveel energie, dus ergens rond 20u30 of 21u is het al bedtijd. Een heel ander ritme dan om middernacht gaan slapen in België.

    Wat ik mis: mijn vrienden, mijn familie, en raar maar waar, om een beetje op de hoogte te zijn van de Belgische (politieke) actualiteit. Nog iets dat ik mis: de kwaliteit van de supermarkten. Wat ik niet mis: donkere winters, de Belgische regen, het verkeer rond Antwerpen, en de NMBS.

    En o ja, ik wil jullie niet jaloers maken, maar het is hier 25 graden vandaag.

  • Fixing e-mail signatures for Apple Mail in macOS Ventura

    December 20, 2022 - Posted in emails macos signature

    This is an update to “Adding an HTML signature to Apple Mail (and have it show up properly!)”

    After upgrading to Ventura, my lovely e-mail signature showed up with missing images.

    A bit of Googling brought me to a solution.

    For each image, instead of the image, use an HTML element (e.g. a or div) with the width and height of the original image, and a background image that is encoded as base64 (for Apple mail), with a fallback to the image URL (for gmail).

    For example:

    <div style='color: transparent; width: 30px; height: 30px; display: inline-block; background: none; background-image: url("data:image/png;base64,BASE64HERE"), url("IMGURLHERE"); background-size: cover;'>&nbsp</div>

    Apply this logic to your code, and the images will work again.

  • Property toggle in Figma

    December 5, 2022 - Posted in figma ui workflow

    Leuk, zo met 1 klik van dark naar light mode met deze plugin.

  • Ontspullen

    November 20, 2022 - Posted in positief

    Ik ben wegens aankomende verhuis vanalles aan het wegdoen, en wat een deugd is eigenlijk dat buurtplatform Hoplr niet?

    Ik heb gisteren een tiental mensen iets kunnen geven, en sommigen waren échtig blij met wat ze hadden gekregen.

  • IntelliJ Idea: run stylelint after save

    September 20, 2022 - Posted in development webdev

    It is time to drop some esoteric knowledge again, for the Googling people that get into the same pickle as me. And for myself, when I have this problem on a new machine.

    So the problem is as follows: sometimes you get into a situation where formatting on save goes against the rules set in your project’s .stylelintrc. I got into this situation where, for a reason unbeknowst, the editor was intent on removing the spaces between the parentheses in code like this:

    @media ( max-width: 500px ) {
    
    }

    So basically changing it to…

    @media (max-width: 500px) {
    
    }

    I personally think that is the best formatting, but to stop syntax discussions the coding gods have invented eslint and stylelint, and who am I, as a new dev on the team, to go against a rule? I don’t even want to have those discussions anyway.

    If you’re curious, it’s this stylelint rule.

    "media-feature-parentheses-space-inside": "always"

    I took me a while, but… after combining several blog posts I found the right settings. You will need to go to Tools > File Watchers in the settings (you will need the File Watchers plugin), and create a new setting. These are the settings you need:

    • Program: $ProjectFileDir$/node_modules/.bin/stylelint
    • Arguments: $FilePath$ --fix -s scss --config $ProjectFileDir$/.stylelintrc
    • Output paths to refresh: $FilePath$

    In the process I learned that IntelliJ Idea has even more settings than I thought.

    BTW. I think after many years of just happily coding without any IDE “help”, I think I might have found my new editor. VSCode never really sat with me. But I can work with this.

    Happy coding!

  • SvelteKit form actions are the bomb

    September 11, 2022 - Posted in svelte webdev - 2 comments

    In the video above I demonstrate a little app and its code in a slightly unorderly fashion, so I thought I’d put some words down and hopefully make things more clear.

    First of all, this is just a demo app and not a real-life application, although it contains concepts that a real-life application will need like environment variables, progressive enhancement, data fetching, calling an API etc.

    I re-architected an earlier version of this todo app to use the latest changes in SvelteKit. The old version used fetch calls all over the place and was hardly optimized. I made it a few months ago to practice with HTTP verbs like PATCH, PUT, DELETE etc.

    This new version works way better, and behind the scenes it’s using the latest SvelteKit logic. This means using +page.js – +page.server.js, the new load function etc.

    These todo demos might seem silly but serve the purpose of showing how a real-world app could look like in the fewest lines of code. They’re a way to practice and evaluate the concepts behind something.

    In the case of the Sveltekit todo app (I mean the official one, which you can see by generating a new SvelteKit project), an API is called, and you can add, edit and delete todo items.

    In my demo app, there is similar functionality, although a Trello board is being used as a back-end.

    The reason that I do this is so that this way I don’t need to build an API (a skill I currently don’t have) and I can (1) use their excellent documentation and (2) I can focus on the heart of the matter, which is building a working app where I can experiment with doing things that a real-world app should do i.e. all your CRUD-y goodness: add stuff, modify stuff, delete stuff.

    Buuuut here I can do it in a way that is super modern. The gist of the techniques used is that you can have all the benefits of an MPA + SPA combined.

    It’s quite hard to explain, because you’d have to piece together a few of Rich Harris’s Svelte/SvelteKit talks to really make sense of it. But I’ll give it a shot.

    In one of them he had a progressively enhanced form demo. He disabled JS and his form still worked. Because everything ran on the server, and was only progressively enhanced by the client.

    In his newest talk at the real-life Svelte Summit (which I just attended in Stockholm) he came up with another demo, this time implementing Sverdle, a Wordle clone in SvelteKit. The same logic applied here – fully running on the server, enhanced on the client.

    If you ever read about Remix for React this will sound very familiar. SvelteKit is built using as much of the web platform as possible (we are talking FormData, actions inspired by HTTP verbs etc.).

    I think all of this is very exciting and I couldn’t wait to try it out, so that’s what I did. You can watch the video for my full explanation.

    I find the code logic behind this to be beautiful.

    For example, the code belows shows a simplified delete button, tied to a form action. The first part of the code lives in the +page.js template, the other in the +page.server.js file.

      <form
        action="?/delete"
        method="POST"
        use:enhance={() => {
          return ({ form, result }) => {
            if (result.type === 'success') {
              deleted = true
            }
          };
        }}
      >
        <input type="hidden" name="id" value={data.id}>
        <button>Delete</button>
      </form>
    export const actions = {
      delete: async ({ request, locals }) => {
        const form = await request.formData();
        await api('DELETE', 'cards/'+form.get('id'));
      }
    }

    You could make a small form for every CRUD action on the page (like in SvelteKit’s demo app) or work with bigger forms that do more.

    I love this new approach of working in SvelteKit. It is so concise, yet it does so much. I believe SvelteKit form actions are the bomb and usher in the future of forms in web apps. No more controlled inputs. Hello server side rendering and progressive enhancement!

    You can find the GitHub repo for this project here.

  • WP6

    September 3, 2022 - Posted in development wordpress - 1 comment

    Ik heb zitten nadenken over de veranderingen in WordPress 6 “Arturo”, met als nieuwigheid dat full-site editing gegeven.

    Ik heb dat eigenlijk eerlijk gezegd nog nooit zien werken in de praktijk, dus ik sta daar wat skeptisch tegenover.

    Voor een eenvoudige website zie ik het nog wel werken, maar ergens ook weer niet. Elke vrijheid die je krijgt in de editor heeft een “andere kant”, die voor mij in de weg staat van de finale kwaliteit.

    Stel dat je bv. iets in 2 kolommen zet. Dan moet je eigenlijk ook weer een definitie hebben van wat er mee gebeurt op een klein scherm.

    Stel dat je een knopje een kleur geeft. Oké, goed, maar wat met de hover, active, focus state enzovoort?

    Als designer die let op elk detail wil ik een goed eindresultaat. Hoe geavanceerder de vorm van customization door de eindgebruiker, hoe meer “controle” je afgeeft. Of hoe meer werk je dan hebt om de oneindigheid aan variaties die dan mogelijk zijn te kunnen voorzien.

    Ik besef wel dat het keurslijf waar je enkel een tekstveldje kan aanpassen een beetje 1997 is, en je als content editor wel wat opties wilt om de layout te krijgen die je wil.

    Dat is altijd al een moeilijke balans geweest, sinds de eerste dagen als web designer. Vanuit technisch vlak moet je dan eigenlijk beslissen: wat is hardcoded, aanpasbaar, en indien aanpasbaar, in welke mate? Ik wil niet weten hoeveel werkuren er al verspild zijn in de wereld om iets aanpasbaar te maken, waar het dan in de praktijk nooit werd gedaan.

    Ik gebruik WordPress al 16 jaar. Door de jaren heen heb ik vooral minimale thema’s geschreven die de standaard have_posts loop gebruiken, met volledige controle over welke HTML en CSS er allemaal binnen komt. Zo min mogelijk plugins en zo veel mogelijk gebruik makend van functionaliteiten zoals custom post types en de manier om in te haken op zaken uit het CMS zoals de navigatie (wp_nav).

    Voor use cases waar ik mijn eigen klant ben, ben ik overgeschakeld op een systeem dat ik voor sommige pagina’s vooral statische content had.

    Dat is echt doodeenvoudig, je maakt een nieuwe PHP file, en als die zo geformatteerd is, wordt die beschikbaar als template:

    <?php
    /**
     * Template Name: home
     */
    ?>
    

    Omdat het toch vooral voor mezelf/mijn bedrijf was, en we als team de skills hadden om zo te werken was dat lang “the way to go”. Dan pasten we gewoon de template aan, hardcoded, en hup, deployen maar.

    We hebben ook ooit eens een WP-expert ingehuurd om het allemaal wat properder te zetten, met een moderne PHP logica.

    Aan de kant van het bloggen en websites beheren ben ik tevreden met WordPress omdat er effectief een CMS-kant is, en als ik in schrijf-modus ben dat ik écht niet naar mijn terminal wil gaan, een markdown file openen, de laatste git versie uitchecken etc…

    De trend van static sites (onder devs) is misschien leuk als tech-demo en voor sommige mensen werkt het misschien (als je dat dev-gegeven toch al leeft), maar voor mij niet. Ik heb geen zin om mijn website elke 2 jaar te herschrijven in het laatste framework. De code van vandaag gaat al mee sinds 2015, en dat was dan weer een evolutie van code van daarvoor.

    Af en toe schreef ik er een stukje bij als ik het nodig heb of motivatie heb, zoals dark mode of de code voor propere code-blokken. Maar eigenlijk is al die code al jaren vrij stabiel, en doet die wat het moet doen.

    Ik ben ook eens erg onder de indruk geweest van Advanced Custom Fields, en heb dat onthouden als dé manier om iets geavanceerd en gestructureerd in WordPress te krijgen (samen met custom post types). Ik heb eens een heel portfolio systeem uitgedacht voor de Mono site, om dan erna een jaar gefrustreerd te zijn dat we bijna niks in ons portfolio mochten zetten.

    Terug over full-site editing dan.

    Ik heb er ook schrik voor dat die evolutie misschien zorgt voor een niet-juiste scheiding van de data en de layout.

    Met het Gutenberg project (en in het algemeen de “blocks” trend in zaken als Coda, Notion etc.) krijg je eigenlijk data exports waar de metadata van de layout vervat zit op de plek van het “blokje” zelf.

    Of situaties waar die informatie tout court niet aanwezig is, waardoor je export eigenlijk een onvolledig beeld geeft.

    Dat wordt wel ingewikkeld om te onderhouden en te transporteren naar toekomstige systemen.

    Ik ben in het algemeen toch een voorstander van iets dat jaren kan meegaan. Ook daarom hou ik niet zo van die headless CMS trend, waar ik weinig stabiliteit in zie.

    Dus… ik ben eigenlijk niet geneigd om als ik een nieuw web project heb, mee te gaan met heel die nieuwe WP redenering.

    Misschien is het dan toch tijd om eens een ander CMS te overwegen. Of misschien moet ik me openstellen voor deze manier van werken. Ik werk dagelijks als UI designer in een software context, met af en toe een front-end development uitstap.

    Ik ben te weinig met web design in de praktijk bezig om er echt een mening over te formuleren. Misschien zit er in mijn lezerspubliek wel iemand die deze nieuwe problematiek beter beheerst. Wat denken jullie?

  • Natural sort order

    August 21, 2022 - Posted in development javascript rant - 1 comment

    I was doing some administration in the awful BillToBox (seriously not happy with this “solution”, but that’s another topic for another day), and to try and make sense of my uploaded documents I sorted them by name:

    Look at the “Naam van he…” column.

    What the hell is going on with this sorting? 82, 83, 86, 85, 84? Hu? (Expected behaviour is 86, 85, 84, 83, 82…)

    In which world does this make any sense? It doesn’t even seem to be a case where they forgot to implement natural sort order – it’s just… wrong?

    This Svelte REPL shows a quick implementation of natural sort order sorting. Jeff from CodingHorror explains the problem in this 2007 blog post.

    Reminds me to maybe go for a tried and tested solution instead of reinventing the wheel when we revamp filtering & sorting in my current project… as there are always lots of things you don’t think about, until you encounter the problem.

← older
newer →
  • ©2025 Johan Ronsse
  • X
  • Mastodon
  • Portfolio 2024