DEV Community: Nashe Omirro

My first deep dive into creating open source projects

Nashe Omirro — Sun, 27 Apr 2025 01:49:20 +0000

Have you ever had that feeling of building something from scratch? The temptation of proving yourself that you are a software developer and that you should use your own packages instead of relying on other's works?

Well a week ago I had that feeling, CSS! How hard could it be to make a bunch of styles for common elements, right?

So I was using this awesome project called skeleton, an adaptive design system powered by tailwind, and I really liked the foundation it gave me but didn't really use most of their provided components. And for that reason as well as the urge to build my own tool, I decided to make stratum!

This is by all means not to advertise my package, I assure you after this experience I do not want to maintain it outside of my own issues and feature requests 😅.

The Fun Part

Essentially, the idea was to strip out the things I liked from skeleton and add my own styles, maybe even make my own svelte components, I'd learn a bunch of stuff, and maybe even get a small community going.

Oh how naive I was, imagining and brainstorming ideas and actually executing said ideas are very very different things, this project made me more aware of this now.

Learn, Learn, Learn

I said that if I was gonna do this I was gonna do it right, as if the package is official and would actually be used by people. Hence the first thing I had to learn: monorepos, setting them up, looking into how projects could communicate with other projects, keeping dependency versions consistent across them.

Simultaneously I also had to make a deeper dive into tailwind, making custom utilities, diving deeper into CSS, looking into cross browser consistency especially for native elements, and at the same time exploring the internal workings of the skeleton project so that I have a guide.

Lastly, I had to look up A11y, how to make quality svelte components, and all how in general how I can make stratum more unique, since I wanted not to just copy-paste skeleton.

This was still fun no doubt! The challenge of learning, the reward of demystifying advanced-looking concepts and things, it was still a positive experience, however this is where I started to feel overwhelmed.

Smaller, Smaller, Smaller

Not long after creating the first drafts of the core package, I realized I had to be realistic. I cannot complete this in an appropriate amount of time and I only had one developer working on this (me).

During this, I had made plenty of issues to track what needed to be done and any bug I found, the more I explored/brainstormed the more issues I solved, and the more issues I created.

If I were to see this project actually making the finish line I had to strip away a lot of the features I had planned, I gave up on the idea of making my own components, I removed already created features/projects, and after all that I was left with an appropriate workload, although be it not as impressive.

The work I didn't think about

Okay after a big while, I've done the work, I'm ready to release v0.1.0 of the project, I'm ready to host the created sites alongside the release. And overall I was happy with what I made.

But it's not just the code you had to prepare: How do I automate version bumping and changelogs? If this does get an active community how would they contribute? Do I even want to take on reading PRs or solving issues? Do I even want to build a community from scratch? Discord, Youtube, advertising the project, etc., What about updates to the project? Do I really want to make migration guides and documentation?

The answer to most of the questions above is a resounding NO THANK YOU. (the first question was solved with changesets, go check it out it's awesome!)

It was clear to me I have bitten of more than i could chew, I don't even believe that stratum would be worth investing that much time and effort. So I left it at that, this project is now just my personal CSS framework, I still am very happy with it despite not reaching the stars I fantasized it would reach 😅.

The next time

Despite not wanting to author an open source project, if I were to make an open-source project of similar size here's what I would do differently:

Get some other devs into the project: Ape together strong as they say. Even at least one more developer could make a huge difference, you get feedback on your project before even making it, and the workload is theoretically halved or significantly reduced.
Dream appropriately: My project initially had a scope that required say two or three developers working together, a few months, and also not forgetting to actually put the project out there. Before even starting, look at how much time and effort you can actually devote to this project.

I have a lot more respect now towards open source maintainers, sure you could make the argument that some are funded or that they gain reputation by doing so, but that doesn't make the work they do any more easier, work is still work, and to be honest they could arguably get a lot more from just devoting their time elsewhere. So thank you to any maintainer who is reading this, I promise to donate to projects I use from time to time (not now though I'm broke 😭).

Even with the project not going as planned, I still learned a lot from the challenge, I'm still gonna use stratum for my personal projects and am very accomplished for completing it (barely! this thing doesn't even have proper documentation!)

making tailwind components more viable with "dip:"

Nashe Omirro — Thu, 20 Mar 2025 19:32:43 +0000

So before diving into this, this code straight up isn't mine and I just found it on github written by gustavopch which is just an implementation of a tweet from tailwind's creator, Adam Wathan.

what is it

It's basically just a custom variant that does one thing, places utilities you use in a lower specificity:

@variant dip {
  @layer dip {
    @slot;
  }
}

the above variant will place all CSS properties on a layer called dip. Since all tailwind utilities go in a layer called utilities, dip is actually a child of that initial layer.

And with the way CSS handles layers, rules that are not in a layer will always beat out rules that are, so in this case the utilities layer always beats out the utilities.dip layer. Which makes us able to do something like this:

<!-- `text-sm` will win against `text-2xl` -->
<h1 class="dip:text-2xl text-sm">This is a bad example</h1>

again text-sm is not in the parent layer, so it beats the child layer that text-2xl resides in.

what are the use cases

the title of the article, components! specifically overriding their styling, and more specifically, creating components that are utilities *wink*

let's start with the former, which to be honest kinda sucks and tw-merge is still better. Imagine this is a component in your favorite framework:

<!-- `className` and `children` are props, you know the drill -->
<h1 class="dip:text-xl dip:text-surface-900 {className}">{children()}</h1>

any other class given to it can cleanly override text-xl and text-surface-900! Just like you would with tw-merge, only this time no javascript needed.

but still, the reason why tw-merge is better is because you can't stack the dip! Once you've already overriden a class you can't do it again! Imagine this:

<BaseHeading /> // is used and "overriden" by...
<SpecialHeading /> // which is also used by...
<Article /> // which "overrides" it again

if SpecialHeading overrides BaseHeading and then Article overrides SpecialHeading it now doesn't work because we can't dip any deeper, for this example to work we have to use two layers not just one, okay maybe we can do two layers then, but what if the overriding goes for a third time? Don't even think about it:

<!-- the cursed output to our frankenstein's monster -->
<h1 class="dip2:text-xl dip:text-2xl text-3xl">Oh bloody hell</h1>

so yes, you can use dip: like the above with some heavy limitations but I'm more excited about the second use-case.

the true use case

fools! If you're reading this far in the article then you have fallen right into my trap! Because you see, this was actually @layer components propaganda!

With the ability to place utilities into lower specificities, we are able to create utilities that are supposed to be overriden!

@utility btn {
  @layer dip {
    color: var(--color-primary-500);
    padding: --spacing(2);
    /* ... */
  }
}

and what's more, they can be used with variants! and intellisense autocompletes it with added tooltips! Now before you spit on me and recite your mindless "tailwind actually is against using component classes", imagine with me for a moment, look at how awful this is:

// in a UI library somewhere...
type Props = HTMLAttributes<'button'> & { ... } 
function Btn({ class: className, ...props }: Props) {
  return (<button class={merge("...", className)} {...props}>{children()}</button>)
}

the shit you have to go through just so you could group a bunch of utility classes together, the typescript, the props, the runtime merging, the added abstraction, and then what if you want to make it an anchor tag instead? Oh but of course any library worth its salt has to have polymorphic components!

Embrace the taboo with me for a sec, look at how this can be all done with just using CSS:

@utility btn {
  /* ... */
}

and then:

<button class="dip:btn text-sm">accept</button>

we can even ditch dip: when we don't need to override it! Or just dip it by default with:

@utility btn {
  @layer dip {
    /* ... */
  }
}

you can use @apply inside by the way, and why must you have multiple components for variants when you could do:

@utility btn {
  /* ... */
}

@utility special-btn {
  @apply btn;
  /* ... */
}

I could keep glazing but in short tailwind v4 has a lot of flexibility and power that we could utilize to remove unnecessary abstractions. In truth, I would agree with the "you don't need component classes" but only in a sense that you don't need a lot of them, but just not needing them at all seems impractical.

conclusion

So.. what do you think? Honestly I'm just glad component classes can now have autocomplete, back in v3 you had to do it with javascript as a plugin. The dip: variant is interesting but the big weakness of it being just "override-able once" is a big downer, for a lot of big apps out there I don't think they'll be dropping tw-merge anytime soon, but for small to mid sized apps I think it would be great.

I'm more interested on your thoughts with the "true use case" claim though, I really think it's worth making a @component rule that is the same with @utility but instead places them in the components layer, the layer is just too under-utilized.

Also p.s, tailwind's actually fine with component classes, i don't know why I thought they didn't.

Working with Astro and Alpine

Nashe Omirro — Sat, 02 Mar 2024 09:42:43 +0000

A modern version of templating engines and Jquery.

In this age of high-level frameworks, this stack gives you a clean slate similar to the experience of web developers ages ago, when SPA was still an experimental concept and when Jquery was still king, only this time with the benefits of cutting-edge technology and modern day advancements.

best used for

This stack works best with websites that are content-heavy, not needing heavy logic, but still needs scripts for things like carousels, dropdowns, navbars, etc. And unlike other more popular JS frameworks, Your code will feel much more light-weight and more closer to traditional javascript, because you are not rendering markup with your logic, but instead attaching logic to your markup.

Try it out!

Astro already has official support for Alpine with the @astrojs/alpine integration. You can then start writing scripts with either Alpine.data or inlining it with x-data:

<script>
  import Alpine from "alpinejs";

  document.addEventListener("alpine:init", () => {
    Alpine.data("Component", /*...*/);
  });
</script>

Important things to know:

@astrojs/alpine does two things to add alpine to the project, one is letting you add an entrypoint where you could add plugins and custom directives to Alpine, and then it attaches the Alpine module script at the <head /> of every page.

<head>
  <!-- your custom astro scripts will be placed above -->
  <script type="module" src="...">Alpine.start()</script>
</head>

This allows you to use Astro's script tags without worrying about Alpine initializing before registering your alpine:init listeners.

You can even create a utility function for it:

// utils.js
export function defineComponent(name, cb) {
  document.addEventListener('alpine:init', () => {
    Alpine.data(name, cb);
  })
}

<script>
  import { defineComponent } from "./utils.js";
  defineComponent("Component", () => { /* ... */ });
</script>

Just note that if you do import Alpine on the server, you'll most likely get an error, avoid that by only importing utils.js inside <script /> tags.

Another thing is to be aware of is name conflicts when using Alpine.data(), they are not scoped and there's no way for us to create these names dynamically with Astro, so a naming convention is needed to avoid potential conflicts.

Thoughts on utility-first approaches in CSS

Nashe Omirro — Sat, 17 Feb 2024 15:12:39 +0000

With Tailwind reaching 6,000,000+ weekly downloads on NPM, as well as becoming my personal go-to for hobby projects, I wanted to understand why it got so popular... And I believe the one primary reason is an issue within CSS that bothered developers for so long:

Class naming is "hard"

Is that it? Well, yes but it goes further than that. So let's first ask why class naming is hard.

Look at these two pictures, they are both doors.

If we were to name this doors just like how we do in CSS, Let's ignore best practices for a second and call the first door something like yellow_door and the other brown_door.

Simple right? Now what if we had a slightly different looking door that's also brown, what then?

There are two ways we've come up with to solve this, renaming the doors to be more descriptive or using some form of modifiers:

normal_brown_door and modern_brown_door
brown_door and brown_door --modern

Okay.. Then what if we add 10 other doors with various sizes, colors, the amount of inner squares they have, the design they follow, oh wow!

What a headache... Well technically we can create some sort of structure that will name all the doors, but I'm too lazy to do that.

Class naming isn't hard per se, what's hard is avoiding the consequences of poorly named classes.

"Should I use modifiers for this? Should I create a base class? Should this class "extend" from the base class even when it shouldn't use some of the base class's styles? Should I instead refactor the base class into two classes or move some of the styles of the base class to one that inherits from it? Should I just copy the styles into a new class, do I need it connected to the base class in the first place?"

Questions like these attempt to make our CSS more maintainable in the long run, and solving said questions is a pain.

The natural way we "name" things

Okay then, since these doors are real, how do we describe them in real life? Simple! We describe them the same way: yellow door, brown door. If we had more doors, we'd get more descriptive.

Picture this, you are on a call with a friend that's right outside and they're looking for the house that you live in. How would you direct them to the building?

The natural way we'd do it is to describe the building no? It's a two-story house, it's egg white, it has a red roof, the door is black and modern looking, etc. The more descriptions you add, the more better they could find the place. For many people, describing the house is the first thing that comes to mind. Yes, guiding them to the house is arguably more common but guess how we guide them? we describe landmarks and things that they see visually.

Getting to the point

Now imagine describing your house in succinct one-liners, it becomes harder doesn't it? Especially if there are other identical houses near you.

That's what we're doing with class names, we are trying to put descriptions of things and compressing them into shorter names and trying to make logical structures out of them. Wouldn't it be more easier if we just use the descriptions themselves?

Developers are built different

As web developers, we understand CSS properties like how we would understand visual descriptions in real life, and that's exactly what a utility-first approach enables us to do in code.

A way for developers to visually describe an element instead of naming and creating OOP-like naming conventions for them. No need to name things that are just too abstract.

Components are easier to logic about

That's nice and all but we still have to "name" things, we have to name our components, and we still need to group styles into it.

That's true, even with a utility-based approach we can't avoid that, but we still drastically avoid naming abstract objects and we let our components handle the structure instead (which is somehow easier). When we create components, there is some logical sense behind it, whether it's because it has some functionality attached or maybe it's an easily-named object.

Now at this point, free reign is given to the developer with how they create their component libraries/systems, but it isn't cluttered by impossible-to-name objects and they only have to worry about their components as a whole. That div that has flex and auto-margin left in the Navbar component doesn't need a name, just described, and that Button's styles could be modified and overridden with props instead of using classes.

TLDR

Correctly naming things are hard, especially one's that are abstract in nature, describing them is easier, that's what a utility-first approach lets us do.

Drawbacks

The only implementation of this approach is none other than what first introduced it, Tailwind. Now it's really nice to not worry about naming... But then you end up with a messy hot pile of utility soup, which I and many other developers would agree is not ideal.

Some accept it as a tradeoff, while others think that it's too much of a con for what it offers. I personally feel that it should do better with it's @apply directive, making it easier to hook in to tailwind's internals but it's currently frowned upon to even use it, which feels like Tailwind leaning more towards a "utility-only" approach rather than what it claims.

why using both mobile-first and desktop-first approach isn't bad practice

Nashe Omirro — Thu, 28 Dec 2023 03:49:16 +0000

So I actually use both "max-width" queries and "min-width" queries.

Why use both though?

Now before answering why I do it this way we need to understand the reason for a mobile-first approach, and that reason is that our responsive-styling is much more intuitive when we gradually add more CSS instead of gradually removing CSS, and the consensus is that we would have more CSS the more larger the screen becomes.

But sometimes that isn't the case. The most common exception is a navigation menu which is much more complex for mobile devices, in mobile you need to have an absolute-positioned menu with toggle-able transitions, but in desktop it's just a static flex-box with some padding. In these scenario, if we truly want the benefit of a mobile-first approach we would then have to start the styling in a bigger screen size.

Using both properly

If you agree with my reasoning you might try it yourself and do something like this:

/* for convenience sake let's call this above('sm') */
@media (min-width: 480px) {
  // ...
}

/* and this below('sm') */
@media (max-width: 480px) {
  // ...
}

But the problem with this is at 480px both queries work. Now that might not look like an issue, but let's say we hid our toggle button at above('sm') because we would like our nav menu to only be absolutely-positioned below('sm'). If the user is at exactly 480px they would not see the toggle button nor the navigation menu!

The mostly complete solution

So to fix that we have to only have one of the queries be inclusive (480 and above) and the other to be exclusive (just below 480), so you might try something like this:

@media (min-width: 480px) {
  // ...
}

@media (max-width: 479px) {
  // ...
}

Now with this, our imaginary toggle button should be visible right at the moment that our nav menu becomes a static box. We only have one query active between above('sm') and below('sm').

But even then there is still a problem, browser screen sizes aren't integers.

The complete solution

Because screen sizes aren't fully integers (1028.4px, 721.6px, etc.), we have a problem yet again in cases where the screen size is between 479px and 480px.

For example, if the browser window is at 479.6px, then both the below('sm') and above('sm') queries would be inactive! Which means that in our theoretical situation the nav bar already becomes a static-box but the toggle button is still visible.

So to fix this, all we have to do is use floating points as well:

@media (min-width: 480px) {
  // ...
}

@media (max-width: 479.9px) {
  // ...
}

In the above block, we set the query to only be active when we are 0.1px away from 480px. This way, no matter if the browser has a size of 479.6px or 479.9px, we would still have either the below('sm') query active, or the above('sm') query active.

Of course, you could argue that if the screen size is between 479.9px and 480px, then we would have the same problem yet again, but at that point I think its quite unlikely that that would happen. But you could still prepare for it if you set the max-width at 479.99px.

Conclusion

Apart from nav menus, I honestly can't think of other situations where the mobile-first approach needs to be flipped. I do think that the name should've been more closer to what it wants to do, so something like "additive approach" could have worked better.

Then again, the term "mobile-first" seems to have expanded it's meaning to caring more about the mobile view than the desktop view, this was around the time people discovered that more and more traffic is coming from mobile devices, so I can see why the name stuck.

But I want to emphasize that these are just guidelines and should not have to be followed strictly, as a developer it's important to understand why we follow guidelines in the first place and why in some cases it is actually much better to break them.

Having fun with svelte stores using store proxies

Nashe Omirro — Fri, 17 Nov 2023 18:29:53 +0000

So imagine this one big global store with lots of nested properties, how would you write a way to derive a piece of state from that store? One answer would be to just react to that store inside svelte itself, and maybe a utility function could handle the deriving logic:

import { store } from './store.js';
import { deriveFoo } from './store.utils.js';

$: foo = deriveFoo($store);

another more refined answer is to use a derived store to then export it inside of svelte:

import { derivedFoo } from './store.js';

<p>{$derivedFoo}</p>

In most cases, those two are good enough and is the standard way to get value out, but there is a more radical approach to derivation, and it has big upside to it as well.

abusing the store contract

Before getting into the third approach, we'll just understand what the store contract is in svelte. In a nutshell, it is the automatic process of svelte subscribing and setting a store inside components:

import { store } from './store.js';

function updateStore() {
  // assignments becomes a call to the store's set property
  $store.foo = $store.foo + 1;
}

// svelte spots this and auto-subscribes for you
<p>{$store.foo}</p>

What makes them truly awesome though is that they don't care what kind of object it's actually accessing, so long as it has a subscribe property and optional set property and both conform to the store contract (subscribe gets passed a callback and set gets passed a value).

Now knowing this, we are able to create our own derived store without the derived function from svelte!

const store = writable({ foo: 0 });

const derivedFoo = {
  subscribe: (cb) => store.subscribe((state) => cb(state.foo),
};

In the above example, we are basically hijacking the subscription process and letting us extract foo and pass it to the given callback. This means that users of the store are actually subscribed to the big gigantic store but only get a small part of it.

derived and writable?

Okay, it's nice to understand what's actually happening but why do this when you can just use derived?

The answer to that is the fun part, unlike derived, we can supply a set property! Making the store writable!

const store = writable({ foo: 0 });

const foo = {
  subscribe: (cb) => store.subscribe((state) => cb(state.foo),
  set: (value) => store.set((state) => { 
    ...state,
    foo: value
  }
};

And to use it:

import { foo } from './store.js';

function updateFoo() {
  // we can correctly set foo!
  $foo = $foo + 1
}

// we can use it just like derived
<p>{$foo}</p>

And that's not all, another feature that uses the store contract when dealing with stores is the bind: directive, which means we could do this!

import { foo } from './store.js';

<input bind:value={$foo} />;

Binding to a derived state! Pretty cool, yeah?

Conclusion

You don't have to stop there, this is just a simple example, the truth is that as long as you follow the store contract, anything goes and you can get crazier with it.

but I guess stores will probably kick the bucket soon because of the new runes coming to town, understanding this though will still help you try to do the same with runes! Or maybe not... apart from the "you can do this?!" factor, realistically there isn't really a common use case this solves that the other, more simpler and readable approaches don't solve. It is still kinda neat~

Choosing what to spend your time on

Nashe Omirro — Sat, 21 Oct 2023 15:40:40 +0000

Recently I've been stuck trying to start learning something new. I'm self-thought and am currently job-searching and noticed the insane amount of applications being sent in by numerous other people, obviously this had gotten me down but I knew I had to take action and adapt. Should I keep advancing my front-end knowledge? Should I make a new better project for my portfolio? I have a decent foundation on the front-end, so then why not complete the stack?

"Aha!" I muttered as I started searching for a back-end guide, and then my hope got squished when I saw how much I had to learn before becoming competent. How much time do I have to spend? A month? two months? five? I knew these were the wrong questions, but the thought did make me hesitant to dive in. I was able to be comfortable with SQL and exposed myself to Postgres after a few months, albeit I did struggle pushing myself to do so.

"There has to be an easier way" I thought, and there was. When I was searching I noticed a lot of web-builder jobs with Wordpress or Shopify, it'll be easier to jump in and it'll probably only take a month max if I wanted to be competent, but then questions began cluttering my head again, what then? Make web projects using said builders? What projects should I do? Do I even want to learn these? Isn't this choice "weaker" in the long-run?

There again paralyzed by choices, I couldn't commit to one so I spent a few weeks switching between the two, constantly trying to make up my mind, and have come to a depressing realization, I'd realized that I have wasted a lot of time thinking of what I wanted to spend my time on. This realization made my heart drop, as even before this web-builder vs back-end debate, this feeling of paralysis isn't new, I had contemplated over what to choose before: web-dev vs game-dev, continue self-thought vs continue traditional education, continue web-dev vs start mobile-dev, learn X vs learn Y, etc. etc. etc.

I wanted to shout, but I couldn't cause it was 2:00AM and I lived with my family, so just like anyone stuck fixing a bug for hours, I shouted my heart out internally. I wanted to reject this paralysis, I hated having to over-analyze, I hate having to think so much to choose so I gave up all my thoughts, I let go of what's best for my future, what's best for my time, and held on to one question: "what are you genuinely interested in right now?"

The next day I started learning game development, hours passed and I continued, there was no other thought but wanting to learn more. After years of overthinking, I have somehow forgotten what it felt like to genuinely learn for the sake of learning.

Conclusion

Often choices are difficult and that's true to some extent, we want to choose the right path, the right person, the right career. However, I think we are too hung up on that part, we want the "best" option and in doing so we ask the wrong questions.

Handling view types from supabase with typescript

Nashe Omirro — Tue, 13 Jun 2023 05:56:17 +0000

When you have a view on supabase and grab the types using the supabase cli, you'll soon find out that all the properties are nullable, this is not a problem with supabase but a limitation of postgres.

Solution

The easiest way to handle these types is to use type guards, but it could get a bit messy and complicated if we don't use utility types so lets make our lives easier by writing them:

// the Database type generated by supabase
import type { Database } from "./db";

export type DBTypes = {
    [P in keyof Database['public']['Tables']]: Database['public']['Tables'][P]['Row'];
} & {
    [P in keyof Database['public']['Views']]: Database['public']['Views'][P]['Row'];
};

// example
❌ Database['public']['Tables']['my_table']['Row'];
✅ DBTypes['my_table'];

the type above allows you to view the singular row type of any table or view just so that we can make things more readable. Some other utility types that will be helpful is ones that remove the null type from an objects properties, here we have two:

type RemoveNullOn<T, O extends keyof T = never> = {
  [P in keyof T]: P extends O ? Exclude<T[P], null> : T[P];
};
type RemoveNullExcept<T, E extends keyof T = never> = {
  [P in keyof T]: P extends E ? T[P] : Exclude<T[P], null>;
};

Both of these two do the same thing but in slightly different ways. With these types, we can easily create type guards more easier.

Example

I have a view in one of my projects that joins a few tables so that I could just do one api call:

// ...
class_details: {
  Row: {
    advisor_id: string | null
    advisor_name: string | null
    assigned_id: string | null
    assigned_name: string | null
    class_id: string | null
    class_name: string | null
    filepath: string | null
    is_locked: boolean | null
    section_grade: number | null
    section_id: string | null
    section_name: string | null
    updated_at: string | null
  }
// ...

I know that some columns will always be present, so I could then create a type guard checking for those properties else I will throw an error:

// I want to remove null from X except for these keys
export type ClassDetail = RemoveNullExcept<
  DBTypes['class_details'],
  'assigned_id' | 'assigned_name' | 'advisor_id' | 'advisor_name' | 'filepath' | 'updated_at'
>;

export const isValidClassDetails = (
  details: DBTypes['class_details'][]
): details is ClassDetail[] => {
  return details.every(
    ({ class_id, class_name, is_locked, section_grade, section_id, section_name }) =>
      class_id && class_name && is_locked && section_grade && section_id && section_name
  );
};

And to check for other properties, we could create additional type guards:

export const hasAssigned = (
  detail: DBTypes['class_details']
): detail is RemoveNullOn<typeof detail, 'assigned_id' | 'assigned_name'> =>
  Boolean(detail.assigned_id && detail.assigned_name);

export const hasAdvisor = (
  detail: DBTypes['class_details']
): detail is RemoveNullOn<typeof detail, 'advisor_name' | 'advisor_id'> =>
  Boolean(detail.advisor_id && detail.advisor_name);

export const hasFilepath = (
  detail: DBTypes['class_details']
): detail is RemoveNullOn<typeof detail, 'filepath' | 'updated_at'> =>
  Boolean(detail.filepath && detail.updated_at);

The neat thing about this is that DBTypes['class_details'] can always be extended by any type we've removed null on:

// true
{ a: string, b: string } extends 
  { a: string | null, b: string | null } ? 
    true : 
    false

so we won't get any type errors if we nest them as long as the object type can extend the original type DBTypes['class_details'].

// detail has `assignedId` and `assignedName`
if (hasAssigned(detail)) {
  // ...
  // typescript won't complain
  if (hasFilepath(detail)) {
    // ...
  }
}

Hiding utility functions in Supabase

Nashe Omirro — Tue, 23 May 2023 11:29:05 +0000

In Supabase, it is often useful to have utility functions to use in RLS Policies to re-use common logic like is_admin(uuid) or get_all_items(uuid), or when you need to create security definer functions to bypass RLS policies.

But the problem is that these functions is also exposed through our API and could be called by users using supabase.rpc(). The way we could hide these functions is to move and create them in another schema.

The Solution

To do this, go ahead to the SQL editor and create the schema:

create schema utils;

To create functions on this schema, we can prepend utils. on our function names when creating them.

create or replace 
function utils.is_admin (uid uuid) 
returns boolean 
language plpgsql as $$
begin
  -- ...
end
$$;

You can ignore the function body and focus on the function name utils.is_admin, this creates a function in the utils schema instead of the default public schema. You can check that our schema and function has been created if you look at the Database section on the dashboard.

Only the functions and tables in the public schema will be exposed through the API so our utility functions cannot be called using supabase.rpc().

To use these functions, you'll need to write the full <schema>.<function_name>(), just like the built-in storage.foldername() function that Supabase provides. So to use the function above, you can call it by doing utils.is_admin().

Granting Access

But wait! We're not done yet, if we create RLS policies with our functions now then Supabase will not complain, however, once we test it out through our application we get an error that we are not permitted to use functions on the utils schema, this is because we haven't granted permission to our users that they can access these functions:

To do this, head back to the editor:

grant usage on schema utils to PUBLIC;
grant execute on all functions in schema utils to PUBLIC;

The first line is to allow usage of our schema, the second line allows the public to execute every function on our schema. The keyword PUBLIC means everyone, so here we are granting access to our functions to anyone. (still not exposed though)

This way, we can now have functions that are not exposed to the users, but can also be used for RLS policies. This is especially safer than exposing security definer functions to the public, and much cleaner than to just leave it in the public schema.

Granting Access to specific users

We could also just give access to certain users, the authenticated keyword is for users who are currently signed-in:

grant usage on schema utils to authenticated;
grant execute on all functions in schema utils to authenticated;

This will make sure only users who are signed in can access our utility functions, anyone who isn't will get the error before. Remember to revoke the privileges from PUBLIC if you previously granted access:

revoke usage on schema utils from public;
revoke execute on all functions in schema utils from public;

Understanding the react dev environment for beginners

Nashe Omirro — Fri, 13 Jan 2023 05:16:07 +0000

If you're like me you probably made the mistake of jumping straight into react after you've gotten used to coding JS in the browser.

And if that's the case you probably felt lost like I did because you're trying to learn the framework inside a giant black box of other complicated stuff like Webpack, Babel, Typescript, NPM, etc. If that's you at the moment then maybe this high level overview from the perspective of a fellow junior could help you de-mystify this combination of tools.

What is NPM and Node.js?

You probably heard a brief explanation for these before, Node.js is used to run JS outside the browser and NPM is used to manage your dependencies. That's really all it is but if you're still confused then for now treat NPM like a manager for adding third-party libraries to your app, like embedding a <script /> tag for Bootstrap or Bulma. And then your package.json file contains a list of the dependencies you've added.

How does my code get run on the browser?

Well first we need to understand that when you type "npm run dev" or "npm start" in your command line, you're actually starting a local server (if you've used the Live Server Extension then it's just that). The local server then hosts your app on a port, hence why you see your application on localhost:XXXX.

// start
- run the command: "npm run dev"
- NodeJS creates a local server
- local server hosts your app on a port

This server will be running until you close the active terminal or stop the process with Ctrl + C. Whilst it's running, whenever you make changes to your code, it will listen to that change and update the app on the browser.

// running
- you save your changes to your code
- server picks up on that change
- server then updates the app on the browser

Note that it doesn't refresh the entire page but only updates what needs to be updated, this method is called Hot Module Replacement (HMR).

Where does Webpack and Babel come in?

These tools actually have been doing it's job the whole time, Webpack is the one responsible for listening for changes and compiling your code and uses Babel to compile modern code to old code so that your app can run in older browsers, as well as converting JSX into regular JS. At the very start and whilst your updating your code, Webpack is doing it's job:

// start
run the command: "npm run dev"
NodeJS runs Webpack which spits out a local server
Webpack compiles your code
Webpack hosts your app on a port

// running
- you save your changes to your code
- Webpack picks up on that change
- Webpack compiles the new changes
- Webpack then updates the app on the browser

Note that even though I'm using Webpack in this example, this also applies to other tools like Vite. Also, this process of listening and re-compiling is optimized so you don't have to worry about Webpack having to recompile your whole app every time you save.

What exactly is the server hosting?

It's actually hosting an index.html file, the JS bundle, and other static assets you've included. Webpack then attaches a <script /> tag to the html file that points to the JS bundle so that the browser will load your JS.

// start
- ...
- Webpack compiles your JS into a bundle
- Webpack hosts the other static assets and index.html
- Webpack adds a <script /> tag to html file
- Webpack hosts your app on a port

This is also what happens after we run "npm run build", we get a folder that contains all the files needed to host our app on the web:

- index.html
- js_bundle.min.js
// other static assets...

Note that vite does do things a bit differently, instead of bundling your code into one file, it serves all of them as ES Modules, it will still bundle them in production (when you run "npm run build").

What about ESLint and Prettier?

ESLint doesn't do any transformations on your code, it's a tool used for highlighting errors and code smells. Nothing much to do with the main process above.

Prettier is just a code-formatting tool, you can download the extension to have it be your default code formatter when you press Alt + Shift + F on VS Code, or install it through NPM.

What's up with all these files in my root?

Most files that have names such as ".config.*", ".json", etc. Are configuration files for the various tools the project is using. Even ESLint and Prettier can be configured with such files ".eslintrc", ".prettierrc", and so on.

Some tools allow multiple names for their config files, but you can usually tell which is which. It could be a bit daunting seeing a weirdly named file at the root but it's most likely there to configure some internal stuff your environment is using.

For the most part you wouldn't need to worry about configuration, memorizing every config property isn't necessary, the defaults should be good enough for most.

More on JSX and Babel

As mentioned before, Babel will handle compiling your JSX code to React.createElement calls. The thing with JSX is that it isn't natively supported in JS, you can call it an extension of JS, where we add new syntax to JS and then convert it back with Babel so that the browser can read and execute it properly. Babel actually has a playground where you can see the converted code as you type it!

What about Typescript?

Typescript is kind of the same as JSX but in a much more larger scale. We still need to trans-pile it to JS to run it in the browser. As to what is trans-piling your .ts and .tsx files varies depending on what you've used to bootstrap your project, CRA uses Babel for everything and Vite uses the Typescript Compiler (tsc).

Conclusion

Pretty nifty right? I'll be honest I am pretty sure this isn't even everything, there could be more config files from other tools that your project will use, like testing with jest or integrating storybook, its... its a lot, but don't worry about it, it's not a deal breaker if you don't know the exact specifics of the tools you're using, but it's important to know how they all come together.

Cover image by Tim Hüfner on Unsplash

Making polymorphic component implementations faster

Nashe Omirro — Sun, 25 Dec 2022 07:34:42 +0000

👋 Hey if you're looking to add polymorphic components to your project, why not try react-polymorphed, It's a types-only package I made to help create fast polymorphic components without the hassle. It also solves some common problems like correctly inferring event-listeners, supporting refs, and restricting what the component can polymorph into.

The Problem

what causes typescript to suddenly become sluggish is this one type: ComponentPropsWithRef<T>. Here's what the type currently is:

type ComponentPropsWithRef<T extends ElementType> = T extends new (
  props: infer P
) => Component<any, any>
  ? PropsWithoutRef<P> & RefAttributes<InstanceType<T>>
  : PropsWithRef<ComponentProps<T>>;

And the usual implementation is something like this:

// for a polymorphic button
type Component = <C extends ElementType = "button">(
  props: ComponentPropsWithRef<C> & { as?: C }
) => {
  // ...
};

Of course there's more to it than that (we haven't made it work with forwardRef yet) but this is essentially what it is.

So right now we are feeding C to ComponentPropsWithRef<T>. We do not know what C is until it is used, we just know that it extends the type ElementType. Since we don't know what it is yet, ElementType will be used in ComponentPropsWithRef<C> instead, the ElementType can be boiled down to this:

type ElementType = keyof JSX.IntrinsicElements | ComponentType<P>;

Let's focus on the keyof JSX.IntrinsicElements type... THAT is a union of over 173 TYPES! And we are feeding that to ComponentPropsWithRef!

ComponentPropsWithRef<ElementType>

BUT that isn't exactly the problem, sure this is what slows down typescript but it's only slowing typescript down because of how the ComponentPropsWithRef<T> type is structured.

Here's where my understanding becomes mixed with a bit of speculation, So take what I say after this with a pinch of doubt, I am just gonna go ahead and say that this piece of code from ComponentPropsWithRef<T> is what's causing it to be so slow:

// ...
PropsWithRef<ComponentProps<T>>

It's not really because we are using a union of over 173 types to check what component props are, in fact, if you feed ComponentProps<T> with ElementType:

ComponentProps<ElementType> // this results to `any`

you wouldn't get any impedement at all, it's still very fast (explained why later). So if it is not the massive union, nor is it ComponentProps, then is it PropsWithRef? Also nope, the type below doesn't cause any significant problem at all:

PropsWithRef<ComponentProps<ElementType>>

The true problem is the combination of being placed inside a conditional and typescript having this behavior of going through each element inside a union, to visualize this let's observe this type:

type A<B extends string | number> = B extends string ? "a" : "b";

type IsA = A<string>; // "a"
type IsB = A<number>; // "b"
type IsAB = A<string | number>; "a" | "b"

In the type IsAB, It's going through every element in the union and testing each on the conditional, which if we now look at what ComponentPropsWithRef<ElementType> is doing, it is being computed like this:

  | PropsWithRef<ComponentProps<"a">>
  | PropsWithRef<ComponentProps<"div">>
  | PropsWithRef<ComponentProps<"button">>
  | // ... all the other 170+ elements
  | PropsWithRef<ComponentProps<FunctionComponent<any>>>;

And if we look at what PropsWithRef<P> is doing, it is also checking if the props contains string ref or exactly this:

type PropsWithRef<P> = "ref" extends keyof P
  ? P extends { ref?: infer R | undefined }
    ? string extends R
      ? PropsWithoutRef<P> & { ref?: Exclude<R, string> | undefined }
      : P
    : P
  : P;

So now, we are feeding EACH ELEMENT PROP into the type above, which then checks if those props have a ref property, which then transforms the type again to have no string included in the ref property.

IN the end, we still get any but in a more costly way.

The Solution

So now that we understand the problem, A naive solution I came up with is to lift PropsWithRef<T> outside the conditional like so:

type ComponentPropsWithRef<T extends ElementType> = PropsWithRef<
  T extends new (props: infer P) => Component<any, any>
    ? PropsWithoutRef<P> & RefAttributes<InstanceType<T>>
    : ComponentProps<T>
>;

This makes it ridiculously fast cause now we aren't doing the checks PropsWithRef<T> on every element! We first resolve what ComponentProps<T> is and then do the checks PropsWithRef<T> does.

But isn't ComponentProps<T> still like this?:

  | ComponentProps<"a">
  | ComponentProps<"button">
  | // ...
  | ComponentProps<FunctionComponent<any>>

Yes it is, but I'm just going to guess that those are just accessing individual properties of JSX.IntrinsicElements as well as just inferring props from FunctionComponent, also throw in the assumption that typescript have already cached those values since we always use them when we write react JSX.

But it's still a union of over 173+ different objects, but even then, because we also do ComponentProps<FunctionComponent<any>> or that class component being any on the other side of the conditional, the union get's simplified to just any.

Conclusion

I hope at this point you also got that eureka moment I had when I first realized the problem. Typescript is a wonderful language that, just like it's subset Javascript, also has a lot of quirky behavior (just ask a library maintainer).

Creating fast type-safe polymorphic components using render props

Nashe Omirro — Wed, 16 Nov 2022 01:17:51 +0000

UPDATE: After a few weeks of researching more about polymorphic components and other implementations, digging through source code and all, I made a typescript package for creating polymorphic components that uses the as prop, and better yet, doesn't slow down typescript at all, go check it out!

Spoiler alert: We won't be using the as prop for this one, if you were looking for a solution that mimics the implementation of styled-components or other component libraries, you can check out this very detailed guide by Ohans Emmanuel.

HOWEVER, I wouldn't recommend the pattern, simply because it makes typescript significantly slow and if you're using average to low-end devices, it just kills DX. Truth be told though that I have not looked for better as prop implementations that does not impede typescript.

This post is basically just a more verbose solution from this article, "Writing Type-Safe Polymorphic React Components (Without Crashing Typescript)" by Andrew Branch, it explains in more detail than I ever could, on why the as prop is slow and his solution to the problem. I also recommend to check that out first if you want more context.

Expected Behavior

Before starting, we first need to know what polymorphic components are:

we can override the component to render something else.
It has a default render, a <Button> is a button until we say otherwise.
If we don't override the component, it should have default prop types, and once we do override it, strip those away and replace them with the props of our override.
We might also pass props that are required by the component no matter what we are rendering.

Implementation

Okay, now that we got that over, here comes the fun part! The core concept is to pass in a function that our polymorphic component will call, more widely known as the "render prop" technique, here's a simple demonstration:

// the props we pass to our render function
type InjectedProps = {
  className: string;
  children?: React.ReactNode;
};

// the props we pass to our Button
type Props = {
  color: 'red' | 'green';
  children?: React.ReactNode;
  render?: (props: InjectedProps) => React.ReactElement;
};

// the default render function for rendering a button
const defaultButton = (props: InjectedProps) => <button {...props} />;

const Button = ({
  color,
  children,
  render = defaultButton,
}: Props) => {
  // calls render, in which if undefined is going to render our
  // defaultButton
  return render({
    className: getClassName(color),
    children,
  });
};

// <button className="red-button">Fwoop</fwoop>
<Button color="red">Fwoop</Button>

// <a className="green-button">Fwoop</a>
<Button color="green" render={(props) => <a {...props} />}>
  Fwoop
</Button>

Instead of using an as prop, we pass in a render prop that the polymorphic component calls. In the second use of our <Button /> we render an anchor tag instead.

The actual component is stored on the render prop, and Button is only used to calculate the props that will be passed to our render.

Using Generics

But what if you want to pass our <Button /> some button attributes?

// type and onClick isn't part of the props
<Button onClick={onClick} type='submit' color='green' />

We can try adding those in to Props with the help of ComponentPropsWithoutRef:

type Props = ComponentPropsWithoutRef<'button'> & {
  color: "red" | "green";
  // ...
};

But this would mean we can do this with no errors:

<Button
  onClick={onClick}
  color="red"
  aria-hidden
  render={(props) => <a {...props} />}
>Fwoop</Button>;

Now in here we have 2 choices, either have the Button change it's props according to whatever the render prop returns or just write those attributes inside the <a /> tag instead. If we go with the former, not only will that be harder than implementing the as prop, we also won't get the performance benefits this pattern brings. So, we are going for option #2

Which means that we shouldn't be able to pass in those props if we have a custom render, moreover, we aren't passing those props to render in the first place. Let's fix that:

import { ComponentPropsWithoutRef } from 'react';

type InjectedProps = {
  className: string;
  children?: React.ReactNode;
};
type DefaultProps = ComponentPropsWithoutRef<'button'>;

// let's place the render type here for re-use
type RenderFn = (props: InjectedProps) => React.ReactElement;

type Props = {
  color: 'red' | 'green';
  children?: React.ReactNode;
  render?: RenderFn;
};

// let's also make sure default button has default props as well.
const defaultButton = (props: InjectedProps & DefaultProps) => (
  <button {...props} />
);

// checks if render is undefined, if it is then we should also
// have default props.
const Button = <T extends RenderFn | undefined>({
  render = defaultButton,
  color,
  ...props
}: T extends undefined
  ? DefaultProps & Props
  : Props & { render: T }) => {
  return render({
    className: getClassName(color),
    ...props,
  });
};

// Has button attributes by default
<Button color="green" aria-hidden>
  Fwoop
</Button>

// Is rendered as an anchor tag
<Button color="red" render={() => <a aria-hidden />}>
  Fwoop
</Button>

// Typescript will complain about the type attribute
<Button 
  type='button' 
  color="red" 
  render={() => <a aria-hidden />}
>
  Fwoop
</Button>

By using generics, we can determine if the render prop was passed or not. If it wasn't, our props would be of type: DefaultProps & Props, but if we did pass one, the DefaultProps get's stripped away.

note that including { render: T } is important, it tells typescript which prop we should check for.

Tidying up

With the above solution, that pretty much checks all of the goals we've set:

our Button is overridable ✔
our Button is a button until we render something else ✔
if we did pass a render function we strip away the default props and also only passing the important bits ✔
and we still require a color to be passed, render prop or no render prop ✔

But our solution is a little messy, let's tidy up with some utility types:

// utils.ts
export type RenderProp<T extends Record<string, unknown>> = (
  props: T,
) => React.ReactElement | null;

export type PropsWithRender<
  IP extends Record<string, unknown> = {},
  P extends Record<string, unknown> = {},
> = P & {
  /** when provided, render this instead
   * with injected props passed to it. */
  render?: RenderProp<IP>;
  children?: React.ReactNode;
};

/** Intersect A & B but with B
 * overriding A's properties in case of conflict */
export type Overwrite<A, B> = Omit<A, keyof B> & B;

And we can use them like so:

type InjectedProps = PropsWithChildren<{ className: string }>;
type DefaultProps = ComponentPropsWithoutRef<'button'>;
type Props = PropsWithRender<
  InjectedProps,
  {
    color: 'red' | 'green';
  }
>;

const defaultButton = (
  props: Overwrite<DefaultProps, InjectedProps>,
) => <button {...props} />;

const Button = <T extends RenderProp<InjectedProps> | undefined>({
  render = defaultButton,
  color,
  ...props
}: T extends undefined
  ? Overwrite<DefaultProps, Props>
  : Props & { render: T }) => {
  return render({
    className: getClassName(color),
    ...props,
  });
};

One thing I didn't like to keep doing was having to write JSX for our default render function, so I wrote a little utility to help with that:

/**
 * Creates a render function given a react element type, 
 * types are very loose on this function so make sure to give 
 * it the proper `P` for the `Component` passed
 * because typescript won't complain if they don't match.
 */
export const createDefaultRender = <P extends Record<string, unknown>>(
  Component: React.ElementType,
): RenderProp<P> => {
  return (props: P) => <Component {...props} />;
};

Now we can just do:

const defaultButton =
  createDefaultRender<Overwrite<DefaultProps, InjectedProps>>(
    'button',
  );

Yeah, maybe its not too much of an improvement but to each their own.

with forwardRef

Unfortunately, forwardRef() and generics don't mix at all and that there are multiple ways to potentially solve this problem. Me being a lazy ass went for the easiest choice... not using forwardRef() at all and just using a custom prop named innerRef.

If you also chose the big-brain solution then here's some more utility types you can use:

/**
 * just like `ComponentPropsWithRef<T>` but with `ref` key 
 * changed to `innerRef`.
 */
export type ComponentPropsWithInnerRef<T extends React.ElementType> = {
  [K in keyof ComponentPropsWithRef<T> as K extends 'ref'
    ? 'innerRef'
    : K]: ComponentPropsWithRef<T>[K];
};

and then we can change our DefaultProps to:

type DefaultProps = ComponentPropsWithInnerRef<'button'>;

If you're also using the createDefaultRender function we can change that so that it assigns 'innerRef' to ref:

export const createDefaultRender = <
  P extends Record<string, unknown> & { innerRef?: unknown },
>(
  Component: React.ElementType,
): RenderProp<P> => {
  return ({ innerRef, ...props }) => 
    <Component ref={innerRef} {...props} />;
};

A small caveat

There is a possibility that we might override props unintentionally, take a look at this instance:

<Button 
  color="red" 
  render={(props) => <a {...props} className='my-button' />}
>
Fwoop
</Button>

O-Oh! The className from ...props got overwritten with 'my-button'. Sometimes this might be what we want but most of the time we usually want them together, this is also the case if we had injected props that have event listeners and what not.

Luckily for us, the man who I got this solution from already made a small utility function that merge-props together.

import mergeProps from "merge-props";
<Button 
  color="red" 
  render={(props) => <a {...mergeProps(props, {
    className: 'my-button'
  }) />}
>
Fwoop
</Button>

Conclusion

Yep, that was.. a lot, if you're a bit confused, don't worry, I am too but it does make more sense if you keep writing them this way.

Thanks for reading, and I'm sure that there are probably ways we could have implemented this better, so please write them in the comments for I too don't really know what I'm doing~