DEV Community: a Mediocre Dev

Svelthursday: SVGs

a Mediocre Dev — Thu, 11 Nov 2021 22:26:12 +0000

What is this?

Having recently fallen in love with Svelte, I have dove into it on the deep end. And let me tell you, it is awesome! With these short posts, I aim to explore some of the less covered topics that I encounter as I write stuff in Svelte.

Example repository can be found here.

Alright, it's time to dig in... Thirty seconds, go!

SVG Components

Rich Harris, the creator of Svelte, is was a graphics editor at the New York Times, and so you'd be excused for thinking that Svelte would make SVGs easy. The truth is, that's not always the case (as is true for other libraries and frameworks). However, Svelte does provide some powerful tools for working with SVGs.

The Basics

A common usecase is to import svgs from a static file wrapped in an <svg> tag, using the <use> tag with the href="/some-svg.svg"-attribute. This does not work with Svelte, at least not as it is. This would require a few extra steps involving a <symbol> tag and an id attribute in the original SVG, and ultimately it is not a very flexible.

Importing the SVG-file in the <script> tag is also a common way to attempt to do this, but this solution also requires some extra steps.

In fact Googling this issue will yield a number of solutions. One solution, however, I would propose is superior to the others (and it is an easy one to implement).

Simply renaming your SVG file from a .svg to a .svelte and importing it as a component is pretty much all you need to do. I have to admit I balked at this solution at first as I prefer to keep my SVGs as .svg files. Yet, this opens a world of possibilities, most notably enabling dynamic SVGs.

Let's start with a simple example:

<!-- line-chart.svelte -->
<svg
    version="1.2"
    xmlns="http://www.w3.org/2000/svg"
    width="100%"
    height="100%"
    viewbox="0 0 1000 1000"
>
    <path d="M1 0v300" class="grid x-grid" stroke="#111" stroke-width="2" />
    <path d="M1 299h600" class="grid y-grid" stroke="#111" stroke-width="2" />
    <g stroke="black">
        <line x1="0" y1="170" x2="100" y2="190" />
        <line x1="100" y1="190" x2="200" y2="120" />
        <line x1="200" y1="120" x2="300" y2="180" />
        <line x1="300" y1="180" x2="400" y2="200" />
        <line x1="400" y1="200" x2="500" y2="100" />
    </g>
</svg>

This produces a rather crude line chart like so:

And we import it simply as a component:

<!-- index.svelte -->
<script>
    import LineChart from "path/to/line-chart.svelte";
</script>

<LineChart />

Easy!

I Have the Power!

You might be seeing where this is going. Since the SVG is now a Svelte component, this means we can treat it like any other svelte component and it will still produce an actual SVG.

Taking programmatically generating SVGs to the next level!

How about:

<!-- line-chart.svelte -->
<svg
    version="1.2"
    xmlns="http://www.w3.org/2000/svg"
    width="100%"
    height="100%"
    viewbox="0 0 1000 1000"
>
    <g class="labels">
        <text x="50" y="320">2008</text>
        <text x="150" y="320">2009</text>
        <text x="250" y="320">2010</text>
        <text x="350" y="320">2011</text>
        <text x="450" y="320">2012</text>
        <text x="250" y="340">Year</text>
    </g>
    <g class="labels y-labels">
        <text x="40" y="10">300'</text>
        <text x="40" y="100">200'</text>
        <text x="40" y="200">100'</text>
        <text x="40" y="300">0</text>
        <text x="20" y="150" class="y-label-title">Price</text>
    </g>
    <path d="M50 0v300" />
    <path d="M50 299h500" />
    <g stroke-dasharray="0 4 0">
        <line x1="50" y1="170" x2="150" y2="190" />
        <line x1="150" y1="190" x2="250" y2="120" />
        <line x1="250" y1="120" x2="350" y2="180" />
        <line x1="350" y1="180" x2="450" y2="200" />
        <line x1="450" y1="200" x2="550" y2="100" />
    </g>
</svg>

<style>
    svg {
        --color: #111;
    }

    line,
    path {
        stroke: var(--color);
    }

    .labels {
        font-size: 12px;
        font-family: sans-serif;
        text-anchor: start;
    }
    .y-labels {
        text-anchor: end;
    }

    .y-label-title {
        text-anchor: start;
        transform: rotate(90deg);
        transform-origin: 2% 14%;
    }
</style>

Now our SVG looks more like this:

Data Driven SVGs

Taking the previous example, let's look at how we can dynamically generate the SVG. This is where the magic happens. What if we want to dynamically generate the y-axis data of each data point based on actual data passed into the component? Let's say we have a dataset of prices for each year. We can then use this data to dynamically generate the y-axis data like so:

<!-- line-chart.svelte -->
<script>
    export let prices_by_date = {
        y2008: 170,
        y2009: 100,
        y2010: 160,
        y2011: 120,
        y2012: 130,
        y2013: 200,
    };

    let y2008, y2009, y2010, y2011, y2012, y2013;

    $: ({ y2008, y2009, y2010, y2011, y2012, y2013 } = prices_by_date);
</script>

<svg
    version="1.2"
    xmlns="http://www.w3.org/2000/svg"
    width="100%"
    height="100%"
    viewbox="0 0 1000 1000"
>
    <g class="labels">
        <text x="50" y="320">2008</text>
        <text x="150" y="320">2009</text>
        <text x="250" y="320">2010</text>
        <text x="350" y="320">2011</text>
        <text x="450" y="320">2012</text>
        <text x="250" y="340">Year</text>
    </g>
    <g class="labels y-labels">
        <text x="40" y="10">300'</text>
        <text x="40" y="100">200'</text>
        <text x="40" y="200">100'</text>
        <text x="40" y="300">0</text>
        <text x="20" y="150" class="y-label-title">Price</text>
    </g>
    <path d="M50 0v300" />
    <path d="M50 299h500" />
    <g stroke-dasharray="0 4 0">
        <line x1="50" y1={300 - y2008} x2="150" y2={300 - y2009} />
        <line x1="150" y1={300 - y2009} x2="250" y2={300 - y2010} />
        <line x1="250" y1={300 - y2010} x2="350" y2={300 - y2011} />
        <line x1="350" y1={300 - y2011} x2="450" y2={300 - y2012} />
        <line x1="450" y1={300 - y2012} x2="550" y2={300 - y2013} />
    </g>
</svg>

<style>
    svg {
        --color: #111;
    }

    path {
        stroke: var(--color);
    }

    .labels {
        font-size: 12px;
        font-family: sans-serif;
        text-anchor: start;
    }
    .y-labels {
        text-anchor: end;
    }

    .y-label-title {
        text-anchor: start;
        transform: rotate(90deg);
        transform-origin: 2% 14%;
    }
</style>

This is but one simple example of how we can dynamically generate SVGs. And much is still hardcoded. A recent tweet by @joshnuss displays a much more sophisticated example of this same idea. I recently published a component that builds on the same principles to produce Squircle-type shapes.

Hope this was a bit insightful. If you have any questions or comments, please let me know!

Bonus!

Svelte has a curious feature called <svelte:options namespace="svg">, and it is not well documented (beyond indicating that you force a namespace).

What it does and what it is intended for is to force the compiler to use the SVG namespace when generating the component, regardless of what tags you are using in the component. For example should you use a div in your svg component the compiler will create it using the document.createElementNS method as opposed to just document.createElement. This might be helpful in instances where you are using non-standard tags in your SVG, and there are issues with your SVG, or you are seeing unexpected behavior. Beyond that, you do not need to declare this namespace in your component as Sveltes compiler is smart enough to figure out what namespace to use in most instances.

Svelthursday: Nested Store Values

a Mediocre Dev — Thu, 21 Oct 2021 21:03:53 +0000

What is this?

Example repository can be found here.

Alright, it's time to dig in... Thirty seconds, go!

Nested Store Values

A lot of Svelte examples show you how to handle stores that contain primitive values or a simple object. But how about arrays of objects? Or deeply nested objects?

Tip: Svelte stores are powerful, and it might be tempting to put everything in a single store. Better practice, however, is to split larger data objects into separate stores and combine them using derived stores. Read on!

Say we want to create a shopping cart modal that iterates over an array of products in our shopping cart, like so:

We start off with a store containing all the products.

const cart = writable([{
    name: "Nintendo Switch OLED 2021",
    image: "/images/switch.webp",
    description: "Nintendo Switch with OLED-Display, 64GB internal storage",
    sku: "0934192",
    price: 499,
    count: 1
}, {
    name: "Metroid Dread",
    image: "/images/dread.webp",
    description: "Hottest Nintendo Switch game",
    sku: "10329362",
    price: 59.98,
    count: 1
}]);

Notice we have a count property. Maybe we want the customer to be able to change this value and sync this value with the store. Easy enough:

<ol type="list">
    {#each $cart as { sku, image, description, name, count, price } (sku)}
    <li>
        <a href="/products/{sku}"><img src="{image}" alt="{name} product image"/></a>
        <a href="/products/{sku}"><h4>{name}</h4></a>
        <p>${price}</p>
        <p>{description}</p>
        <div>
            <span>Qty:</span>
            <input bind:value="{count}" type="number" min="0" />
        </div>
    </li>
    {/each}
</ol>

The bind:value="{count}" is what does the magic. This will reactively update the store for us as we change the value, just like we would expect.

Hold up!

There is one gotcha here at the moment. Say for some silly reason we want to use this as a template and dynamically bind the input to either price or quantity:

<ol type="list">
    {#each $cart as { sku, image, description, name, ...rest } (sku)}
    <li>
        <a href="/products/{sku}"><img src="{image}" alt="{name} product image"/></a>
        <a href="/products/{sku}"><h4>{name}</h4></a>
        <p>${rest.price}</p>
        <p>{description}</p>
        <div>
            <input bind:value={rest["price"]} type="number" min="0" />
        </div>
    </li>
    {/each}
</ol>

So we use the spread operator to gather the dynamically allocated variables and index into the price property. Our input suddenly becomes unresponsive. To circumvent this we can actually further nest those values in our store like so:

...
cart: {
    count: 1,
    price: 499
}

And index into it in the input like so:

<input bind:value={rest.cart["price"]} type="number" min="0" />

And now our input works again.

I have filed a bug report about this.

Finally, lets get the total.

Derived, derived, derived

A derived store in Svelte can take one or more stores and combine them. In a future post on stores I will look at how you combine several stores. But for now lets see a basic use case.

To get the total (quantity multiplied by price, summed) we can use a derived store like so:

const total = derived(cart, (cart) =>
    cart.reduce((acc, item) => {
        return acc + item.price * item.count;
    }, 0)
);

The first parameter is the store or collection of stores we want to pass into the derived store, and the second argument a callback function that takes the values of each passed store as an array, and the set method as a second argument. The callback then returns the derived value (and can alternately alter the passed stores through the set function).

This makes derived stores extremely powerful constructs. And the example above barely scratches the surface by returning the accumulated sum of the price multiplied by quantity using the reduce method.

That's it! You made it this far. Hope you learned something, and chime off in the comments or message me if there is anything you want to learn more about in Svelte, or if you have discovered some cool techniques with stores.

Have a great Svelthursday!

Why you are (probably) using the wrong theme

a Mediocre Dev — Thu, 23 Sep 2021 20:04:42 +0000

The problem with themes

Ever since I left my trusty notepad++, migrating to VS Code I became somewhat obsessed with finding a "perfect" theme. And by that I mean a theme that I could use without ever looking back. I tried about 30-40 themes, and some of them were really good, most were really bad.

Before you say it. Yes, peoples tastes are different and there is no theme that is objectively better. Or so you may think.

After searching I settled on Wes Bos' excellent theme Cobalt 2 for a while. Until I got irked by how bright it was, and moved to the extremely popular Night Owl by Sarah Drasner. The problem, I still wasn't entirely happy. Why italicize variable names? It makes them harder to read. Eventually I started to customize it (and like everyone else in that headspace; maybe I'd publish my own theme and gain some notoriety for it).

Deus Ex Machina

Enter, one indescript day in April. A user by the name u/kingcool1432 on reddit posts about a new theme they have made: Chandrian (a reference to an unfinished trilogy of fantasy books called The Kingkiller Chronicle).

What made this theme so special?

In the post the author claimed the following:

Chandrian is a semantic syntax highlighting theme, where the colors mean something, beyond just looking pretty. It's designed explicitly to make scanning large code-bases easier and to make errors more obvious.

Another user commented:

Isn't every theme designed to do that?

The answer should have been a resounding "Yes!". The reality is, that if that were the case then most themes have failed their job.

So how did the Chandrian theme succeed where other themes have failed?

Syntax Highlighting done right

Note! The examples I am showing in this post are from my own version of this theme. The syntax highlighting has stayed largely the same.

Let's take a look at some example HTML.

Doesn't look any different, perhaps? Did you spot the syntax error?

The syntax is highlighted in a way intended for you to recognize errors immediately in HTML, and shades of the same color are used to indicate different types of tags. Links are a stark contrasting color, while strings have their own reserved color space (and so does numbers). This red thread is interwoven throughout the whole theme. How about some SASS/CSS?

Again, the syntax is highlighted in such a way that you can easily identify different syntactical components. Variables? Orange, !important red, so as to best catch your attention. This is all carefully crafted by a person who has taken great care to understand how we read code. If you haven't already give this theme a star on github, or download it on the marketplace.

If you haven't been convinced yet, then this certainly will!

It's just so easy to skim through the code. Grammar you do not need to worry about have muted colors. Variable names are always white and functions blue, while classes are teal.

But that is standard fare, no?

Many themes make distinctions between these things. The real power of this type of syntax highlighting is how control flow pops. Red colors should be avoided, like debugger or this. While orange means you are breaking flow in some way. Yellow indicates conditionals, and in Typescript a muted rust red indicates a type declaration or interface.

And this only works because the surrounding syntax has a cool color, and so doesn't distract from the warmer colors. This is the way, without a shadow of doubt.

And for those of you who at this point are bursting with a need to be contrarian. How about some nested JSON:

What's with blue on blue?

The Chandrian theme's UI is barely modified from VS Code's standard UI. And as such looks like the cover image. For reference:

This was the only gripe I had with this theme. So I took my favorite theme UI (Night Owl) and transposed the syntax highlighting on top of it. For me this works really well. I find the contrast good enough and the blue colors are relaxing to look at.

If you are like me, you can find my version of the Chandrian/Night Owl theme here.

If not, then I would at least ask you to try out the Chandrian Theme. I'll be willing to bet that you will never look at another theme the same again 🔥🦉

Comparing Front End Frameworks

a Mediocre Dev — Sun, 19 Sep 2021 14:33:51 +0000

...the silly way.

I have been immersed in the JavaScript world for nigh on a year now, and have recently been exploring frontend frameworks in hopes of finding something I enjoy developing in. On my journey I have dabbled in various frameworks and enjoyed the learning. When comparing the developer experience between the different frameworks; one, silly, idea that crossed my mind was throwing some of them together in a single webapp. Otherwise called a monolith, or a collection of microfrontends.

What is this?

In essence, these are my thoughts on creating a small counter in four frameworks: React, Svelte, Vue, and Imba (technically a compiled language).

The page is hosted here: counterfyi.netlify.app

If you just want to see the code, you can do so here.

From 💡 to web

The idea to build a mini counter app came as I found counter.fyi while trawling domain registrars for a new collectible (it's only a hobby, I swear). The idea was simple enough, but as always, execution... to say that it was overkill is an understatement. I ended up using Podium (a microfrontends library developed by finn.no; an online marketplace local to my country—which is always exciting), and then dockerize the individual components in a monorepo.

Yikes!

The process deserves its own story. Let's instead dive into some code.

A Counter App in Four Frameworks

A counter is, by and large, one of the most common ways to get a feel for a framework. So much so, that Vite includes it in their scaffolded projects.

To make it a bit more interesting I decided to add shared state management between the components. For this I relied on Podium's MessageBus, building a small RxJS observable that each component implemented (I will write about it in a future post detailing the journey creating this experiment).

Another thing to note is that css was only implemented as a shared css file (since every component shares). So no comparison will be done on css, though it is certainly warranted when it comes to DX (Maybe I'll come back to do it and update the post at some point).

Quick disclaimer: I did set out to write each component as idiomatically as possible. I may have failed in that endeavour in some instances, don't shout at me.

React

Being an industry heavy (and the uncontested leader), it is no surprise that I decided to include it. I have dabbled some in React, but never felt I connected with it. Writing the component was, however, undeniably easy. And the only snag I hit was implementing the observable (beware the infamous useEffect infinite loop).

import React, { useEffect, useState } from "react";
import { globalCounterSub } from "../__services__/message.service";

function App() {
    const [count, setCount] = useState(0);
    const globalCounter = globalCounterSub("react-pod");

    useEffect(() => {
        const subscription = globalCounter.subscribe((n) => setCount(n));
        return subscription.unsubscribe;
    }, []);

    const decrement = () => globalCounter.update((n) => --n);
    const increment = () => globalCounter.update((n) => ++n);

    return (
        <article className="React">
            <button className="decrement" type="button" onClick={decrement}>
                &ndash;
            </button>
            <div className="number">{count}</div>
            <button className="increment" type="button" onClick={increment}>
                +
            </button>
        </article>
    );
}

export default App;

Another thing to note is that I wanted to make each component as similar as possible in terms of how and where I declared and called functions and implemented the shared state.

Most of DX comes down to the boilerplate and syntax you write initially. Then as the app grows or you work in a team on a larger codebase, readbility and maintanability begin to emerge as the single most important factors. React favours immutability to better facilitate maintenance and predictability (all of these factors influence each other). To my mind components in React are best when they are lean and small. See a component grow much larger than the component I wrote above and your eyes will start to glaze over as you attempt to comprehend which function affects what reactive state where in my opinion this is largely because React doesn't separate areas of concern well.

Svelte

As I have explored these frameworks, this one has stood out as one I would like to use more. Svelte is different from React, and Vue (see below), in that it requires a compilation step (honestly that does not describe it well as we usually bundle React and Vue builds and so the difference is rather imperceptible). What this allows Svelte is to work with the real DOM as opposed to a virtualized one (and as such gain a considerable increase in speed when updating the DOM).

<script>
    import { globalCounterSub } from "../__services__/message.service";

    const count = globalCounterSub("svelte-pod");
    const decrement = () => count.update((n) => --n);
    const increment = () => count.update((n) => ++n);
</script>

<article class="Svelte">
    <button class="decrement" type="button" on:click="{decrement}">&ndash;</button>
    <div class="number">{$count}</div>
    <button class="increment" type="button" on:click="{increment}">+</button>
</article>

That's probably as terse as it gets following the style guide I set for myself.

You are probably noticing how I do not have to do anything except register the namespace of the component with the observable. This is because Svelte supports RxJS observables out of the box. In the React component I had to use the useState hook to store the variable, and call setState in the subscription callback. With Svelte this is all handled for us. Another neat thing is the separation of concerns. There is a clear delineation between what is imperative logic, and what is declarative state.

The $ in {$count} is used to indicate to Svelte that this is a store value, and not the subscription itself. It is akin to a callback like this n => $count = n being passed to the subscription, assuming let $count; has been declared.

Vue

Vue has been my go to for some time. It is very similar to Svelte in terms of its separation of concerns (and does it a tiny bit better in my opinion). However, like React, it utilizes a virtual DOM. The issues I have with it at the moment is much the same I have with React, there is an old way to do things and a new way. In Vue this dichotomy is more pronounced in the old Options API and the new Composition API.

<script setup>
    import { ref, onMounted, onBeforeUnmount } from "vue";
    import { globalCounterSub } from "../__services__/message.service";

    defineProps({
        count: Number,
    });

    const count = ref(0);
    const globalCounter = globalCounterSub("svelte-pod");
    let subscription;

    onMounted(() => {
        subscription = globalCounter.subscribe((n) => (count.value = n));
    });
    onBeforeUnmount(() => subscription.unsubscribe);

    const decrement = () => globalCounter.update((n) => --n);
    const increment = () => globalCounter.update((n) => ++n);
</script>

<template>
    <article class="Vue">
        <button class="decrement" type="button" @click="decrement">&ndash;</button>
        <div class="number">{{ count }}</div>
        <button class="increment" type="button" @click="increment">+</button>
    </article>
</template>

Despite having a very clear separation of concerns. The <script> section is muddied by lifecycle hooks and having to define props to make sure this are passed into the template. Defining props this way is only necessary when using the setup modifier on <script>. The alternative would be to declare an object containing all the props and lifecycle properties as a default export (a considerably more messy-looking implementation). Had it not been for the DX that <script setup> provides I would likely not be as invested in Vue.

Imba

And now for something completely different. Yes, Imba is not a framework, and yes it is also the brainchild of a fellow countryman. Imba 2.0 is currently under development and it is looking a lot more mature than its first incarnation. Imba uses a memoized DOM as opposed to a virtual one. There are considerable efficiency improvements to DOM rendering speeds if we are to believe one of its creators. What I like about Imba is that it takes a lot of inspiration from other langauges, but also attempts to reconcile imperative logic with declarative state creating almost no separation of concerns. And you would be excused for thinking "but that just cannot work!". Yet somehow it does.

import { globalCounterSub } from "../__services__/message.service.js"

let count = 0

let globalCounter = globalCounterSub('imba-pod')

globalCounter.subscribe do(n)
    count = n
    imba.commit!

def decrement do globalCounter.update do(n) --n
def increment do globalCounter.update do(n) ++n

def app
    <article.Imba>
        <button.decrement @click=decrement> "–"
        <div.number> count
        <button.increment @click=increment> "+"

imba.mount app, document.querySelector("#imba-pod")

Seeing that you probably have a lot of questions. I would advise taking a brief look at the documentation as you try to make heads or tails of this. Or maybe you don't need to. If you are familiar with Ruby or Python this shouldn't look all too foreign. That said, diving into Imba will invariably mean learning a lot of new syntax and grammar. You also treat the html equivalent as just another part of the language. Which, unlike JSX, means that you can be a lot more creative with how you create your components (once you get used to all the quirks this language offers).

All in all I like Imba and am excited to see where it will go in the future. Elm is another contender in this arena that I have yet to take a look at. It certainly seems a bit more imposing than Imba. Either way, as WebAssembly settles into its role on the web, and Custom Elements become more usable, these types of languages that blur the line between HTML, CSS and Javascript, will only become more relevant.

Conclusion

Going forward, I found that Svelte is the framework I am sticking to for the foreseeable future. That said, I am excitedly following the development of Imba, and I am by no means averse to working in React or Vue (they are great, but the foundations they are built on are not aging well). That said, JavaScript frameworks are a dime a dozen, a new one sprouting from the back of another every time a developer sneezes. I could have included Solid, Alpine, Lit, or Stimulus, to name a few. I have looked at all of them, and Alpine intrigued me, while Solid seems like something you will migrate your React project to at some point in the future.

"But wait! You haven't mentioned Angular." - I hear you scream in internal monologue. You are right, I haven't, and this is the last time I do.