DEV Community: Alex Riviere

Grid First, Flex Third

Alex Riviere — Sun, 23 Mar 2025 11:55:29 +0000

I’ve been mulling this topic for months now, and I’m pretty firmly of the opinion if you are attempting to do some layout in CSS, you should reach for display:grid first, followed by display:block, followed by display:flex. Grid allows the layout element to be in control of how things get placed, where as flex really relies on the children to define their widths, which most of the time is not how layout should function at all.

Grid First

I’ve been working in a very flex heavy codebase the last couple of years, and there are multiple instances where I have needed to rework multiple components that have used a combination of nested flexbox, position relative/absolute, and lots of growing, shrinking, and hardcoded sizes. Most of these issues have been resolved by deleting those styles and turning the layout portion into a grid.

An example of this would be a text input component. Within this text input component, we had a flexbox layout for the input, that would optionally add margins to the input if there was an icon prop for the start or end, e icons would then be positioned absolute to make sure they ended up at the correct end. This got weird when you started to ltr vs rtl languages, and there was a whole lot of javascript logic just to figure out where and icon needed to go, and which margin needed to be applied.

Now I recognize not everyone has this problem, but honestly, it was solved pretty much instantly with a single grid definition.

.input-wrapper{
  display: inline-grid;
  grid-template-areas: "front-icon input back-icon";
  grid-template-columns: auto 1fr auto;
}

This definition let us assign the starting icon to the “front-icon” grid area, the ending icon to the “back-icon” area, and those will only have width if there is content in there. Done.

I have more examples of patterns like this where flex box just gets in the way more than helps.

Block Second

So this might be a hot take, but i have a lof of places in my work code base that still have the following style:

.descriptive-class-name{
  display: flex;
  flex-flow: column nowrap;
  justify-content: start;
  align-items: start;
}

Congratulations! You’ve made a bunch of blocks! You have successfully created the least useful css statement. This is pretty much the equivalent of this:

.descriptive-class-name>*{
  display:block;
}

Now i can hear some of you saying, “But Alex, what if you want to flip it from being a column to a row?” If this were the case, we wouldn’t be having this conversation. But it isn’t. This is extra code for the sake of “being in control”. Stop it.

A lot of times, you don’t need flex for the thing that you are doing, you need something else. This is one of those cases.

Flex Third

Sometimes, you do actually need/want flexbox. Displaying a grid of cards is a great time to use flexbox (Until you need the contents inside the cards to line up, then you probably want grid and subgrid). Quickly centering something, flexbox is a great option (but so is grid, thus negating this point).

We have better more powerful tools for layout. Reaching for display:flex because you are more comfortable with it does not make it the best choice. If we only reached for what we were comfortable with we would all be doing layout with table elements still, and no one wants that (looking at you, MS Outlook).

Recent Container Query Use: Content next to navigation

Alex Riviere — Mon, 16 Sep 2024 14:33:19 +0000

At work we have a standard layout we are using where there is a nav bar on the left hand side of the screen and content on the right hand side of the screen (this gets flipped for RTL languages). The nav bar can be in an expanded or collapsed state.

Rather than trying to have multiple media queries for the content area to the right based on whether the nav bar is expanded or collapsed, we’re making the right hand side content be a container. Now within that area, pages can style things with container queries based on the inline-size of the content container without having to track the current state of the sidebar.

My Recent Container Query Use: Pagination

Alex Riviere — Mon, 27 May 2024 06:08:44 +0000

I recently read the post We’ve Got Container Queries Now, But Are We Actually Using Them? over at Frontend Masters Boost, and I realized that it would probably be helpful for me to document real world uses for container queries.

Today’s example: A Pagination Component.

We recently rewrote pagination at work, and I decided this is an excellent use for container queries. The pagination component has 2 modes: “Big” mode and “Little” mode which really only care about how much horizontal space they have. In most applications this can be done with media queries as your pagination is a top level thing, but we have a lot of content that gets paginated inside of modals, which may or may not take up the full screen.

Our “Big” mode is when you have multiple page links (think like 10+) and you want to have the pattern display each page link. We use a list of links and also need a “previous” and “next” button at the end. The “Little” mode is what you might think of as “mobile mode” where rather than a list of links, we use a form that has a drop down with the page options. This isn’t just for mobile but can also be used for small paginated lists.

CSS Example

.pagination-container {
  /* create a pagination container based on the inline size*/
  container: pagination / inline-size;
  /* apply some good styling */
  display: flex;
  justify-content: center;
  align-items: center;
  gap: 1ch;
  font-size: 1.4rem;
  border: 2px solid hotpink;
}

.page-links {
  /* hide "Big" mode by default */
  display: none;
  list-style: none;
  gap: 1ch;
  margin: 0;
  padding: 0;

  /* when it is wider than 30ch, display it*/
  @container pagination (min-width: 30ch) {
    display: flex;
  }
}

.page-form {
  /* display "Little" mode by default */
  display: flex;
  flex-flow: row wrap;
  justify-content: center;
  align-items: center;
  /* Hide it when it reached 30ch wide */
  @container pagination (min-width: 30ch) {
    display: none;
  }
}

Codepen Demo

React 19 Beta: Fine I Guess Web Standards Are Okay

Alex Riviere — Thu, 25 Apr 2024 21:02:43 +0000

This post is gonna be salty, but after years and years of teaching developers to add click handlers to divs, add inputs with no labels, and generally insisting that they know better than you, react has released their version 19 beta and it includes support for web components and form actions.

React has had the ability to add support for custom elements for LITERALLY YEARS, as there has been a separate experimental branch that was kept up to date and ready to be merged, but never was. So 6 YEARS after custom elements are generally available in every modern browser the react team has decided to BLESS us with the ability to use a native browser feature. After years and years of damage to the ecosystem, and now that pretty much every library that wants to make something, makes things react first, they throw an olive branch to say “Alright peasants, we will support your silly little elements.”

Similarly, after years and years of saying “Bind a value to every input and don’t worry about using forms” SUDDENLY, it’s now going to be best practice to use forms. How many projects will never implement this? How many countless hours have people spent making pointless click handlers and extra event listeners so that they could replicate a form’s functionality, for the react team to say “Ok, yeah, maybe this web standard is a good idea.”

The damage from React has already been done, and no amount of “Oh look at this thing we can do” will fix it.

The DevRel went down to Georgia...

Alex Riviere — Thu, 29 Feb 2024 22:21:21 +0000

Inspiration came from Stu Robson

The DevRel Went Down to Georgia

(to the tune of The Charlie Daniels Band’s “The Devil Went Down to Georgia”)

The DevRel went down to Georgia, they had some code to shill 
They were in a bind, cause they were way behind, and the VP wasn't thrilled
When they came upon this young dev pushing to main and cursing a lot
The DevRel sat right down and said, "Hey let me tell you what,

"You probably didn't know it but I've pushed main a time or two,
And if you care to have a share, I'll make a deal with you,
The thing my company makes can solve your primary issue,
I'll bet a sticker of gold against your role that it'll make it faster too."
The dev said "My names Sally and I've got stand-up in ten,
But if you wait, I can give an update, and then we can begin"

Sally commit and push your code and submit a new PR,
Cause the tests won't fail in CI, and the DevRel has a card
and if you wait, you'll win this shiny sticker made of gold
and if you leave, the DevRel gets your role

The DevRel opened up their mac, and said "I'll start this show"
And fire flew from their finger tips as they began to git clone
And they pulled a branch, and started to talk about their business
Then a band of recruiters joined in, and it sounded something like this

[insert amazing guitar/banjo/fiddle solo, overlaid with someone discussing some kind of generic developer product with a chorus of recruiter ooh-ing and ahhh-ing, and miscellaneous keyboard sounds]

Now when the DevRel finished, Sally said, "That's a pretty good dry run,
But come sit down in the chair right there, and let me show you my problem."

Fire up some docker, npm run
Add a little python, rust for fun
C Sharp in the backend, layer in some go
Tie it all together with a bit of "No Code"

Well, the DevRel bowed their head because they knew they can't compete
And they laid that golden sticker down as they got up from their seat
Sally said, "DevRel, don't feel too bad, or lose any morale,
The tool seems cool, I like your pitch, but I need it to support pascal!"

Fire up some docker, npm run
Add a little python, rust for fun
C Sharp in the backend, layer in some go
Tie it all together with a bit of "No Code"

Why I Find LLMs Frustrating

Alex Riviere — Sun, 28 Jan 2024 21:38:21 +0000

LLMs are a great tool if they are used responsibly. However when you blindly copy and paste the results, it will make your life hell.

Don’t Trust The AI

We’re currently having to rewrite large portions of our code at work because of a pattern introduced by an LLM that was 100% wrong. It’s not some small part of the codebase either. It’s the data layer. In no way is this code close to being good or correct.

Now this being said, the code in question is misusing the useFetch composable in Nuxt 3. I’ll be honest, I find useFetch to be very backwards in how it works. Essentially, you declare all your dependencies up front, and then it can automatically update based on reactive values. I know why they went this way, but it’s confusing as heck. Add on top of this an automatic caching mechanism you can’t turn off, and you’re gonna have headaches.

But when I discovered that the bad code generated is from ChatGPT, I was furious. You cannot blindly accept what an LLM spits out. LLMs spit out something that approximates what a reasonable response would look like. It does not, cannot, and will not attempt to fact check itself, and even when you attempt to correct it, your results will only be technically correct on a good day. So when you copy and paste the first code example you are given, and then copy and paste it all over the code base…. The result isn’t great.

On The Other Hand…

I have dysgraphia. It’s like dyslexia, but for writing words and communicating ideas. It gets in the way at work very often. I’m regularly having to write issues and communicate technical stuff to multiple other people in a way that isn’t just sci-fi technobabble. I fall short of this frequently. My brain goes faster than my fingers can write (on paper, typing, or speaking sometimes) and I will skip 8 steps when I really need to slow down and connect the dots.

I was talking to my sister (who specializes in education and communication) after a particularly rough patch, and was explaining all of these woes, my sister just looked at me and said,

“Alex, you know that’s what ChatGPT is good at…”

She was right.

I needed something that can take my weird jargon and break it out into a more usable format. ChatGPT is great at taking text written and rewriting it into another tone or format.

So, I caved.

I made a little ChatGPT prompt that understands what technology we’re using, I told it to NOT give code examples (I do not have time to correct that nonsense), and I told it to format it in markdown as a github issue with steps to do. I can then _ edit _ the output as needed to correct its mistakes. It gives me the needed framework to make communication with my team more successful.

It’s been a mixed success. It’s fixed a lot of the pain points we were having. It’s saved me time. It helps me get around the thing my brain cannot do.

More Help

I’ve also recently started using brainstory.ai to help me think through ideas. I’ve used it to help me write some conference abstracts because (once again) my dygraphia won’t let me format things in a way others will understand. It lets me talk and kinda word vomit out all my ideas and then help summarize what I’ve just said.

Another great tool to have in your pocket.

A Tale of Two AIs

I cannot say that I fully endorse using LLMs for everyone. You cannot tell ChatGPT to write your essay homework and expect it to be correct. But, maybe it can help you reword that sentence you’re messing with to make it be better. Maybe if you struggle communicating your thoughts, it can help you put them out in a useful way.

While I’m not always great at communicating, I don’t always need help. Sometimes I can word vomit an entire page long thing about a topic that I have a mild amount of experience with and hopefully help others without any assitance.

Like this.

WTFM

Alex Riviere — Fri, 19 Jan 2024 02:46:32 +0000

A philosophy that you should always maintain when developing is to Write The Fricken Manual.

Many times over the years, i’ve heard the advice to “RTFM”. But the documentation wasn’t great. And no one was writing it. This sounds ridiculous, but until recently, the React documentation was spread across blog posts and tweets, and a huge effort was put into making a new documentation site that was up to date. In a way, it has probably been extremely helpful that React has not released a new version in almost 2 years.

When you write software, you must write the documetation. Immediately. Post haste. Pronto. When you move on to the next thing, you will forget how what you just made works. Write documentation like future you is an axe murderer with a time machine. Don’t anger future you.

Am I perfect at this? Heck no. Ask my coworkers. We’re struggling through getting stuff in my brain out in a usable form right now.

You have to try to write the docs though.

WTFM.

The LightBox Nerd Snipe

Alex Riviere — Sun, 07 Jan 2024 22:32:34 +0000

I’ve been nerd sniped.

A few weeks ago, Raymond Camden posted about An Image Dialog Web Component and I read that article, added some discussion about how you’d style it, then promptly stopped thinking about it… _ consciously _. I think it’s been floating around in the back of my brain because another colleague recently asked what lightbox scripts people were using with astro and other SSGs. My immediate thought was “Well, that should be a web component…” completely forgetting that Raymond made a post about it nearly a month prior.

Anyway, I made my own version.

See the Pen

light-box by Alex Riviere (@fimion)

on CodePen.

This version is a bit more forgiving than Raymond’s. It looks for any link with an image inside of it. Which makes it easier to use it with a list, or whatever nested structure you want. It also allows for multiple images and then will give you previous and next buttons based on what is there, but will limit itself to the contents of the current light-box.

Anyway, You’re welcome. Go use this for good.

Or chaos.

Have fun.

Optionally Shared Context in React Components

Alex Riviere — Mon, 02 Oct 2023 16:00:11 +0000

Right, here’s a weird one. I know what many of you are thinking:

Alex, why the heck are you writing about React?

The answer is, I just solved an issue for someone and they said to write a blog post. So fine, I’m writing a blog post.

Shared React Context

So my friend had a problem:

I’ve not dealt with this before: I’m helping someone who has a React component that is reused across a codebase. It pulls variables from a Context to be used in a few functions. BUT, if it’s in a different part of the app, those variables should come from a different Context. The component has a prop that tells you which context it should pull from, but you can’t put the useContext hooks in an if statement

When I see an issue like this my gut instinct is to point out that in vue you can have optionally reactive data and/or throw this type of thing into a computed value and move on with your day. But I bit my tongue, and made a minimal reproduction with a solution.

Shared Context - Normal Brain Version

import { createContext, useContext } from 'react';
import * as ReactDOM from 'react-dom'

const App1Context = createContext(null);

const App2Context = createContext(null);

const MyComponent = () => {
  const app1 = useContext(App1Context);
  const app2 = useContext(App2Context);

  return <h1>{app1?app1:app2}</h1>;
};

const Apps = [];

Apps.push(() => {
  return (
    <App1Context.Provider value="Hello App 1!">
      <MyComponent />
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return (
    <App2Context.Provider value="Hello App 2!">
      <MyComponent />
    </App2Context.Provider>
  );
});

Apps.forEach((Component) => {
  const mount = document.createElement("div");
  document.body.append(mount);
  ReactDOM.createRoot(mount).render(<Component />);
});

Here’s a working demo

The way this works is by requesting both context values. If the 1st one exists, we use that. if the second one exists, then we use that instead.

Bada-bing, Bada-boom, solved.

Mostly solved

So, someone commented that really only works if you always want it to default to using the first context, but what if you wanted to use the 2nd context first?

Well, you’d need to be able to allow to specify the context order that we pick from, so let’s make a slightly more complex version.

Shared Context - Big Brain Version

import { createContext, useContext } from 'react';
import * as ReactDOM from 'react-dom'

const App1Context = createContext(null);
const App2Context = createContext(null);

const MyComponent = ({ context }) => {
  const chooseContext = {
    app1: useContext(App1Context),
    app2: useContext(App2Context)
  };

  if (!context) {
    context = ["app1", "app2"];
  }

  if (Array.isArray(context)) {
    for (const app of context) {
      if (chooseContext[app]) {
        return <h1>{chooseContext[app]}</h1>;
      }
    }
  }

  if (typeof context === "string") {
    if (chooseContext[context]) {
      return <h1>{chooseContext[context]}</h1>;
    }
  }

  return <h1>YOU PROVIDED NOTHING!!</h1>;
};

const Apps = [];

Apps.push(() => {
  return (
    <App1Context.Provider value="Hello App 1!">
      <MyComponent />
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return (
    <App2Context.Provider value="Hello App 2!">
      <MyComponent />
    </App2Context.Provider>
  );
});

Apps.push(() => {
  return <MyComponent />;
});

Apps.push(() => {
  return (
    <App1Context.Provider value="Hello App 4!">
      <App2Context.Provider value="This will not display.">
        <MyComponent />
      </App2Context.Provider>
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return (
    <App1Context.Provider value="This will not display.">
      <App2Context.Provider value="Hello App 5!">
        <MyComponent context="app2" />
      </App2Context.Provider>
    </App1Context.Provider>
  );
});

Apps.forEach((Component) => {
  const mount = document.createElement("div");
  document.body.append(mount);
  ReactDOM.createRoot(mount).render(<Component />);
});

Working demo here

This version allows you to pass a context prop that can be an array of strings or just a string, and specify which context order you want, or which context specifically you want.

People said this looked good.

Bada-bing, Bada-boom, done.

I was hungry so I started to go make lunch. My brain however started to do loop-de-loops in my head, because my brain LOVES patterns. Like way too much. But it saw one. it saw something that could be refactored into an easier use case.

Fine, brain. Let’s go.

SharedContext - Galaxy Brain Mode

Let’s start with the generic thing we can use to make this better.

// shared-context.js
import { useContext } from 'react';

export class SharedContext {
  /**
   * shhhh, our secret registry
   */
  static #registry = new Map();

  /**
   * register a shared context
   * @param {string} sharedName - the shared name for the context group.
   * @param {ReactContext} Context - the context object from `createContext`;
   * @return {Symbol} - The identifier used to specify the exact context you would like.
   */
  static register(sharedName, Context) {
    if (!SharedContext.#registry.has(sharedName)) {
      SharedContext.#registry.set(sharedName, new Map());
    }

    const ctx = SharedContext.get(sharedName);
    const identifier = Symbol(sharedName + ctx.size);
    ctx.set(identifier, Context);
    return identifier;
  }

  /**
   * Get a shared context map
   * @param {string} sharedName - the shared name for the context group.
   * @returns {Map<Symbol, ReactContext>} returns a map of Idenitier/Context pairs.
   */
  static get(sharedName) {
    return SharedContext.#registry.get(sharedName);
  }

  /**
   * Get the correct context value based on your current component.
   * @param {string} sharedName - the shared name for the context group.
   * @param {*} [fallback] - The fallback value when no context is provided.
   * @param {Symbol|Symbol[]} [context] - The order of lookup for context based on ID symbols.
   * @returns {*} returns either the fallback or the found context.
   */
  static use(sharedName, fallback, context) {
    const ctxMap = SharedContext.get(sharedName);
    if (!ctxMap) {
      throw Error(`no such SharedContext: ${sharedName}`);
    }

    const ctx = new Map();

    ctxMap.forEach((Context, identifier) => {
      ctx.set(identifier, useContext(Context));
    });

    if (!context) {
      context = [...ctx.keys()];
    }

    if (Array.isArray(context)) {
      for (const id of context) {
        if (ctx.get(id)) {
          return ctx.get(id);
        }
      }
    }

    if (typeof context === "symbol") {
      if (ctx.has(context)) {
        return ctx.get(context);
      }
    }
    return fallback;
  }
}

This code gives us a generic way of creating “Shared Context” states that have a default order. You use SharedContext.register to register a context to a shared namespace, and it will return a unique Identifier Symbol that you can use to specify the context again when you want to use it. Otherwise it’ll use the ones that are registered in the order they are registered. To use the Shared context you call the SharedContext.use hook, where you give it the shared namespace, and a fallback value as a default. you can also specify the specific context, or order of the context you would like to use.

The code to use this looks something like this:

import { createContext} from 'react';
import * as ReactDOM from 'react-dom';
import {SharedContext} from './shared-context.js';

const App1Context = createContext(null);
const App2Context = createContext(null);

// The order is based on the order of registry...
const App1ContextId = SharedContext.register("App", App1Context);
const App2ContextId = SharedContext.register("App", App2Context);

// So in theory, with a code split code base, only the ones registered would be used...
const App2ContextIdAlt = SharedContext.register("Alt", App2Context);
const App1ContextIdAlt = SharedContext.register("Alt", App1Context);

const MyComponent = ({ context }) => {
  const ctx = SharedContext.use("App", "YOU PROVIDED NOTHING!!", context);

  return <h1>{ctx}</h1>;
};

const AltComponent = ({ context }) => {
  const ctx = SharedContext.use("Alt", "YOU PROVIDED NOTHING!!", context);

  return <h1>{ctx}</h1>;
};

const Apps = [];

Apps.push(() => {
  return (
    <App1Context.Provider value="Hello App 1!">
      <MyComponent />
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return (
    <App2Context.Provider value="Hello App 2!">
      <MyComponent />
    </App2Context.Provider>
  );
});

Apps.push(() => {
  return <MyComponent />;
});

Apps.push(() => {
  return (
    <App1Context.Provider value="Hello App 4!">
      <App2Context.Provider value="This will not display.">
        <MyComponent />
      </App2Context.Provider>
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return (
    <App1Context.Provider value="This will not display.">
      <App2Context.Provider value="Hello App 5!">
        <MyComponent context={App2ContextId} />
      </App2Context.Provider>
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return <hr />;
});

Apps.push(() => {
  return (
    <App1Context.Provider value="Hello Alt 1!">
      <AltComponent />
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return (
    <App2Context.Provider value="Hello Alt 2!">
      <AltComponent />
    </App2Context.Provider>
  );
});

Apps.push(() => {
  return <MyComponent />;
});

Apps.push(() => {
  return (
    <App1Context.Provider value="This will not display.">
      <App2Context.Provider value="Hello Alt 4!">
        <AltComponent />
      </App2Context.Provider>
    </App1Context.Provider>
  );
});

Apps.push(() => {
  return (
    <App1Context.Provider value="Hello Alt 5!">
      <App2Context.Provider value="This will not display.">
        <AltComponent context={App1ContextIdAlt} />
      </App2Context.Provider>
    </App1Context.Provider>
  );
});

Apps.forEach((Component) => {
  const mount = document.createElement("div");
  document.body.append(mount);
  ReactDOM.createRoot(mount).render(<Component />);
});

Working demo here

This is probably the most flexible version. In theory we could also allow the fallback to be a function so if you wanted a fresh version of something you could do that, but ultimately, I don’t want to be responsible for that, and lunch is ready.

After writing a React helper, I feel a strong need to go take a shower. Y’all take care!

useFetch in Nuxt 3: The Proper Way

Alex Riviere — Sun, 17 Sep 2023 14:33:29 +0000

I have recently seen at least 2 people make a wrapper around useFetch in Nuxt 3 incorrectly by trying to call useFetch as though it were fetch. While the approach they take will usually work (in general), it will very quickly cause you to have multiple errors and weird side effects.

Generally, the example i have seen is something like this:

export const useDataThing = () => {
  // grabing some globally available data via pinia, useStorage, vuex, useState, etc
  const dataThing = useGlobalDataThing();
  const dataThingId = useGlobalDataThingId();

  const isPending = ref();

  //create our own fetch handler
  async function fetchDataThing() {
    // calling a composable like it's just a function
    const { data, pending } = await useFetch(`api/dataThing/${dataThingId.value}`);
    console.log(pending.value);
    isPending.value = pending.value;
    dataThing.value = data.value;
  }
  if (!dataThing.value) {
    fetchDataThing();
  }
  return {
    dataThing,
    dataThingId,
    fetchDataThing,
    isPending,
  };
};

There is a whole bunch of bad errors you’re gonna get from this, mostly stemming from the fact that you’re not calling useFetch in the root of your composable function. So let’s fix that.

A Better Way

useFetch is a composable and should be called in essentially the context of the setup method. It provides a way to trigger fetch calls.

Let’s rewrite this in a better way.

export const async useDataThing = () => {
  // grabing some globally available data via pinia, useStorage, vuex, useState, etc
  const dataThing = useGlobalDataThing();
  const dataThingId = useGlobalDataThingId();

  const { 
         // Our Data result
         data,
         // if the call is pending
         pending:isPending,
         // 2 ways to trigger the fetch call, they both work the same
         refesh, execute,
         // Let's make all the other stuff available too: status, errors, etc
         ...theRest
        } = await useFetch(
    // We can pass a function as the url param so that we can get the current
    // value of dataThingId when fetch is called.
    ()=>`api/dataThing/${dataThingId.value}`,
    {
      // Don't call fetch immediately. Wait for us to trigger it.
      immediate:false,
      // Create a key for caching/correct storage
      key: "getDataThingById"
    }
  );

  //create our own fetch handler
  async function fetchDataThing(...args) {
    await refresh(...args);
    dataThing.value = data.value;
  }
  if (!dataThing.value) {
    fetchDataThing();
  }
  return {
    dataThing,
    dataThingId,
    fetchDataThing,
    isPending,
    ...theRest
  };
};

Doing it this way will Make it way more consistent for you. You can now fetch a different piece of data by doing:

const {dataThing, dataThingId, fetchDataThing} = await useDataThing();

dataThingId.value = 10;
await fetchDataThing();

console.log(datathing.value); // will have the updated values.

Hopefully this will save others with a lot of pain.

Classes, Super, and You

Alex Riviere — Tue, 18 Jul 2023 13:37:20 +0000

Last week Chris and Dave mentioned that they don’t get why you have to call super when you’re in a class.

Let’s learn you a thing

So first let’s just cover what I’m gonna be talking about here. We’re talking about the super keyword that can be used in JS classes. This keyword is most commonly used in the constructor of a class, and Dave asks:

“Why doesn’t class auto-imply super?”

The answer is: Function Signatures.

I Don’t Autograph My Functions

Function signatures tend to be talked about in other languages more, but the general idea is that a function signature is the name of the function, the arguments and their types, and the return type. this creates a unique identifier for the function you have written also known as its signature.

That definition is probably an over simplification, but in other languages with types, you can overload a function/method definition by redefining it with a different signature, and it can be used multiple ways. Since JavaScript doesn’t have this concept built in (and TypeScript won’t do this either) we tend to not talk about it… Until you need to extend a class.

Extending classes

When you extend a class, the original class will have a constructor definition. We’ll use this example from MDN as our basis:

class Rectangle {
  constructor(height, width) {
    this.height = height;
    this.width = width;
  }
  get area() {
    return this.height * this.width;
  }
  set area(value) {
    this._area = value;
  }
}

Our Rectangle class has a constructor that takes in a width and a height. This makes sense because a rectangle can have a width that is different from its height.

So what happens when we do this?

class Square extends Rectangle {
  constructor(length) {}
}

The JavaScript engine doesn’t know how to “auto-imply” a super call. There is 1 argument. the extended class constructor needs 2.

Enter `super`

The fix for this is that the developer must be explicit in how the extended class is constructed.

class Square extends Rectangle {
  constructor(length) {
    super(length, length);
  }
}

Rather than trying to add some AI LLM to every JavaScript engine to try and figure out what your auto implied constructor signature is, you as the developer need to say what the call will be.

Conclusion

Dave, Chris, you have to call super because the engine cannot guess what you are trying to do. I hope this helps.

Please Be More Physically Active

Alex Riviere — Wed, 14 Jun 2023 20:10:06 +0000

Alright, I’ll admit I am the least qualified person to talk about this. But as a mediocre white guy in tech on the internet, I’m going to share my experience.

A bit of backstory

I don’t work out. I should. All of my doctors agree on that point. In fact, all of those doctors would be pleased if I just started walking a little each day. But my brain is bad, and it thinks that taking a walk is the equivalent of summiting Everest. Everytime I consider any form of physical activity, my brain goes “Ew, no.”

In a previous career, I spent lots of time pushing boxes, climbing ladders, regularly lifting 20lb lighting fixtures over my head, and this type of activity kept my body in pretty okay shape. Was I the most fit? No. But at least i was moving. A lot.

Moving over into the Web Dev space, I stopped moving. Like, pretty much entirely. This was/is my downfall.

A year+ ago I went to see a physical therapist (PT) for the first time. My wrist was always in pain, and I figured it wouldn’t hurt to talk to a professional (let’s be honest) my wife told me to go see her PT. We worked through some stuff, the wrist got better, cool. Then, other things started to hurt.

Reality sets in

The way my PT at the time explained it to me was this: Most people end up in physical therapy because they have over-extended something. They’ve done too much. And in doing so, they’ve hurt themselves.

_ However , There is also the other end of the spectrum, where someone does absolutely nothing at all to the point where the body starts falling apart (not literally, I hope). _This is where I am, and let me tell you, it sucks.

Whatcha gonna do?

This is where I’m supposed to be inspirational and stuff, right?

“Just lift one thing at a time!”

or maybe:

“No one ever regrets working out!”

Most platitudes don’t work when your brain won’t cooperate. I genuinely have no idea what I’m gonna do, nor do I have any life altering advice I can give. The only thing I can tell you is what I get told by everyone:

“Please, just move more.”

Don’t let your body fall apart.